3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

A USERS VIEW OF THE SPS AND LEP CONTROL SYSTEMS

R. Bailey

CERN
CH-1211 Geneva 23, Switzerland

Abstract

interact with the accelerators. The same is true of the personnel
responsible for equipment commissioning.

Every accelerator has a control system; at present the SPS has
two, both of which are needed to run the machine. Consequently
a user of the SPS I LEP complex has to be concurrently familiar
with three control systems. While this situation brings problems
it allows, even forces, comparison between the different
systems, which in tum enriches the user viewpoint.

2. Overview of control systems available
From 1975 the SPS has been controlled, either exclusively or
partially, via a system based on Norsk Data ND 100 computersconnected in a TITN star configuration [1]. The computers run
SINTRON and the programmers are provided with the NODAL
interpreter, libraries of graphics primitives and data modules anda means of calling FORTRAN executables [2].

This paper assesses the SPS and LEP control systems from thepoint of view of the user, who may be an equipment specialist,
operator, accelerator physicist or combinations thereof.

1. Introduction - what the accelerators do

From 1985 the major new requirement for SPS to provide beams
to LEP meant a complete rewrite of the applications software.
This was undertaken in a UNIX environment on an Apollo
network, with C as the main programming language andApollo-Dialog for the user interface. In the first instance accessto the hardware was via a gateway into the existing TITN
system. More recently the possibility exists to access someequipment completely independently from the TITN system,
using the same overall Token Ring architecture as for LEP (seebelow).

Exploitation of the two large accelerators at CERN is a variedbusiness. For the SPS in 1991 this amounts to running as a fixed
target machine for over half the year, providing either protons(during 21 weeks) or sulphur ions (during 6 weeks) to thephysics community. In conjunction with this the SPS acts as an
injector to LEP, providing leptons in an interleaved repetitive
supercycle. Furthermore about 15% of the fixed target running
time is given over to machine development periods, when the
SPS is required to run in some non-standard way, mostly as atestbed for the LHC. Finally, the SPS is also used in the othermajor mode of operation, as a proton-antiproton collider, forabout 5 weeks.

Presently the SPS is run using a mixture of purely TITN (30% ),Apollo via the gateway into TITN (50%), and purely Apollo
Token Ring applications (20%) (see figure 1).
LEP applications also run on an Apollo network, with C as themain programming language and Apollo-Dialog for the userinterface. All the Apollos are connected on a control room
Token Ring, with communications out into the field through abridge to a machine Token Ring running around the accelerator[3] . At several points around the ring there is a further bridge or
gateway into either a regional Token Ring or an Ethernet
network. Connected to these local area networks is a variety ofconfigurations, allowing access into the hardware via several
different equipment control assemblies, mostly using theMIL-1553-B standard (see figure 1).

In parallel with all of the 27 weeks of SPS fixed target running,
LEP is taking beam either for zo production or for a substantialmachine development program, the latter amounting to about
30% of the total LEP running time.
For both machines, although mostly for LEP, installation andtesting of new equipment is carried out throughout the year.
This diversity of operations and machine improvement is carriedout from a common central control room, with the same teams
being responsible for both the SPS and LEP. In particular, one
group run the SPS in a variety of modes of operation throughout
the year as well as running LEP. This means that these personnel
have to be familiar with the different control systems used to

S01SRA01
Status Reports: Accelerators

1

1

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S01SRA01

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingExperience Controlling the LAMPF-PSR Accelerator Complex*
S. Schaller, R. Stuewe, E. Bjorklund, M. Burns, T. Callaway, G. Carr,
S. Cohen, M. Harrington, D. Kubicek, R. Poore, and D. Schultz
Los Alamos National Laboratory
Los Alamos, New Mexico, 87545, USA
Abstract
In recent years, control system efforts at LAMPF haveemphasized the provision of uniform control for the LAMPF
linear accelerator and associated beam lines and the Proton
Storage Ring and its associated beam lines. The situation iscomplicated by the presence of several control philosophies in
the operator interfaces, data base mechanisms, and front end
data acquisition and control interfaces. This paper describes thecurrent system configuration, including the distributed operator
interfaces, the data and control sharing between systems, andthe use of common accelerator diagnostic software tools.
Successes as well as deficiencies of the present system will be
discussed with an eye toward future developments. *I. BACKGROUNDThe Clinton P. Anderson Meson Physics Facility -- also
known as LAMPF, the Los Alamos Meson Physics Facility -is composed of an 800 Me V proton linac plus associated beamlines and targets, and an 800 MeV Proton Storage Ring (PSR)
plus its beam lines and a neutron spallation target that serves
the Los Alamos Neutron Scattering Center (LANSCE). The
linac accelerates beams ofH+, H-, and polarized H- (referred toas P-) ions up to 120 times per second in pulses of up to 1000
microseconds width. The average H+ beam current can be as
much as 1 mA. The proton storage ring serves as a beamcompressor, taking a full H- macro-pulse from the linac andejecting it in several hundred nanoseconds.
When LAMPF was built in the 1960's it was one of thefirst accelerators to be designed for computerized control.
Since the IEEE CAMAC standard did not exist at that time, asignificant amount of effort went into the design andconstruction of LAMPP-specific data acquisition hardware.
The system that resulted was called RICE (Remote
Instrumentation and Control Equipment). RICE hardware is
still used for more that 60% of the linac equipment. Over theyears, the control system was expanded to include CAMAC
hardware accessed on demand through remote computers. With
the addition of remote operator consoles, the initial stararchitecture has evolved into a much more distributed
configuration.
The Proton Storage Ring was designed in the early 1980's
to be independent of LAMPF with a separate control room andbeam lines. As a consequence, the PSR Control System was*Work supported by the U.S. Department of Energy

designed and implemented with only minimal consideration of
LAMPF requirements. The PSR system did provide
recognition of its effect on linac timing requirements and it
used a device naming scheme that was similar to LAMPFs.
The PSR system emphasized continuous update of acentralized database.
In 1988, responsibility for the Proton Storage Ring wastransferred to LAMPF. This paper describes the present
configuration of the two control systems and the attempts thathave been made to integrate them in a useful manner. We
conclude with a brief description of our plans for the future.
More information about our plans can be found in acompanion paper at this conference [l].

II. CURRENT CONFIGURATION
A. LAMPF Control System (LCS)
The evolution of the LAMPF Control System (LCS) has
been described in detail elsewhere [2-4). The LCS is currently
composed of a network of VAX computers connected via an
Ethernet using DECnet for communications. Computer
systems in the LCS network are of two types, (Figure 1). A
typical LCS operator console computer runs VMS and drives
one or more LCS operator consoles. Such a computer may
also have a CAMAC-based data acquisition and control
capacity. A typical LCS data acquisition front-end computerruns the VAXELN real-time kernel and handles hard real-timedata acquisition through CAMAC. The VAXELN nodes do nothave local disks.
Accelerator or Serial Highway

Accclc:ratcr

CAMAC

CAMAC

VAXNMS

Ethe net

VAXELN

Ethernet

Figure 1. LAMPF Operator Interface and Front End Computers

Each LCS operator console is composed of one or morecolor character-cell CRTs which are shared between a number
of application programs, several graphics scopes, trackballbased touch panels, and a set of analog control knobs. The
graphics scopes and touch panels are attached to the computer

S01SRA02
Status Reports: Accelerators

7

7

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S01SRA02

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

STAWS REPORT ON TI-IE ADvANDED LIGHT SoURCE CoNIROL SYSTEM
S. Magyary, M. Chin, M. Fahmie, H. Lancaster, P. Molinari, A. Robb, C. Tirnossi and J. Young
Accelerator and Fusion Research Division
Lawrence Berkeley Laboratory
University of California
Berkeley, California 94720
U.S.A.
The ALS consists of an Electron Gun, a Linac, a Linac-toAbstract
Booster line, a Booster, a Booster-to-Storage-Ring line, a Storage Ring (SR), and a number of user beamlines. The control
This paper is a status report on the ADVANCED LIGHT
system is currently operating the existing parts of the ALS
SOURCE (ALS) control system. The current status, perforaccelerator hardware consisting of the Gun, Linac, Linac-tomance data, and future plans will be discussed. Manpower,
Booster line, and the Booster; the Booster-to-Storage-Ring line
scheduling, and costs issues are addressed.
is being implemented now. The Storage Ring accelerator
hardware is under construction; completion is expected someI. INTRODUCTION
time during the second quarter of 1992. We will then be readyto begin commissioning the SR via the control system, both
locally and from the Control Room.
The ALS control system was designed around the conceptsof parallel processing, high CPU and I/0 bandwidth, andhuman-friendly interface. Figure 1 shows the system architecture and its five primary layers (for details of the system see
References [l] and [2]). Layer 1, represented by the Intelligent
Local Controllers (ILCs), interfaces to the accelerator hardwareand communicates with Layer 2, the Collector Micro Module(CMM). Layer 3 is the Display Micro Modules (DMM) that has
bus access to the CMM and in turn communicates with theoperator stations (Layer 4) via serial links. The operator
stations are high-performance Personal Computers that have
Ethernet network (Layer 5) access to file servers and othernetwork services.

Figure 2. Typical !LC installation.

II. LAYER 1 (INTELLIGENT LOCAL CONTROLLERS)The ILC is an intelligent controller consisting of an 80Cl86
main processor, an 80Cl87 math co-processor, and an 80C152
serial-control processor sharing 64 Kbytes of battery backed

Figure 1. ALS control system architecture.

S01SRA03
Status Reports: Accelerators

11

11

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S01SRA03

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA04

LESSONS FROM THE SLC FOR FUTURE LC CONTROL SYSTEMS*
Rusty Humphrey

Stanford Linear Accelerator Center, Stanford University, Stanford, CA 94309

11\e SLC control system is the dynamic result of anumber of forces. The most obvious force is the functional requirements of the SLC itself, but other forces a.re

history, budget, people, available technology, etc. The
plan of this paper is to describe the critical functionalwith 2 x 1010 particles is 1 sufficiently different machinefrom the SLC with 5 x 1010 particles that the problem
often disappears at 2 x 1010, only to reappear when thecurrent is raised to 5 x 1010 •requirements of the SLC which caused significant development of the control system. I have tried to focus onfunctional requirements as a driver, and I will describe
some solutions which we have implemented to satisfy
those requirements.
The important functional requirements drivers forthe control system discussed in this paper are:¢
Repetition rate¢
Sensitivity to orbit distortion¢
Stability/Automation¢
Accelerator Development

The next answer is to tune at the same beam pulse
intensity, but to lower the repetition rate. This is, in fact
the technique that is used at the SLC. However, it does
not work to simply lower the repetition rate of all components in the machine to 10 or even l Hz. Power is dissipated in the rf and pulsed magnet systems, andlowering the repetition rate in such components changes
their characteristics. Therefore, an effective rate limiting
strategy requires that the rate of running the pulsed components of the machine not be changed, but that only the
injection of electrons and positrons be moved to thelower rate.

REPETITION RATE

The above discussion is an overview of the simplest
situation; and even it isn't really simple-how the creation and injection of positrons is handled is problematiceven in this situation. More complicated scenarios arealso possible in the SLC [1].

The SLC runs for physics production at 60 or 120 Hz.
At 120 Hz, 5 x 1010 particles per bunch, 3 bunches/beampulse, and 50GeV, the average power is 150kW. If thebeam has a small enough cross sectional area, such abeam has caused damage to beam vacuum pipes, beamvacuum flanges, collimators, or other beam line components by heating. Such events occur because the beam
has become "errant"; that is, it has wandered from its
nominal orbit, and is actually striking the device. JJ thissituation is not detected, then more and more energy is
put into the device, as the SLC pulses keep coming. The
first issue is to detect the event, and tum off the beam.
There are a number of classic methods of such detection(ion chambers, beam current comparators, etc.), and the
SLC uses them.
Once the event is detected, how does one fix the
problem? Usually the answer is to steer or tune themachine. But now a situation, which appears as a form of"'relaxation oscillator," happens. To tune the beam, one
needs beam in the machine. But because the beam is mistuned, the machine protection system detects the sameproblem again and turns off the beam again. How does
one break this impasse?
11\e first, and obvious answer is to tune at a lower
beam intensity; instead of running with 5x1010 particles,
tune with 2 x 1010• nus doesn't work in general. The SLC•Work supported by Department of Energy contract DE-AC03i'6SF00515.

Another issue for the Machine Protection System isconfiguration flexibility. As the SLC configuration ischanged during tuning or machine studies, the requirements on machine protection change. An obvious example is a repetition rate change from 60 to 120 Hz. A lessobvious example is changing the place where the beam is
stopped. It is a requirement of the machine protection
system that it react to such configuration changes in as
seamless a manner and as prompt as possible. At the
SLC, this functionality is provided by means of the timing system, which includes distribution of timing "patterns" which a1Jow pulse to pulse timing configuration
changes. nus functionality is being augmented because
it is required by a project to upgrade our present
Machine Protection System [2], and because it is needed
for the next phase of our Fast Feedback system.

To summarize the functional requirements: The repetition rate for a linear collider can i.llow errant beam todamage or destroy beam line components. A protection
scheme is required which detects such situations, which
limits the beam, and which allows retuning of themachine to stop the situation. Jt is required that retuning
be done at or near the beam conditions which cause theerrant beam. In addition, the machine and its machine
protection system must be easily and quickly reconfigurable.

S01SRA04
14

Status Reports: Accelerators

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA05

Process Control for The Vivitron: the generator test set-up
J.R.Lutz, J.C.Marsaudon, R.Baumann, E.Kapps, R.Knaebel, J.Persigny.
Centre de Recherches Nucleaires, IN2P3-CNRS I Universite Louis Pasteur
BP 20, F-67037 Strasbourg Cedex, France
Abstract

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

The VIVITRON is a 35 MV Van de Graaff tandem electrostatic accelerator under construction at the CRN since 1985.
About half of the parameters are controlled by equipments
which are highly stressed by their physical environment :sparks, electrostatic field, X-rays, vacuum, and gas pressure. It
needs a dedicated process control system. The described control system is used since early 1991 to perform the voltage
tests of the generator. It provides important information for theaccelerator tuning and for the full size control under development.

side the accelerating tank and in the injector. They are connected to level 2 by optical-fibre links crossing the 2 MV/m electrical field. At least one crate is requested for each electricalequipotential level. The small space available in some "deadsections" imposes the choice of a small-scale bus crate.
Level 2 is located outside the vessel at ground level. [tachieves communication with level 3 and with level 1 and provides data switching, concentration and handling.
Level 1 includes the communication interface, the realtime control and the operator interface.

I. THE VIVITRON

III. THE SET-UP FOR THE GENERATOR TESTSThe Vivitron Van de Graaff tandem accelerator, underconstruction at the Centre de Recherches Nucleaires at Strasbourg France [1] is designed to reach a terminal voltage of
35 MV at its terminal electrode [2]. The tank (51 m long and
8.4 m in diameter) is filled with SF6 at 8 bars. The charging
system is a belt running close to the tube at a speed of 10 m/s.
The column consists of a glass fibre I epoxy ingulating assembly, supported by insulated epoxy posts. Seven porticos, large
field-shaping shields, and discrete electrodes improve the electrical field homogeneity [6].
The expected energy will vary from 20 MeV/A for thelight ions to 5 MeV/A for the heavy ions. The intensity should
go from 1012 pps for the light ions to 109 pps for heavy ones.

For the generator tests, only a reduced process control isneeded. No beam control is necessary, no automation is required, the number of parameters is limited and no equipment
crate is needed inside the machine. All the information is fed
out at both ends of the tank. Optical wires are used for sensors
and activators at high voltage. Shielded and protected galvanic
wires are used for those at the ground level. Thus, data acquisition, data switching and operator interface are dominant.

A. Current flow and terminal voltage

II. THE FULL SIZE PROCESS CONTROL
A. Specific problems
The process parameters are spread over a large area. The
control equipment, located at high voltage inside the accelerator tank and in the injector, are highly stressed by their physical environment: 35 MV breakdown flashes, 440 kJ stored energy, 1.7 to 10 MV/m electrostatic field, X-rays, vacuum, andSF6 gas pressure [3].

B. Architecture
A multi-level structure is implemented between the process and the operator.
Level 3 is in charge of the field equipment I/0 interfaces,
the handling, switching, buffering and communication of the
I/O data. Some of these field equipment crates are located in-

Figure 1. The current monitors in a dead section.

S01SRA05
Status Reports: Accelerators19

19

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingHigh accuracy ADC and DAC systems for accelerator
control applications.
E.Kuper, A.Ledenev
Institute for Nuclear Physics,
Novosibirsk, 630090, USSR
Abstract~n the work presented here the ways of
construction,
the apparatus for the precision
measurements and control systems incorporated in theaccelerating facilities of INP are considered. All theapparatus are developed and manufactured in thestandard of CAMAC.

of
precise components at a practically arbitrary
resolution, high linearity, easily achieved the galvanic
isolation of the analog part and consequently, a low
price.

-

Outputof'--__,.---' DAC

Introduction
ReferencesourceWhile carrying the experiments on the precision
measurements of the mezon·masses on the installations
with the electron - positron colliding beams one has touse the apparatus of a class 0.001 % with theRectifierresolution about 0.0001 %. An instability of the main
Voltageandconverter
stabilizer....._________.
power supply sources of magnetic systems of storagerings should not exceed 0.002%.
The powerful RF generators, the controlled sources
Fig.I. The analog section of PWM-DAC.
of power supply with an output power of a few
hundred kilowatts, pulse components of electronOne of the popular developments of INP is an 8optical channels, numerous digital devices including~hannel code-to-duty factor converter (CDFC) locatedcomputers are the sources of different kinds of noises.
. m the crate and transferring the control signal toUnder these conditions, the stronger requirements on
DAC - PWM integrated directly to the control objects.
the noise damping are posed to the measuring and
The DAC ~ignals in the form of different polarity
control equipment and to the analog data transfer
pulse, the distance between carrying the data onlines.
reference voltage for control system are transferred'
In the power supply system of the facility VEPP-4
through the coaxial cable with the transformer deone has to measure of about two thousand points andcouplin~ to ~he distance of up to 500 m. The simplified
to form the control signals for more than 500
schematic diagram of the converter is given in Fig.1.
channels. The time of energy rise is of ·a few tens of
The pulsed signals from DAC arrive at the trigger
seconds. In the mode of operation one needs the highcontrolled by the analog switches. The PWM
accuracy matching (0.1 % - 0.01 %) in the field variation
modulated signal is filtered with the RC filter of thein the magnetic components of accelerators. The
3rd order. In order to match it with the control systemtechnical parameters of the control and measuring
the error signal amplifier (ESA) is envisaged which
structures should provide the operation of the power
equalizer the DAC output signal to that from the
supply systems both in the static and in dynamic modes
current or voltage sensor. The galvanic de-couplingof operation.
on power supply is performed with the help of highfre~uency conve~t~r with the transformer of special
Digital - to - analog converters
design with the mimmum crossing capacitance. DAC
parameters are: 16 bites, error - 0.01 %, settling time Usually, the power supply sources of the storage
0.4 s, temperature factor of the output voltage ring facilities requires the digital-to-analog converters
0.0003%/K. The given configuration is being widely(DAC) of quite a low fast action at an accuracy
used in the systems of pulse power supply of theranging from 0.1 % up to 0.001 %. Therefore, most oftransport channels for charged particles, in the power
the converters used are designed on the base of the
supply sources for the "high current" correctors, i.e. inpulse width modulation PWM. The advantages of thethecontrolled objects arethose cases,
where
given type of DAC are well known: the minimum
distanced considerably and their groundings are=3 Ic

S01SRA06
Status Reports: Accelerators

23

382

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S01SRA06

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The GSI Control System
U. Krause, V. Schaa, R. Steiner
Gesellschaft fiir Schwerionenforschung mbH, D 6100 Darmstadt, Germany

Abstract
The GSI accelerator facility consists of an old linac andtwo modern machines, a synchrotron and a storage ring.
It is operated from one control room. Only three operators
at a time have to keep it running with only little assistancefrom machine specialists in daytime. So the control tools
must provide a high degree of abstraction and modelingto relieve the operators from details on the device level.
The program structures to achieve this are described inthis paper. A coarse overview of the control architecture
is given.

I. THE GSI ACCELERATOR FACILITYAt GSI the heavy ion linac UNILAC runs successfully for 16
years. It produces beams of all elements up to uranium
with energies between 1.4 and 20 MeV /u. In '89 the heavy
ion synchrotron SIS and the experimental storage ring ESB.
started operation with ion energies up to 2 Ge V /u.
A new control system has been designed for SIS and ESB.
which is adopted step by step also for the UNILAC.
The system has to handle quite different facilities,- the UNILAC with 3 injectors and repetition rates of
25 ... 100 Hz,- the SIS with repetition rates of 0.1 ... 3 Hz,- the ESR with repetition rates of ::;0.001. .. 0.1 Hz,- transfer lines,
but has to provide an uniform operator access to all accelerators from one control room.
When the upgrading of the old components will be completed a total of 3000 devices scattered over an area of 250
x 250 meters have to be controlled. Complexity varies
from simple DC magnets to ramped magnets (ramps generated from up to 900 samples) and diagnostic devices (upto 40kB of data). Fast switching of the machines allow timesharing between several experiments and injection to thenext accelerator in sequence, all with independent beams.

II.

OPERATING REQUIREMENTS

There is a need for several identical consoles for independent operation of accelerator segments and hardware redundancy.

A consistent "look and feel" has to be provided for theoperator interface of all application programs.
To keep the control system serviceable and extensible
it has to be a modular and uniform system with definite
allocation of tasks. The size of the facilities suggests a decentralized, distributed and hierarchical system. Therefore
real-time aspects are limited to the device handling level,
data for these operations are stored there. By this meansa clear separation between accelerator and device oriented
aspects is achieved.
The operating level ("physics of accelerators"), locatedon powerful workstations, deals with the equipment as awhole and handles devices in a modeled form only. The
device level ("physics of devices"), located mainly on microcomputers close to the devices, maintains and controls
single devices. Both levels are connected by standardized
device accesses using identical mechanisms for all devices.

III.

CONTROLS COMPONENTS

On the operating level VAX 3100-VMS graphic workstations
are installed forming a VAX cluster. Uniform software allover the system is ensured by cluster-disks. One to three
VAXes are grouped as consoles for operator interaction.
The device level is equipped with two types of 68020
VME boards with a real time kernel. One is used as Master
Processor (MP) for command evaluation. The other isequipped with an interchangeable communication interface
and is used as Equipment Controller (EC) for device control and as Communication Processor (CP) for networking.
For communication between operating and device nodes
ETHERNET is used. Devices are connected via modified
MIL-STD-1553B serial bus with standardized InterFace
Boards (IFB) as part of the devices. Besides this otherinterfacing like IEEE-488 is partly used by simply replacing the communication part of the EC boards. Typically 5
to 10 devices are driven by one EC.
Time signals for process synchronization are broadcasted
from a central timing system to all ECs via serial bus(MIL-STD-1563B) and Timing InterFaces (TIF).
Each VME node is equipped with CP, MP, TIF and 1. .. 9
ECs. A diagram of the components is shown in fig. 1.
Actually 33 operating computers are used in the main
control room and in several local consoles close to experi-

S01SRA07
Status Reports: Accelerators

27
27

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S01SRA07

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA08

VME Applications to the Daresbury SRS Control System
B.G.Martlew,M.McCarthy,W.R.Rawlinson
SERC Daresbu:ry Laboratory,Warrington WA4 4AD UK

Abs1rac1

The control system for the Daresbury SRS has recently
been extended with a VME based alarm system which isoperational. A further development is a steering system toprovide servo control of the electron beam orbit position in
the storage ring.

ring and Beamports. CCC3205B provides control for the
beamlines with one serial CAMAC highway. Local control at
the plant is implemented with Tandy 102 computers. The total
parameter count presently stands at approximately 1800.

CCC3210

I. INTRODUCTION
The Daresbury SRS is a 2 Gev electron storage ring
dedicated to providing synchrotron radiation to approximately
32 stations on 10 beamlines. It came into operation in mid
1981 and was upgraded with a high brightness lattice in 1987.
The control system for the SRS was designed andconstructed in the period 1975-1980 and the originalcomputers were upgraded in 1985.
The original control system provided an alarm condition
monitoring system with a sampling resolution of 2 minutes.
Recently, a dedicated VME system has been added which
provides alarm monitoring and indication with sampling at thelevel of 5 seconds.
The high brightness lattice upgrade in 1987 reduced thesource size by a factor of 10 and this led to difficulties withbeam alignment and positional drift over the period of a stored
beam. Work is under way to provide a VME based beamsteering system to provide servo control of the electron beam
position.
This paper will give a brief description of the SRS
control system followed by a description of the new alarmsystem. A description of the beam steering system and its
present status will be given.

Console1

ConsoleConsole2

3

Linear accelerator,
Bemnlines
Booster,Storage ring andbeamports
Fig 1. The SRS Control system

CCC3210 is offline to the control system and is used forprogramme development and testing.
High level programming is done in RTL/2 with more
recent applications written in C.
III. THE ALARM SYSTEM

II.THE SRS CONTROL SYSTEMThe SRS control system consists of a network of 4
Concurrent Computer Corporation(CCC) 3200 seriescomputers as shown in Fig 1.
All computers in the network have a CAMAC system
crate and communicate via CAMAC fast serial data links.
CCC3230 is the operator interface computer providing service
to three operator consoles in the main control room via a
CAMAC parallel branch. Two of the. operator consoles
contain a colour display and keyboard (Tektronix 4207), aknob and tracker ball and a monochrome graphics display. The
third console contains a Tektronix 4207 colour display andkeyboard and serves as the personnel safety console.
CCC3205A and CCC3205B computers provide theinterface to the plant via serial CAMAC highways.
CCC3205A has two serial highways, one for the linear
accelerator and Booster synchrotron and one for the Storage

CCC3230

The original SRS alarm system was in operation for 9
years from the start up of the machine. Over this period, thesystem has been found to have several disadvantages:-

1. Noisy analogue input signals gave spurious alarmindication which lee! to alarms being ignored byoperators.
2. Alarm conditions were applied to large numbers ofparameters which led to 'swamping' of the alarm
display and the operators being presented withmore information than they could reasonably
handle.
3. The large number of alarmed parameters led todifficulties in administration of the system.
4. The 2 minute sampling rate meant that the system
was in fact no more than a fault indication systemrather than a true alarm system.

S01SRA08
Status Reports: Accelerators

31

31

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.ICALEPCS1991, Tsukuba, Japan<br /> (partial, pages 194 of 611)JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991-S01SRA09

Yao Chih-Yuan
Hefei National Synchrotron Radiation Laboratory
U.S.T.C.

BEPC project, the leaders of the project
decided early in 1985 that in order to reduce
development work and shorten the construction
period the new control system of SPEAR ringshould be adopted as the base for BEPC.
BEPC
control system isatypicalcentralized
control system. A
VAXll/750
serves as the central control
computer.
SerialCAMAC systems are the baseforequipment interfacing.

Abstract
Three accelerator facilities were built
in the past few years, the 2.8 GeV electron
positron collider BEPC, the heavy ion SSC
cyclotron accelerator HIRFL and the 800 MeV
synchrotron radiation storage ring HESYRL.
Aimed at different research areas,
they
represent a new generation of accelerator in
China.
This
reportdescribes
thedesignphilosophy, the structure, performance aswell as future improvements of the control
systems of the these facilities.

1. System Configuration
Fig. 1is a block diagram of BEPC
control system. The system is functionallydivided into three levels.

I. INTRODUCTION
The
development
andresearchofaccelerators in China has made good progressin the past thirty years. Many low energy
accelerators for research and application
have been constructed, including high voltage
type
accelerator,
cyclotron,
linearaccelerator, betatron etc. Their application
covers a wide range: medical
treatment,
industrial
irradiation,
non-destructive
inspection, isotope production and many otherfields. The three newly completed high andmedium energy accelerator facilities, Beijing
electron positron collider(BEPC),
Lanzhouheavy ion research facility(HIRFL) and Hefei
synchrotron radiation source(HESYRL), aimedatdifferent scientific researchareas,
represent a new generation of accelerator
facilities.
Early accelerators are mostly controlled
by panel meter and push button type manualcontrol system. Application of microcomputersto accelerator control system started at the
beginning of SO's when microcomputers were
becoming popular in China.
This paper is not intended to be a
general survey. Control systems of the threenewaccelerator
facilities,
which
are
relatively
larger
in
scale
and
more
complicate in structure, are described herewith the emphasis on the system architecture.

UNIBUS

VAXll/150

J X G'>.PH.IC DISPUY
3
TCl.01 PANEL 'x

m:aO?EP.A'ICR CCNSOt..E

First, at the center of the system isthe DEC VAXll/750 computer, which is equippedwith a asynchronous serial interface board
for connecting terminals and knobs, a DRll-B
OMA interface for connecting color display
monitors, and other standard peripherals suchas hard disks, printers, tape drivers etc. A
SLAC designed Vax CAMAC Channel(VCC) is the
key element in data communication network. It
is a DMA controller to interface .VAXll/750
UNIBUS with CAMAC system. Two CAMAC system
crates are controlled by the VCC, one for the
linear accelerator the other for the storage
ring. one system crate houses several serial
branch driver modules and each branch driver
starts a fiber optic serial high way loop
which connects up to 7 user CAMAC crates.
The
second level is the local
controlstations formed by user crates. I/O functions
are performed by the local control stations.
Each local control substation controls one

II. BEPC CONTROL SYSTEM
BEPC
is
the
first
high
energyaccelerator
built
in China.
The
mainfacilities of BEPC are a 1.4 GeV electronlinear accelerator injector, a 1.4 GeV beamtransport line and a 2.8 GeV electron storage
ring. The project was started in 1984 andcompleted in 1989.
Because of the strict time table for the

S01SRA09
Status Reports: Accelerators

35

35

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

Accelerator Control Systems in China

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA10HESYRL Control System Status
Yao Chih-Yuan
Hefei National Synchrotron Radiation Laboratory
u.s.T.c.

Abstract
HESYRL synchrotron radiation
storagering was completed in 1989 and has been incommissioning since then. Now it has met its
designspecification and is
ready
for
synchrotron light experiments. Control systemof the project was completed in 1989 and somemodifications were made during commissioning.
This
paper
describes
itspresent
configuration, status and upgrading plan.
I. INTRODUCTION

are executed on the PCs.
storage ring and beam transport line
equipments are controlled and monitored by
local control micros. The LCMs are locatednear the equipments. Each LCM controls only
one or one type of equipments.

CC«SOLE PC

Hefei National Synchrotron Laboratory(HESYRL) is a dedicated synchrotron lightsource. It's main facilities are a 200 MeV
electron linear accelerator, a beam transport
line, an 800 MeV electron storage ring andthe experiment stations.
Design and construction of the ring andlinac control system started in Oct. 1984.
The linac control system was completed in1987
and the ring control
systemwascompleted in 1989. Modifications have been
made to the system during two years ofmachine commissioning, including RF control,
vacuum monitoring and new control programs.
The ring control system is a distributed
computer
control system consistsofaPDPll/45 computer, two PCs, a communication
microcomputer system(CMM) and up to 40 local
control microcomputer systems(LCM).
The linac control is essentiallyamanual control system.
Atiming system consisting oftwomicrocomputersprovidesallnecessarytriggering signals for the linac and theinjection system.
II. RING CONTROL SYSTEM
A. system Configuration
Fig.1 is a block diagram of the ring
control system.
Two
PCs perform themaincontrolfunction. Console display and command input
are also performed on the PCs. The PDPll/45
minicomputer system, originally planned to be
employed as the main control computer,is now
only a part of communication system becauseof its limited memory and poor
displayability. The two PCs are connected to the
DZll ports of the PDP. Ring control programs

CCM-UNICATIOOMICRO CCMPUTER'IO S'IORAGE RING B';}.JIFMrnr

FIG. 1BLOCK DIAGIW1 OF HESYRL RING CCffi'ROL SYS'I'Eli

A LCM consists Of a MULTIBUS crate, a
SBC80/24 or SBC80/20-4 CPU board, a homedesignedserialinterfaceandmemoryexpansion board(HCOM) for communication and afewinterfaceboardsforequipmentinterfacing.
system communication is performed at twolevels. The console PCs exchange data andcommands with PDP through its serial lines.
The
PDP communicates with LCMs via
adedicated communication microcomputer system,
which is a MULTIBUS system composed of amaster
SBC
80/24
CPU
board,a
DMA
communication board and between 1 to 10
intelligent communication boards(COMM).
The COMM board is similar to Intel
SBC544 intelligent asynchronous communication
board. It has a zao CPU, 4 serial ports,onboard RAM/ROM and dual port RAM memory which
can be accessed by both a MULTIBUS master andthe on board Z80. One COMM board can handle
communication with 4 LCMs.

S01SRA10
40

Status Reports: Accelerators

40

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA11

The Control System of HIRFL
Jiao Tianshu, Li Tianyou,Ma Siwen,
Chu Zhensheng, Huang Tuanhua, Zhou Xun,
Wang Zhen,Shen Zhiqing
Institute of Modern Physics, Accadmia, Sinica
No.57, Nanchang Road, Lanzhou

and commissioning at the elementary level. Controlling the HIRFL process is implementing at ahigh level.

I. Introduction

The Heavy Ion Research Facility in Lanzhou(HIRFL) is a multi-purpose and variable energy
machine designed to accelerate wide range ofions. (I) In order to obtain a designed beam(particale and energy) and to transport it toa proper experimental areas in a short time, it re.
quires to modify a great number of parameters,
this cannot be easily achieved without the help of
a computer.
The control system design and construction
was started in 1983. First of all, some local
control station of accelerator subsystems were finished in 1988 and satisfied the needs of operating

2. The brief description of control system
Fig.I shows the general layout of the control
system for HIRFL.(2) It is based on CAMAC distributed process configuration.(3)(1) The local computer control stations are designed according to the accerlerator subsystems,
such as Magnet, R.F, Vacuum, Injection and Extraction, Beam line etc. and· were finished in 1988.
They can meet the case of beam tuning and accelerator operating at elementary level.
CONSOLECAM AC

1/0 modules<

CAMAC-1/0
modulca

ALL YA!UllTY OF
POWER SUPPLY

ACB-auxilla.ry Cootrollu Bus

ACC- auiillUY· c;,at; cOnyrollcr
Dct..:..n.ttaway Communic.ation• Liiik

Fig. lThe block diagram of HIRFL control system

S01SRA11
44

Status Reports: Accelerators

44

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA12Control System for a Heavy-Ion Accelerator Complex K4 - KlO
V. M. Kotov and R. Pose
Joint Institute for Nuclear ResearchLaboratory of Computing Techniques and Automation
Dubna, USSR
Abstract
Control systems for newly created accelerators, perhaps forthe first time, may be designed almost only around international standards for communication and control techniques.
This is also true for the project of a control system for theaccelerator complex K4-K10 at the Joint Institute for Nuclear
Research Dubna. Nevertheless, open systems architecture withconstruction principles being essential for modem systems ofsuch big devices as particle accelerators leaves designers
enough possibilities for solving even very sophisticatedproblems.
I.

INTRODUCTION

The control system of the heavy-ion accelerator complex
K4-K10 is similar to the systems developed for controlling theaccelerators of other physical laboratories the experience of
which was used in preparing the given project [1,2,3}.
Nevertheless irrespective of the similarity of accelerators andcontrol problems there are no equal control systems. Thisdepends not only on the differences of accelerators as such but
first of all on the time the system was designed and on thepresent state of computing and communication technique andon the special features of the system architecture, which allow
new technical acquisitions during the realisation.

II. THE ARCHITECTURE OF THE K4-K10
CONTROL SYSTEM
The architecture of the K4-Kl0 control system is based ona two level distributed computing system (Fig. 1). The upper
level uses a modular system IEEE 1296 (Multibus) from theSiemens AG [4] (SIMICRO) as well as workstations with
UNIX and X Window in the Central Control Room, and is
integrated into a system via a Local Area Network (IEEE802.3).
The standard IEEE 1296 and its realisation in the
SIMICRO products allows a high computing power inside
every crate (the CPU on-board in the SC™-systems based on
RISC processors providing 5 MIPS and more) as well as theuse of CPU with embedded PC/AT 386 in the OSM™ and
AMS™ systems 1• These SIMICRO systems are equippedwith a complete set of communication modules for LAN in theIEEE 802.XX standards.
The functions of the system at this level are supported by
the operating system SORIX™ - a UNIX™ Real Timeversion (reaction time for interrupt signals::;. 100 µsec.) andlTM SIMICRO, SX, SORIX, OSM, ASM - Trade Marks of
SIEMENS AG
2TM UNIX - Trade Mark of AT & T

permit an exit to LAN via TCP/IP protocols2.
Therefore, using the possibilities of the 7 level scheme for
the OSI model of open systems, the architecture of the upper
level of the control system provides an output to the equipment and to the real time programs as well as a complete
support for the TCP/IP protocols for an output to a LAN IEEE
802.XX. According to the loading of the network at this levelby means of bridges one may distinguish two LAN segments:
one for the workstations WS in the Central Control Roomrunning under UNIX and the other for the Front End
Computing. The latter are mainly crates in the IEEE 1296
standard with Real Time UNIX, joining the node computers fordata acquisition and handling in the control mode as well asthat for graphics and monitoring. They are equipped with terminals, Touch Screens and other man-machine communication
devices.
The lower level of the distributed computing system directly corresponding to the equipment and executing devices
and based on standards for industrial systems (for example inthe VEPP4 [5] CAMAC instrumentation is used at this level)
is connected to the upper level by means of the communication
environment FIELD BUS (MIL-1553-B). This standard
mostly agrees with the demands for a multidrop bus and in1983 was proposed as a standard protocol for the field bus inaccelerator control systems (6]. Together with well developed
hand shaking features for the message transfer between bus
controllers and remote terminals (RT) this standard allows
simple and cheap data transfer to single serving devices, fulfilling simplest functions. For connecting digital measuring devices to the upper level the standard IEEE 488.X is used.
For the most part all the bus controllers (BC) MIL-1553-B
are placed on the upper level of the control system. They provide the interfacing of the node computing system to the lower
level equipment. The BC for the K4-Kl0 control system isdeveloped on the basis of a processor module in the Multibus
II standard, designed in the Laboratory of Computing
Technique and Automation of the JINR using the VLSI of a
32-bit microprocessor set Kl839 software-compatible with amicro VAX [7]. The interface controller for the MIL-1553 bus
is a piggy-back module for the CPU board. One such BC may
control 30 standard interfaces (Remote Terminals) on each bus.
The standard interface of the MIL-1553 bus has to provide
a prompt/reply regime. In this case a microprocessor isneeded. In the case of simple messages of the type "adjust
and/or read" it has to handle the transfer directly.
The use of the MIL-1553 for the communication with theequipment together with the time synchronization channel
allows one to put the real time mode on the lowest control
level. Such a solution proposed and realized in the GSI [1]relieves the upper control level of the real time business andallows on this level the use of the LAN 802.3 alone without a
TOKEN RING (IEEE802.5) as it is done for the SPS/LEP in
CERN (2).

S01SRA12
Status Reports: Accelerators

47

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU01

Future Directions in Controlling the LAMPF-PSR
Accelerator Complex at Los Alamos National Laboratory*
R. Stuewe, S. Schaller, E. Bjorklund, M. Bums,
T. Callaway, G. Carr, S. Cohen, D. Kubicek,
M. Harrington, R. Poore, and D. Schultz
Los Alamos National Laboratory
Los Alamos, NM llS.A. 87545
Abstract

Accelerator

Four interrelated projects are underway whose purpose is tomigrate the LAMPF-PSR Accelerator Complex control
systems to a system with a common set of hardware andsoftware components. Project goals address problems inperformance, maintenance and growth potential. Front-end
hardware, operator interface hardware and software, computer
systems, network systems and data system software are being
simultaneously upgraded as part of these efforts. The efforts
are being coordinated to provide for a smooth and timely
migration to a client-server model-based data acquisition andcontrol system. An increased use of distributed intelligence atboth the front-end and the operator interface is a key element of
the projects.*

MasterTimer
Controls
Computers,.___..._ _ Ethernet - - - ' ' - - - - - - - " - - - - t i >I. INTRODUCTION
Figure 1. The LAMPP RICE System.

The integration of the Los Alamos Meson Physics Facility(LAMPF) and the Proton Storage Ring (PSR) control systems
is presenting a series of problems for the operations andsupport personnel using the two systems. The two systems
were developed independently using different personnel,
different underlying philosophies and different equipment but
developed interdependency when the operating and support
groups were combined in 1988. A detailed discussion of thecurrent control systems is presented in a companion paper inthese proceedings.

II. PROBLEMS AND IMP ACT
A. LAMPP RICE System
The LAMPF Control System (LCS) was built upon the
LAMPP-designed Remote Instrumentation and Control
Equipment (RICE) System. RICE is the hardware and softwareinterface between the actual accelerator devices, such as
magnets and beam-line instrumentation, and the software that
operators and developers use to control beams.This system is
illustrated in Figure 1. RICE presently utilizes 73 of 80
possible modules handling 10,000 data and control points
distributed along approximately 2 km of beam channels.

The RICE system has several limitations. First, RICE
allows only one timed data request per beam pulse. At the low
repetition rates characteristic of tuning beams, this feature cancause requests for device readout to become deeply queued andcan cause tuning mistakes as operators react to "old" data.
Second, the RICE star architecture places limits on the
maximum data rates. Third, the RICE system is fairly rigid.
For example, the current implementation of the linac harp
system permits data from only two harps at any time andrequires availability of greater than 50% of the RICE system
to obtain that data. Fourth, there is a need for higher accuracy
and precision than is available with RICE. Finally, it isestimated that 30% of the parts in the RICE system are nolonger commercially available.

B. P SR /SS System
The PSR Control System is based upon a series of PDP11 computers known as Instrumentation Sub-Systems (ISSes)
which communicate with a central VAX system using serial
CAMAC [1]. This is illustrated in Figure 2.

*Work supported by the US Department of Energy

S02SRU01
50

Status Reports: UpgradeContent from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU02

Common Control System for the CERN accelerators
R. Rausch, Ch. Serre, editors
CERN - 1211Geneva23 - CH

Abstract
The PS and SPS Accelerator Control Systems are
becoming obsolete and need urgent rejuvenation. After acontrol users forum, where users expressed their needs, twomain Working Groups were set up, consisting of Control andEquipment Specialists and experienced Machine Operators.
One Working Group studied the architecture and the front-end
processing and the other a common approach to theapplication software needed to run the CERN accelerator
complex. The paper presents the technical conclusions of theirwork and the policy to implement it, taking into account thenecessity to operate both machines without interruption of the
Physics Program.

I. INTRODUCTION
The complex of CERN accelerators is divided in two setsof different characteristics. The PS set is constituted of ten
different accelerators which represent the source of all particles
accelerated in CERN (maintained by PS division); they aresmall and mainly fast cycling machines. The SL set iscomposed of two bigger machines, the SPS and LEP which
are slow cycling accelerator or particles colliders (maintained
by SL division). The two sets are, broadly speaking, separated
by the Swiss-French frontier.
The PS and SPS accelerators control systems wereconceived and implemented some 15 years ago. They are basedon 16 bit computers, with a proprietary operating system anda star network. These components do not permit the use ofmodern industrial software packages and communication
standards. Their maintenance is expensive and is becoming
more and more difficult. The consolidation of the control
systems has become necessary and urgent, and it was felt thatone should profit from this consolidation to aim at a real
convergence of CERN's accelerator control systems.
In order to work out a common technical solution, thecollaboration between the PS and SL control groups has been
reinforced considerably since the beginning of the year 1990.
A common consolidation project is the result of thiscollaboration and it was elaborated by working groups of thetwo divisions. Joint working groups were set up to study thedifferent aspects of the project and to reach the necessaryconsensus on what should be done. [l]The first working group designed the common control
system architecture, the front end processing and discussed the
network characteristics, the local control facilities and theinterface between the controls and equipment groups.
The second working group defined a common approach tothe application software needed to run the accelerators,
discussed the programming environment and the possible

software tools and studied the future layout of the work placein the control rooms.
Other groups, linked with the two previous ones, worked
on specific subjects like the Equipment Control Protocols, thecommon on-line data base, the Man Machine Interface, theTiming and Synchronization problems. They generally worked
out common solutions which are today in the implementation
phase.

II. ARCHITECTURE
The new Common Control System consists of threelayers: Figure 1- the control room layer with its consoles and central
servers;- the front end computing layer distributed around theaccelerators;- the equipment control layer with the Equipment Control
Assembly (ECA) crates which form part of the equipment.
The hardware and software used on each level reflect theconsiderable variety of accelerator components to becontrolled. The new architecture offers more flexibility andwill allow continuous partial upgrading as technology
evolves.

A. Control Room Layer--

It must fulfil two main functions:
Provide the operators with a reliable, user-friendly interface
to the accelerators. Modern workstations running thecommercial software package X - windows with a suitablecommercial tool kit to construct the user interface werechosen. The operator work places are very demanding interms of graphic and interaction facilities. The key point inselecting the new platforms is the interoperability with theexisting equipment and the portability of the software
between them. We hope the choices made, UNIX operating
system (OSF based in the future) with X-Window and
Motif tool kit and communication by the TCP/IP
protocol, will allow a smooth transition from one
generation of hardware to another.
Offer a number of central services through servers (which
are generally more powerful machines of the same familyas the workstations). These central services can be thecoordination of various control tasks, central data and filestorage, model computing and collection of alarms.

S02SRU02
54

Status Reports: UpgradeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU03

New Control Architecture for the SPS Accelerator at CERN
K.H. Kissler and R. Rausch
European Organization for Nuclear Research
CERN - 1211Geneva23 - CH

Abstract
The Control System for the 450 Gev proton
accelerator SPS at CERN was conceived and implemented
some 18 years ago. The 16 Bit minicomputers with theirproprietary operating system and interconnection with adedicated network do not permit the use of modern
workstations, international communication standards andindustrial software packages. The upgrading of the system
has therefore become necessary.
After a short review of the history and the current
state of the SPS control system, the paper describes how
CERN's new control architecture, which will be common to
all accelerators, will be realized at the SPS. The migration
path ensuring a smooth transition to the final system isoutlined. Once the SPS upgrade is complete and following
some enhancements to the LEP control system, the operator
in the SPS/LEP control center will be working in a single
uniform control environment.

I. HISTORIC REVIEWThe SPS control system was designed in 1972 andbrought into operation in June 1976. By that time no standard
communication network protocol existed and pioneering
work had to be done to interconnect initially some twenty
minicomputers located in 6 equidistant equipment buildings
and one central control room around the 7 Km circumferenceof the SPS accelerator ring. The minicomputers used were
NORDIO from Norsk Data with 16 K.Byte core memocy and
128 KByte drum mass storage. The equipment interface
consisted of CAMAC crates connected to the computer's I/0
bus with CAMAC modules linked directly to some of thebeam instrumentation while all other equipment wascontrolled via a CERN designed multiplex (.MPX) systemcomposed of a serial field bus, MPX crates and user
dedicated MPX modules.
On the software side, the manufacturer's operating
system has been modified to suit the particular real-time
control requirements of our distributed multiprocessor
environment. While most of the software drivers were written
in computer assembly code, an interpreter, called NODAL,
has been developed to provide easy interaction between theoperator and the equipment connected to CAMAC, remote
access facilities and network functions. Every computer had aresident NODAL interpreter allowing to use it in interactivemode and in stand alone operation for test andcommissioning purposes. No one computer would be theover-all master of the control system and the message
transfer system was designed so that any computer could passa message to any other without a preset master-slave
relationship, implying that the system was completely
symmetrical and transparent [1].
IL PRESENT SITUATION
Since the start-up of the SPS in 1976, the control
system has been extended to cope with the changing
requirements of the accelerator which was initially designed
as a pulsed proton accelerator for fixed target experiments,
then modified to act as a proton/antiproton storage ring forcollider physics, and now also as, an injector to LEP,
accelerating electrons and positrons interleaved with proton
acceleration. Such evolution has required a great flexibilityof the control system with the ability to modify programs asnecessary in a simple way and to add computers, network
links and equipment interfaces where and when required,sometimes even during the exploitation of the accelerator
complex.
Today the SPS control system is composed of 52
operational process and central computers (.NORDIOO)
interconnected by a multi-star network with 6 Message
Handling Computers (MHC). The interfacing between
computers and accelerator equipment is done by CAMAC(72 crates and 450 modules) and by the MPX system (693crates and 5500 modules). Figure 1.
With the need to operate the SPS in a supercycle
mode when using it as a LEP injector, major additions had to
be made to the control system since about 1986. A more
flexible and versatile exploitation of many accelerator
components like beam monitors and pulsed power converters
was required. At the equipment level, this requirement has
led to the use of 8 Bit and 16 Bit microprocessor based
systems, embedded in G64bus and VMEbus crates. These
Equipment Control Assemblies (ECAs) are connected to theappropriate NORDlOO process computer via 1553 field bus
segments and a VMEbus crate housing the bus controllers
and linked to the computer's I/O bus.
In the accelerator control room, Apollo workstations
where installed to cope with the more complex supercycle
operation. These communicate with each other and with an

S02SRU03
Status Reports: Upgrade

59

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU04

The Next Generation Control System of GANIL
T.T. Luong, L. David, E. Ucorche, M. UlrichGrand Accelerateur National d'Ions Lourds
BP 5027 -F 14021 CAEN Cedex, FRANCE

Abstract
The existing computer control system of GANIL is being
renewed to fulfil the increasing requirements of the accelerator
operation. This medium term major improvement is aiming at
providing the physicists with a wider range of ion beams ofhigher quality under more flexible and reliable conditions.
This paper gives a short description of the new control
system envisioned. It consists of a three layer distributed
architecture federating a VAX6000-410NMS host computer, areal time control system made up of a dual host VAX3800 andworkstation based operator consoles, and at the frontend
segment: VME and CA.MAC processors running under the
V AXELN operating system, and programmable logic
controllers for local controls.
The basic issues with regard to architecture, humaninterface, information management, ... are discussed. Lastly,
first implementations and operation results are presented.

I. INTRODUCTION
The GANIL laboratory has been operating since 1983 an
accelerator complex consisting of three machines in cascade : acompact injector cyclotron and two fourfold separated sector
cyclotrons (Fig. 1).

This facility provides the experimenters with fast heavy
ion beams for fundamental research in the fields of nuclear
physics, atomic physics and solid state physics, as well as forindustrial applications.
Significant upgrades were carried out these last few years
to augment the energy of heaviest ion beams and to increase
their intensities by making use of new ECR source.
Acceleration at GANIL henceforth encompasses ion species,
from carbon to uranium, with beam energy ranging from up to
95 MeV per nucleon for the ions with masses up to 40 u to
24 MeV per nucleon for the heaviest ions.
The rejuvenation of the GANIL computer control system
is under way, aiming at two main goals : l/supersedes thepresent control system which is technologically outmoded anddriven to its ultimate capabilities, 2/matches the performancesof the emerging control system with the widening scope of theservices in a large variety of domains (beam setting and tuning,surveillance, diagnostics, expertise, ... ) within an operator
friendly environment.
This paper emphasizes the main topics to be consideredwhen designing and implementing our next generation control
system. In particular, stress is laid on using : 1/acknowleged
industry or international open standard hardware and software
products to achieve minimization of investment over the life of
the system, 2/modular structures to make easier future
expansions.

ACCELERATOR CONTROL SYSTEM

11.1. General

Figure 1. Accelerator and Experimental Areas

The first generation control system adopted a centralizedarchitecture built with a 16bit minicomputer (MITRA 625)
which ruled over other kinds of processors devoted to local or
ancillary tasks : 8bit (JCAMIO/INTEL 8080) and 16bit(DIVA/MC68K) microprocessor CAMAC controllers,
programmable logic controllers (APS30-12 and PB400). These
processors are connected to the MITRA via two bit-serial
2.5 MHz CAMAC loops which bind up 40 crates with about
800 attached modules.
This tight coupling with the computer MITRA
considering architecture and non portable software makes thecontrol system vuinerable with regard to collapse, obsolescenceand ageing of that computer.
In contrast, the GANIL control system to come is basedon a distributed architecture. Intelligence is therefore handed
over to local processors which are responsible for dedicated field
operations. The chosen topology features three functional
levels which intercommunicate by means of an Ethernet local
area network (LAN) :S02SRU04
Status Reports: Upgrade

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

65

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU05

REPLACEMENT OF THE ISIS CONTROL SYSTEM
R.P. Mannix, C.J. Barton, D.M. Brownless, J.C. Kerr
Rutherford Appleton Laboratory, DIDCOT, Oxon., OXll OQX, U.K

Abstract
In operation since 1985, ISIS is the world's most powerfulpulsed spallation neutron source. The decision has beentaken to replace the existing ISIS control system, which has
been in use for over ten years. The problems of such a project, given the legacy of processor specific hardware andsoftware are discussed, along with the problems associatedwith incorporating existing interface hardware into any new
system. Present progress using commercial workstation
based control software is presented with, an assessment of
the benefits and pitfalls of such an approach.

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

age ISIS experiment lasts two days, within which several
data taking runs, all of which are essential, must be performed. These sorts of breakdowns, although infrequent, arehighly undesirable.

The new system is required to take over all the current
functions of the existing control (at least as well) and havethe capability for much increased data storage, greater reliability, easy reconfiguration and extension and almost transparent communications with other computer systems.
The available effort is about 25% of that when the original system was created, when both decreases in staff and theload of supporting the existing system are taken into account.

I. INTRODUCTION

II. PROJECT PLAN

ISIS is based on an 800MeV proton synchrotron, running
at 50Hz, providing an average beam current of 120µA onto a
Uranium target. The injector, synchrotron, extracted proton
beam line and target station have been under control of thepresent system both during commissioning (1980-85) andoperation. Work is in progress to attain the design current of
200µA within two years.

The system currently being developed is based on theVista Controls 1 software suite, and the Hytec Electronics2
Ethernet CAMAC Crate Controller (ECC). The new software
provides a fully distributed database driven control systemwith a graphical interface over a number of DECnet nodes(currently VMS only although work is in hand on a POSIXcompliant version). Each control or monitoring object is referred to as a channel and, by using the channel name, control screens can be generated with an interactive draw package. Our current development system is based on two DEC
VAXstation 3100 colour workstations and two DEC VT1300
X-terminals, although it is not clear that the choice of processors is optimal. Figure 2 shows a general arrangement of the
proposed new system, based on Ethernet (an alternativetransmission medium would be FDDI).

The control system (old CERN-SPS pattern), is based on
5 GEC computers, assembly language Data Modules, a general purpose multiplex system for equipment interfacing(MPX) , CAMAC based operator interfaces (see Fig. 1) andan interpretive control language. There are approximately
15000 lines of data module source code. The equipment interface consists of 700 modules in 70 crates. There are several hundred control programs in use.
The present control computers are very modest in power
and are very limited in storage capacity. The operating system allows us to control hardware from a number of concurrent interpreter processes on each processor. High priority
processes communicating with hardware completely lock out
all others. Communication with other systems is nonexistent, peripherals such as floppy disks are obsolete andunsupported, backups require shutting down the control system and maintenance is expensive (24hr cover is essential).
The various branches of the interface hardware are tied explicitly to particular processors- reconfiguring after a processor failure is impossible- a serious disk drive fault can,and has, shut down the accelerator for a few hours. An aver-

The use of channel names, database and handlers (equipment routines) maps very well on to our existing system
based on Data Modules. The graphical interface provided
with the new software should enable the functions of 75% of
the control software to be replaced without recourse to writing code.
The system-wide nature of the databases and the networked nature of the CAMAC driver crates makes access toall equipment possible from any processor- somethingwhich was not previously possible.
Terminals with any level of access to the control system
can easily be added anywhere on site (if desirable!). A con-

S02SRU05
Status Reports: Upgrade71

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU06

Upgrading the Control System for the Accelerators at The Svedberg Laboratory
KJ. Gajewski, L. Thuresson, 0. Johansson

The Svedberg Laboratory
Uppsala University
P.O. Box 533, 751 21 Uppsala, Sweden

Abstract

Two accelerators at The Svedberg Laboratory in Uppsala,the Gustaf Werner cyclotron and the CELSIUS ring, will get a
new control system. At present both the cyclotron and thering have their own control systems based on S99 and PDP11 minicomputers respectively. There are also a number ofsubsystems which are controlled separately from the standalone PC based consoles (ECR ion source, electron cooler,vacuum system). The goal of the rejuvenation is to integrate
all existing control systems and provide the new system withan uniform operators interface based on workstations. The
obsolete S99 microcomputers will be substituted with a VME
system and all subsystems will be connected to the Ethernet.
The upgrade strategy enabling the transformation of thesystem without any long shut-down period is discussed.
Hardware and software planned for the upgrade is presented
together with a discussion of expected problems.

1. INTRODUCTION

The control systems for Gustav Werner cyclotron and the
CELSIUS ring have been designed at different times. The
cyclotron [1] after a major rebuilding started its operation in1986 The main cyclotron· control system, based on S99
microcomputers, covers the cyclotron and all beam lines. The
radiation protection system for the whole laboratory area isalso based on S99 microcomputers with an 286/PC as aconsole. Another 386/PC connected to a Programmable Logic
Controller (PLC) controls the external ECR ion source. The
CELSIUS control systems is based on the LEAR control
system from CERN slightly adapted to our needs. The system
is based on a PDP-11/73 minicomputer connected via
CAMAC hardware to the accelerator equipment. This systemenables to control all function generators and all staticparameters but these for the electron cooler. The electron
cooler is controlled independently from an IBM PC. Someother subsystems, both on the cyclotron and the storage ringside, are also controlled from the 286/386/PCs. From the very
beginning the work on these control systems was completely
independent - there were separate teams for each machine (thecyclotron and the ring) and there was no cooperation between
them. It all resulted in two distinct control systems withdifferent philosophy and incompatible hardware solutions.
After achieving the production stage of operation by thecyclotron and approaching the same stage by the CELSIUS
ring a need for a common control system became obvious.
Some organizational changes (creating one control group for
cyclotron and the ring) should help to achieve this goal. The
cyclotron and the ring is each controlled from its own control
room with very limited possibilities to control or even only
access the information from the other machine. This is highly
unsatisfactory and the new control system will enable tocontrol both machines from either of the control rooms. Someother features like beam sharing will be added. In order toimprove the situation we plan to connect all substems
together via an Ethernet and add a new user interface in theform of UNIX workstations. Some of the old S99
microcomputers will be substituted by a VME systemrunning VxWorks. Such approach will enable us to achieve
our objectives with minimal changes in the front end level and 'without any long shut down periods of the accelerators.

2. EXISTING CONTROL SYS1EM ARCHIJECTURE
A. Cyclotron
The cyclotron control system is based on Texas Instrument(TI) microcomputers. At the top level there are three TI S99

microcomputers. The control system data base resides in oneof the S99 systems, while the other two are mainly used as
operator interface to the system. At the hardware level most of
the equipment is connected to the control system by an inhouse-built microcontroller called General Interface (GI). A
single eUI'O-board includes a 1MS9995 microprocessor, analog
and digital 1/0 channels, a terminal port for local control and acustom-designed serial communication bus. Up to 31 devices
can be connected to this bus. Special interface boards ( also inhouse-built ) are used to connect the bus to the S99 systems.
There are about 150 GI's in the system. They are mainly usedin the beam transport- and RF-system. Apart from the GIcontrollers two industrial PLC units (Modicon 484 and 684)
are used in the vacuum- and RF-system, fig. 1.

Figure 1. The main control system of the cyclotron.
T - tenninal
PLC - Programmable Logic Controller
GI - General Interface (front-end controller)

The S99 systems runs TX990, a multitasking operating
system from TI. Today both hardware and software support for
S99 is very limited. Most of the control system software is
written in assembly language. All this makes maintenancedifficult and time consuming.
The radiation protection system also uses two S99
microcomputers. One S99 system handles the interlock andaccess control to the various experimental areas. The othermonitors the radiation level by means of some 50 radiation
detectors distributed in the laboratory. A 286/PC is used as

S02SRU06
78

Status Reports: UpgradeContent from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU07

Upgrading the BEPC Control System
Ya.ng Li-Ping, Wa.ng Li-Zheng, Liu Shi-Ya.o

Institute of High Energy Physics, Academia Sinica
P.O.Box 918, Beijing

Abstract
The BEPC control system has been put into operation and operated normally since the end of 1987. Three
years's experience shows this system can satisfy basicallythe operation requirements, also exhibits some disadvantages a.raised from the original centralized system architecture based on the VAX-VCC-CAMAC, such as slow response, bottle neck of VCC, less CPU power for control
etc.. This paper describes the method and procedure for
upgrading the BEPC control system which will be basedon DECnet and DEC-WS, and thus intend to upgrade thecontrol system architecture from the centralized to the distributed and improve the integral system performance.

1. The system status and its milestone
The project of BEPC control system was determined toadopt basically from the SPEAR control system in januaryof 1985. The prototype control system was constructedduring half year begun from september of 1985 at SLAC.
In the end of 1987, the control system realized the on-line
control and monitoring for the most equipments of BEPC
Storage Ring (SR) and its Transport Line (TL), and was
put into precommissioning at this time. The beam orbit
correction has been brought into commissioning in juneof 1989. The RF on-line control (including its ramp) wascompleted in march of 1990. Thus all the equipments of
SR and TL were controlled by the computer, and the VAX11/750 computer (the central control computer) becames
a member of DECnet of IHEP at the same time.
From the operation experiences in the past several years,
it seems that the philosophy and criterion for constructing
the BEPC control system are available, which resulted that
this system can be completed just on time schedule andhave a high reliability of system operation.

2. Several problems in system
The BEPC control system architecture follows the oldcentralized control model of the SPEAR, we had done incessantly some improving work on system level in the pastyea.rs, but still there a.re several problems which can't besolved. These problems a.re as follow:
1. The unique VAX-11/750 computer is used for the central control computer, its poor CPU power (only the 60
percent performance of VAX-11/780) limits the processing
speed of whole control system; Many batch jobs (about 16
control processes) always reside in the memory, moreverwhich heavily increases the load of VAX-11/750 computer
system. These causes slow the response and processing
speed of the entire system.

2. Due to we adopt the VAX-VCC-CAMAC (VCC, thatis, VAX CAMAC Channel) hardware system architecture,
one VAX QIO in CXCAMAC program takes 20 ms at lea.st,so the VCC forms the bottle-neck of the control systemcommunication. Especially it is obvious during the power
supply ramping, the other jobs can not be serviced quickly.
3. The current human-machine interface is supported by
two graphic colour monitors (resolution 512 x 512), twotouch-screen with several computerized knobs. Now one
monitor is occupied by one picture once a time, if we want
to see several pictures of the different requirements of accelerator commissioning simultaneously, it needs to add
more graphic display.
4. A fatal failure of the VAX-11/750 computer in the night(no on call service for computer) will break down the collider's operation. So a backup computer is needed to beconsidered.

3. System upgrade
After we analyzed the present conditions, we decided
to reform the control system from the current centralized
system to the distributed system and intend to solve those
problems for improving the whole system performace.
a. The distributed control system architecture

In order to reduce the heavy load of VAX-11/750 andincrease the speed of whole system responses, we divide
the current control jobs on VAX-11/750 to several partsand load them into different computer nodes. the upgrade
system will be based on the DECnet, its system a.rchitec-

S02SRU07
82

Status Reports: Upgrade3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The rejuvenation of TRISTAN control system
November l, 1991
T. Mimashi, J. Urakawa, S. Kurokawa, .T. Kawamoto, S. Takeda,
A. Akiyama,. K. Kudoh,. K. Komada, T. Naitoh
National Laboratory for High Energy Physics (KEK),
Tsukuba, Ibaraki 305, Japan
abstract
The current TRISTAN accelerator control system uses CAMAC as a front end electronics, and they are controlled by twenty
five Hitachi tninicomputer HIDIC 80's which are linked with an N-to-N token ring network. After five years from now, thesecomputers must be replaced. This is because of the life time of control system and we have to cope with the requirements
imposed by our future project such as the KEK B-Factory and the main ring photon factory projects. The rejuvenation of thiscontrol has to be done under some constraints such as the lack of manpower, limited time and financing. First we review the
problems of current control system, then the philosophy of the new generation control system is presented. Finally it isdiscussed how to move to the new generation control system from the current TRISTAN control system.

I.Introduction
Eight years have passed since the current control systemstarted the operation of1RISTAN accelerator (l] (2]. We
have a few weeks hardware maintenance for every six
month to keep our system highly reliable. The Hitachi
company takes care of these maintenance; they clean up
each computer, check its operation and replace some parts
such as fans, filters, etc. The disk of each computer isreplaced every five years. Hitachi also supports 24 hour"on call shift" for any computers troubles. Supported bythese maintenances, the current system has been working
very stable for these eight years.
Recently some of the I/0 devices become out of date,and it becomes difficult to repair these devices. In addition
to the problem, the current system can not satisfy theincreased reouirement of accelerator control. The latter ismainly causcid by the lack of CPU power and by the factthat L'1e process computers are an 16-bit machine. And
the network transfer capability is limited by the lack of
CPU power. In order to solve these problems, it is about
a time to start thinking about rejuvenation of 1RISTAN
control system.

2.Tbe TRISTAN complex and its control
systemThe accelerator complex of 1RISTAN consists of threemajor accelerators. A 400 m electron linac accelerates
electrons and positrons up to 2.5 Ge V and injects into theaccumulation ring. The accumulation ring accelerates
them up to 8 GeV and injects them to the main ring. The
main ring is an electron-positron collider . Two electron
bunches and two positron bunches are circulating in the
opposite direction and collide with each other at the midpoints of four straight sections. The current experimentruns at the center of mass energy of 29 GeV (3].
There are two independent control systems for theiroperation, one of the system takes care of the operation of
linear accelerator and the other takes care of that of theaccumulation ring and the main ring. This paper
discusses about the rejuvenation of the later system [2].
The 1RISTAN accelerator control system uses twenty-

85
Status Reports: Upgrade

five minicomputers and two large general-purpose
computers (The main frame: Hitachi HITAC and Fujitsu
FACOM) (4].
The minicomputers control hardware equipment andserve for man-machine communication. The general
purpose computers are used for the calculation of closed
orbit distortion correction which overload theminicomputers. The 25 distributed minicomputers,
Hitachi HID IC 80's, are connected by optical fiber cables
to form a 10 Mbps N-to-N token-ring network. Fromeach minicomputer, a CAMAC serial highway is extended
to the hardware equipment.
The miTlicomputers are classified into two groups: thesystem computers and the device-control computers. The
system computers control six operational consoles andtwo alarm-processing. The device-control computes are
three minicomputers for RF cavities control, five formagnets control, two for vacuum controls, two for beam
monitor, two for beam transportation, one for timing
control, one for program development, one for a gate way
between the control system and main frame and one forgeneral purpose.
ConsoleC<m1puur CenterFig 1: The current 1RISTAN accelerator control
systemS02SRU08
85

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S02SRU08

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingUpgrade Plan for the Control System of the KEK e-/e+ Linac
K. Furukawa, N. Kamikubota, K. Nakahara and I. Abe
National Laboratory for High Energy Physics (KEK)
Oho, Tsukuba, Ibaraki, 305 Japan
Abstract

A modern control system must interlink many kinds ofobjects and facilities. We may link it with advanced
technology, such as A.I. systems [3] or CASE tools. We may
also link to the control systems of other accelerators or
utilities, although some access limitation mechanism isneeded. We may further link the new control system at thenext upgrade time. Since the aecelerators for research projects
are always improving, we must combine many kinds ofcomponents to the control system. Thus we must make thecontrol system as flexible as possible.
In order to fulfill the requests we cannot rely on only one
hardware and software vender. We had better utilize
international and de facto standards. If we have muchcapacity to develop control components, we may define ourown standards. However, this would lead some difficulties infuture, as we have already experienced. We thus want toutilize currently available standards.
The lifetime of an accelerator control system is relatively
short, since electronics technology makes rapid progress anddemands for control systems are changeable. We must thus
always worry about future changes and upgrades of thecontrol system. Since new technology and future standards
are very likely to support existing standards, employing
standards is promising.
A desire for standards has grown among both users andvendors recently. If we adopt standards, (a) since there will
exist less ambiguity in the rules, we can develop reliable
technology based on it, (b) since the required components may
be obtained commercially, the development period may besubstantially reduced, (c) since the standards in other fields
may support each other, it may be easier to construct the entire
system. These facts are especially important in a small
system, such as in our case where manpower is limited.

The KEK 2.5-GeV linac has been operating since 1982.
However, in order to maintain reliable operation, the control
system should be upgraded within a few years. We plan toreplace the minicomputers and the main network connecting
them. Thus, the architecture of the control software will also
be revised. In the new system we should adopt software andhardware standards.
In the next control system we will employ the TCP/IP(DARPA) protocol suite for the main network and Unix
workstations to replace the minicomputers. For connections
to the local controllers, VME bus (IEEE 1014) will beutilized.

I. INTRODUCTION
The KEK 2.5-GeV linac provides electron and positron
beams for both the TRISTAN collider and the Photon Factorystorage ring. The linac control system was designed in 1979and has been successfully operating since its commissioning
in 1982. This old system is based on a distributed processor
network, comprising eight minicomputers and hundreds ofmicrocomputers, and on a control message exchange.
Detailed descriptions have been given elsewhere [l] [2].
We have recently had many requests for increased
functionality of the control system not included in the original
design. However system resources were inadequate toimplement the desired functionality. Furthermore, theminicomputers and the associated main network used in theold system will become unsupported by the computercompany in a couple of years. We had thus decided to replace
the main part of the control system and have carried out
studies regarding the new system.
As a result, we have decided to adapt international and defacto standards as much as possible. The recent advances inelectronic technology enable us to use common standards
among various fundamental components. We have employedthese standards in the new network system and computers.
For the main network the TCP/IP (DARPA) protocol suite on
the Ethernet (IEEE 802.3) media is utilized. Unix operating
systems on a group of workstations and VME-bus-based(IEEE 1014) computers were chosen for the main console
stations and subcontrol stations, respectively.
We describe below the design, current status and future of
the new linac control system.

A. TCP I IP Network.
Since equipment used for a accelerator is spread over along distance, we must use some kind of computer networks
between controllers. Since our linac is a pulsed high-power
RF machine, in the old system we attached importance tonoise elimination and have used proprietary fiber optic
networks (Loop-I). Since their hardware and software arededicated to the old system, we cannot utilize them for any
other configurations.
Thus, we had to think about introducing a more
standardized network, which can be adopted to various
configurations. In order to be independent from suppliers
TCP/IP protocol suite (DARPA) is most appropriate. We

II. SYSTEM COMPONENTS

S02SRU09
Status Reports: Upgrade

89

89Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S02SRU09

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU10The New Control System for TARN-2
S. Watanabe, M.Yoshizawa, J.Yoshizawa and T.Katayama
Institute for Nuclear Study, University of Tokyo, Tanashi, Tokyo 188, Japan
K.Aoki and K.Ohnishi
Sumitomo Heavy Industry, Tanashi, Tokyo 188, JapanThe new control system for the cooler-synchrotron.
TARN-2, is described. The new control system consistsof OPU's (work stations) and EXU (control computer)linked with the local area network. The text message isused to transfer the control commands and their results.
The control program CSA90 at EXU decodes the text mes·sage and executes it with the aid of the interface andperiodic control subroutines.
Both subroutines use
common sharable image composed of the status. values.
parameters and so on. The CAMAC. GP I B and RS232C a restandard interface at EXU.

extraction system. On the other hand, dynamic control
of both the Rr acceleration and ring magnet s~·stem[4],is also performed with the dedicated microcomputers with
e.xterna I memor~· modu Ies[ SJ. These systems we 11 regu Iate
TARN2 and now used without some troubles.
In 1990, basic design of the new computer control
system was started and was authorized to combine thepresent 1/0 controllers.
The present paper describes
the new control system of TARN2 during the development
phase.
Basic Architecture

Introduction
A heavy-ion synchrotron-cooler ring. TARN2 has been
constructed at the Institute for Nuclear Study. Univer·slty of Tok~·o. It has a maximum magnetic rigidlt~· of 6.2
Tm, corresponding to I.I GeV for protons and 0.37 Ge\/u
for ions of charge-to-mass ratio 1/2. Now the injector
is a sector-focusing cyclotron with K=68. The aims of
TARN2 are to study the acceleration. cooling and ext.rac·
tion of heavy ions and so on. Recently study of the"'eak beam monitoring and experiment of atomic ph~·sics isbeing continued. So the TARN2 control system must gives
reliable control functions and monitoring required todirect the up·to-date comple'( operations associated withon site experiment..

RS232COPU/LGU
VAlistation3100

EXU
MicroVAX3400

GPIB
CAMAC

OPU/LGUVAXstation3100

Ethernet

rig.I The new computer control system of TARN2
The present control system consists of the serial
CAMAC, GPIB and microcomputers(!]. The serial CAMAC
system covers static con tro I system such as beamtransport[2], injection. electron cool ing[3] and a beam

In the new control system. the actual device contro I and man-machine communication is made by theseparate units. The new system comprises OPU's(workstations) and EXU (control computer) linked withthe local area network. The new computer control system
of TARN2 is shown in fig. J.
The several kinds of workstations and PC's areused as OPU's. One is a VAXstation 3100. Another one isa microcomputer NEC-PC9801 with Ethernet board andOECnet·OOS. The uVAX 3400 is used as EXU and CAMAC. GPIB
and RS232c are also available in the EXU.
The OPU and EXU execute ta.sh to task communica·
tions between them. Before the message transmission.
OPU is linked with EXU. Then OPU and EXU transfer the
text message to each other. The format of text message
is formalized as shown in rig.2.
~t EXU. the received text message is stored into abuffer area by the interface process of contro I program
CSA90[6]. Subsequently the buffered text message istaken by interface subroutine and then executed by a pe·
riodic subroutine after decoding the text message. Bothsubroutines use a common sharable image composed of thestatus, values, parameters and so on. Both subroutines
are registered in the EXU and se Iect i ve Iy ca 11 ed by the
OPU using the subroutine number. The text message con·sists of this interface subroutine number and a commandmessage associated with a control procedure of the target devices. So the central job at OPU is to generate
the text message according to the associated control
procedures. The interval of a periodic subroutine canbe controlled by the associated control program CSA90.
The minimum interval time is 50 msec and can be in·creased by 50 msec integrals.
The communication network 'INS-Ethernet' is astandard network in our institute, whereas other network
system is used in our institute. The new control system

S02SRU10
Status Reports: Upgrade

93

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU11

A New Architecture for Fermilab's
Cryogenic Control System
J.Smolucba, A.Franck, K.Seino and S.Lackey
Fermi National Accelerator Laboratory•Box 500, Batavia, Illinois, 60510

Abstract
In order to achieve design energy in the Tevatron,
the magnet system will be operated at lower
temperatures.I The increased requirements ofoperating the Tevatron at lower temperatures
necessitated a major upgrade to the both the hardware
and software components of the cryogenic control
system. The new architecture is based on a
distributed topology which couples Fermilab
designed J/0 subsystems to high performance,
80386 execution processors via a variety of networks
including: Arenet, iPSB, and token ring.

hosting platform. We prefer it not only for thearchitectural advantages it offers, but also because of
the existing support services which have alreadybeen developed for our front end computers3. The
substantial amount of hardware and software that wewere able to inherit allowed us to concentrate themajority of our efforts on developing smaller, more
efficient J/O subsystems.

We partitioned the control system into six sectors
following the physical distribution of satellite
compressors around the Tevatron. Each sector
consists of four satellite refrigerators and their
Introduction
associated compressor. The sectors are connected bya token ring network to effect global
The addition of "cold compressors" to the communications.
Tevatron's satellite refrigeration system, as well as
the desire to dynamically balance the site's
Each satellite unit is controlled by an Intel, iSBC
distributed compressor load, introduced additional 386/120 single board computer. The five CPU· performance requirements on the cryogenic control modules reside in a common Multibus Il chassis
system. The required signal processing capabilities which is located at the compressor installation. The
basically doubled, raising the number of 1/0 loosely coupled architecture of Multibus Il is ideallyterminations to approximately 2,000 per satellite.
suited to this application. It supports protected,
independent execution for each processor module,
To effect global optimization the system's software while simultaneously providing fair access toalso required significant enhancements. These centralized system services. These services include: aincluded: support for global communications Tevatron clock distribution processor, a "machine
between refrigeration processors, an improved user data" (MDAT) J/O module, global shared memory, ainterface to the finite state machines, both code and DOS based 386PC/AT for system initialization andparameter down-loading capabilities, and diagnostics, and a token ring processor for global
substantially improved diagnostic support for the communications.
system's hardware.
Inter-processor communications within the sector
Together, the performance criteria exceeded the are accomplished over the parallel system bus (iPSB)
capabilities of the original, Z80 based control which, in conjunction with the message passing
system2. Therefore, a complete upgrade was protocol of Mutibus Il, functions as a 40 megabyte
per second local area network. The crate
warranted.
configuration is illustrated in Figure 1.

The new architecture
To achieve the desired performance with aminimum of hardware, we adopted a distributed
architecture centered around Intel's 32 bit, 80386 * Operated by the Universities Research Association Inc., under
microprocessor. Multibus Il was selected as thecontract with the U.S. Dept. of Energy.

S02SRU11
96

Status Reports: Upgrade96

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD01

Controls for the CERN Large Hadron Collider (LHC)K.H. Kissler, F. Perriollat, M. Rabany and G. Shering
CERN, CH-1211 Geneva 23

Abstract

CERN's planned large superconducting colliderproject
presents several new challenges to the Control System. These
are discussed along with current thinking as to how they can be
met. The high field superconducting magnets are subject to"persistent currents" which will require real time measurements
and control using a mathematical model on a 2-10 second timeinterval. This may be realised using direct links, multiplexedusing TDM, between the field equipment and central servers.
Quench control and avoidance will make new demands on speed
ofresponse,reliabilityandsurveillance. Theintegrationoflarge
quantities of industrially controlled equipment will be important. Much of the controls will be in common with LEP so aseamless integration of LHC and LEP controls will be sought.
A very large amount of new high-tech equipment will have to
be tested, assembled and installed in the LEP tunnel in a shorttime. The manpower and cost constraints will be much tighter
than previously. New approaches will have to be found to solve
many of these problems, with the additional constraint ofintegrating them into an existing framework.
I. LHC REQUIREMENTS

TheLarge Hadron Collider (LHC) is the major projectplanned by CERN[ 1], and will be its largest and most expensive
ever. It will present control problems much greater than thoseexperienced in earlier accelerators.

LHC and LEP controls. This will not be easy, in part due to themuch more difficult control problems ofLHC, in part due to thewide separation in time between the construction of the twosystems compared to the speed of evolution of controls technology. A challenge for LHC will therefore be to permit the use of
the latest and cheapest controls technology in such a way thatit integrates with existing technology, allows experience andalgorithms to be maintained, and does not demand a difficultand costly upgrade of existing systems. Another objective to beborne in mind is the aim of having a single control centre for thewhole of CERN on the LHC time scale.

II. MAGNETIC FIELD CONTROLThis will be the most difficult control problem for
LHC. The magnetic field is determined not only by the voltages
and currents from the 1400 power supplies, but also by "persistent currents" in the superconductor which vary with timedepending on the history of the magnetic cycle. Fortunately
HERA experience has shown these effects to be reproducible,
hence eventually calculable and correctable. Corrections will
be derived from magnet measurements during the construction
and from on-line measurements from reference magnets. The
final trimming will have to be done using single pilot bunchesof first 109 then l 011 protons. After full beam injection, continuous feedback control will be required, especially immediately
after injection and during beam squeezing.

LHC is a superconducting twin beam hadron (proton A. Modelling Server
initially) collider providing 7.7 TeV per beam at IO Tesla
bending field. The novel twin bore magnets in their cryostats
The solution envisaged is to use a modelling server
will be installed in the same 27 kilometre tunnel as the LEP which will re-calculate the power supply settings in real-time,machine. The scale of the control problem can be gauged in part using measurements from the reference magnets, beam meafrom the I792 dipole and 392 quadrupole cryostats filling most surements, past history of the magnetic cycle, and the magnetof the circumference, in part from the number, about 2000, of characteristic data-base. The update time will be between 2 andinsertion and corrector magnets and appropriate beam instru- 10 seconds. Tests on an Apollo DNlO'OOO in the LEP control
mentation. The difficulty of the control problem will come from system indicate that the computational load will not be beyond
the sensitivity of the superconducting magnets to quenching the sort of on-line computer we can expect in the LHC time
under beam loss from the 4725 bunches of 1011 protons at scale.Eachpowersupplywillhaveamicroprocessorcapableof
400.8MHz, making 85 lmA. This problem is exacerbated by the interpolating the required voltages and currents between modtime varying persistent currents and theneed for strong collision elling server updates.
insertions to achieve the targeted luminosity of over 1034• These
requirements will strain dynamic aperture and magnetic field B. Fast Communications
control to the very limit.
A new communications system is being studied for
As LHC will be built in the same tunnel as LEP, a lot LHC, in conjunction with SSC, in order to acquire the beam data
ofequipment and controls will be common to the two machines. and set the power supplies at the required rate[2]. This will use
A major objective will therefore be a seamless integration of TDM communications technology and reflective memory com-

S03SRD01
100

Status Reports: Design/ConstructionICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD02

A Performance Requirements Analysis of the SSC Control System
S.M. Hunt, K. Low
SSC Laboratory *2550 Beckleymeade Ave.
Dallas, Texas 75237

Abstract
This paper presents the results of analysis of the performance requirements of the Superconducting Super Collider
Control System. We quantify the performance requirements of the system in terms of response time, throughput
and reliability. We then examine the effect of distance andtraffic patterns on control system performance and exam·
ine how these factors inftuence the implementation of thecontrol network architecture and compare the proposedsystem against those criteria..

I. INTRODUCTION
The Superconducting Super Collider Laboratory (SSCL)
is a complex of accelerators being built in the area of Waxahachie, Texas. It will be fully operational at the end of
the decade. The SSCL consists of six accelerators: a 1 Gev
Lina.c, three booster synchrotrons (the 12 Gev low energy
booster, a 200 Gev medium energy booster, a 2 Tev highenergy booster) and two intersecting, contra-rota.ting 20
Tev synchrotrons that make up the Collider itself. The
complex will occupy approximately 112 km of undergroundtunnels. There are estimated to be about 150,000 control
points requiring remote control and interrogation in orderto operate the accelerator and diagnose its condition.

II. PERFORMANCE REQUIREMENTS
A. Response time
The control system's response to operator requests
should be such that response delays be unnoticeable tothe operators. The minimum response time of the control
system should be, in the absence of any other constraining
factors, 20Hz.
In addition, it will be necessary to provide for higher rates,
up to 1 Khz for some essential services like the quench protection monitors (QPM).

B. Throughput
In the Collider tunnel there are 5 Superconducting
dipole magnets per half-cell and 968 half-cells per ring.
Every 450m is an equipment niche (alcove) which controls
5 half-cells (200 niches). The HEB has 280 half-cells controlled by 24 Niches. The MEB consists of 200 half-cells
controlled from 8 surface buildings and the LEB has 108
half-cells controlled from 6 surface buildings. Throughput•Operated by the Universities Research Association, Inc., for the U.S.
Department of Energy under Contract No. D&.AC02-89ER40486.

requirements vary widely [Table 1]. The Lina.c is not considered here. The environmental (ENV) figures include
niche temperature, power, smoke alarms, oxygen and water. The value in the column marked Locations indicatesthe number of Niches or equipment buildings for a particular machine. The value in the column marked Bytes
indicates the number of bytes of raw data being generated
at that location for each time interval indicated in the column marked Ra.te, which is the number of time intervals
per second. The value in the column marked Bandwidth
is the total number of bytes per second generated for that
equipment type and is the product of the Locations, Bytes
and Ra.te values. For the LEB BPM data rates have been
set in this table at one tenth of the raw rate in order toconserve bandwidth.
The total amount of data generated site-wide by the
SSCL is in excess of 250 Mbytes per second (2 Giga. bits
per second)[l,2].

C. Reliability
Total allowable unscheduled downtime for the control
system is 30 hours in 4505 hours of operation per year.
The control system will consist of 205 equipment locations
consisting of 162 Collider niches, 24 HEB niches, 11 MEB
buildings, 6 LEB buildings, the Lina.c and the control roomcomplex. Ea.ch of these locations will have one communications element (Hub Gateway or multiplexor, dependingon the communications architecture chosen) and up to 9
equipment crates.
H each of these 2050 elements (205 locations x 10 elements)
is a "critical" system, then to achieve 30 hours of unscheduled downtime with a mean time to repair of 1.5 hours (20incidents per year) each element would have to achieve amean time between failure of 54 yea.rs (3]. It is therefore
clear that other measures, such as the use of redundant
systems, will be necessary in order to achieve the necessary reliability figures.

D. Capacity
The installed system should have a ca.pa.city at least 50%
greater than the requirements stated above. It should furthermore be capable of being expanded by 400% without
incurring any additional civil engineering costs or replacement of existing components, only expansion costs.

Ill. OPERATIONAL REQUIREMENTS
A. Data Accessibility

S03SRD02
Status Reports: Design/Construction

105

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD03

The Computer Control System for the CESR B Factory
C.R. Strohman, D. H. Rice and S. B. Peck
Laboratory of Nuclear Studies
Cornell University
Ithaca, New York 14853*

Abstract
B factories present unique requirements for controls andinstrumentation systems. High reliability is critical to achieving the integrated lUminosity goals. The CESR-B upgrade atCornell University will have a control system based on thearchitecture of the successful CESR control system, which uses
a centralized database/message routing system in a multiported memory, and V AXstations for all high-level control
functions. The implementation of this architecture will address
the deficiencies in the current implementation while providing
the required perfonnance and reliability.

I. INTRODUCTION

CESR-B is an upgrade to the existing CESR facility. 1
The major part of the upgrade is the addition of a second
storage ring in the existing tunnel. The two rings will operatewith asymmetric energies (3.5 GeV and 8 GeV) and willintersect within the CLEO detector. The design luminosity is3xH}13cm·2s·1 which will be achieved with 230 bunches in eachring.
The control system for CESR-B is also an upgrade of theexisting control system.2 The architecture is shown in figure
1. The MPM (Multi-Port Memory) contains the database andis accessible by the high-level computers and the BCCs (BusControl Computers). The high-level computers are used todevelop and run programs which interface with the operatorsand physicists to control and monitor the experiment. The
BCCs manipulate and move data between the database and theaccelerator hardware. Both the MPM and the interface
hardware are mapped into the memory space of the BCCs.
They only transfer data when requested to by the high-levelcomputers.
It is important to remember the difference between thearchitecture of a system and how it is implemented. Within awell defined architecture, one can make hardware or softwarechanges to improve some aspect of perfonnance without
affecting systems which are outside of the boundary of thecontrol system.

II. DESIGN PROCEDURE

Having decided that the current CESR control system isa suitable model for the B factory, we proceeded to analyze

the strengths and weaknesses of our system and the different
needs of the new system. Part of this process was defining thescope of the control system.

A. Boundaries of the Control System
For a large design project, well defined boundaries are
essential. At the boundaries, the needs of other people must be
taken into consideration, and the design process requires
communication between the designers and the users of thecontrol system. Within the boundaries, the control systemdesigners can do whatever is needed. We have defined thescope of the control system by defining interfaces for application programmers, instrumentation designers, and operators.
Application programmers must be provided a complete,well documented, set of functions which meet their needs.
Programmers are not allowed to bypass these functions byusing calls to lower-level routines. CESR uses approximately
35 functions.
Designers of instrumentation hardware are provided witha specification for constructing interfaces to the control system.
This includes mechanical, electrical, and protocol details.
Recommendations that simplify the control system are included, but not required. This encompasses things like avoiding
write-only registers and not having read operations change thestate of the system.
The actual implementation of the operator interface is acombination of efforts by both the application programmers
and the instrumentation designers. However, it is essential toknow the needs of the operators when designing the control
system.
B. Special Requirements of the B Factory

We need to know what makes CESR-B different fromCESR and how these differences affect the architecture andimplementation of the control system.
The first question is how much larger will the new system
be? At this early date, we do not have all of the details fromthe various design groups (eg. vacuum systems, magnet
systems), but we do have general numbers. Combining thisinformation with the fact that the amount of equipment in thetunnel will approximately double, we detennined that the newcontrol system will have roughly twice as many output control
points as the current system.

"Work supported by the US National Science Foundation

S03SRD03
110

Status Reports: Design/Construction

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD04

Standards and the Design of the Advanced Photon Source Control System*
William P. McDowell, Martin J. Knott. Frank R. Lenkszus, Martin R. Kraimer, Roben T. Daly, Ned D. Arnold, Mark D.
Anderson, Janet B. Anderson. Roben C. Zieman, Ben-Chin K. Cha, Fred C. Vong, Gregory J. Nawrocki, Gary R. Gunderson,
Nicholas T. Karonis, and John R. Winans
Argonne National Laboratory
Advanced Photon Source
9700 South Cass Avenue
Argonne, Illinois 60439
IDgh performance

I. INTRODUCTION

processor
Program development

The Advanced Photon Source (APS), now underconstruction at Argonne National Laboratory (ANL), is a 7 GeV

Log/arcbiv"
Bridge to o!her networks

Some applicaliom
Clients for X-!Crminals

positron storage ring dedicated to research facilities usingsynchrotron radiation. This ring, along with its injection
accelerators is to be controlled and monitored with a single,
flexible, and expandable control system. In the conceptual stage
the control system design group faced the cballenges that face allcontrol system designers: (1) to force the machine designers toquantify and codify the system requirements, (2) to protect theinvestment in hardware and software from rapid obsolescence,and (3) to find methods ofquickly incorporating new generationsof equipment and replace obsolete equipment without disrupting
the existing system. To solve these and related problems, the APS
controlsystemgroupmadeanearlyresolutiontousestandardsin
the design of the system. This paper will cover the present statusof the APS control system as well as discuss the design decisions
which led us to use industrial standards and collaborations withother laboratories whenever possible !O develop a control
system. It will explain the APS controls~ and illustrate how
the use of standards bas allowed APS to design a control system
whose implementation addresses these issues: The system will
use high perfonnance graphic workstations using an
X-Windows Graphical User Interface (GUO at the operator
interface level. It connects to VME--based microprocessors at
the field level using TCP/IP protocols over high performance
networks. This strategy assures the flexibility and expansibilityof the control system. A defmed interface between the systemcomponents will allow the system to evolve with the direct
addition of future, improved equipment and new capabilities.
Several equipment test stands employing this control systemhave been built at ANL to test accelerator subsystems andsoftware for the control and monitoring functions.

Console Computer
RISC Processor

Most Applica!lons
Program DevoloplJICDt
Most ConrolcFunetions
4 at Central Conlrol
l at injector area11\)ector Jnp11f/011tput
Controllers (IOC)M680x<l Proccssor{s)Most interface functions
Alarm Checking
Closed loops
7 atlinac
S at positron accumulacor
7 at synchrotron
l at high energy tran&fer

Storage Ring IOCs

M680x0 Procesror{s)lat each sector-pair
2 at speclll diagnostics
2 atrfbuilding
l for ring magnets

Remote Console
Provides all collSolc functions
All central c.ollSO!e func!lons
AJiyware on network
FunctiollS ea local collSOlc\ _ Equipment Processors
Status details
Preproccss dala
PS: lfllec!ion ( Sx 40 200)
Raw PS: lfsectorpair(W)Dillgilos!ics lfseclor pair (20)=Figure 1. APS Control System

II. STANDARDS AND THE APS CONTROL SYSTEM
The APS control system must be capable of (1) operating the
APS storage ring alone and in conjunction with its injector
linacs, positron accumulator, and injector synchrotron for filling,*Work supported by U.S. Department of Energy, Office of Basic
Energy Sciences under Contract No. W-31-109-ENG- 38.
Tl!a aubmitted ma!llHCtiPt ha be9n authoredby e cont,,..tor of the u. s. G011ernmentand (2) operating both storage ring and injection facilities asmachines with separate missions. The control system design isbased on the precepts of high-performance workstations as theoperator consoles, distributed microprocessors to control
equipment interfacing and preprocess data, and aninterconnecting netwotk. In a paper presented at the 1985
Particle Accelerator Conference [1] we outlined our initialapproach to the APS control system. In this paper we predictedunder contract No. W·31·100-ENG.;18.
Accordingly, the U. S. Government retains e
nonoxcluliw, royalty·free
to publish
or reproduce th• publilhld form of thiscontribution1 or allow other• to do so# for
U.S. GOV8rnment p u - .

u.,..,..

S03SRD04
116

Status Reports: Design/Construction

116

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The ESRF Control System; Status and Highlights
W.-D.Klotz
European Synchrotron Radiation Facility
BP 22038043 Grenoble Cedex, France

1

Introduction

The European Synchrotron Radiation Facility 1 [1] will operate a 6GeV e- /e+ storage ring of 850m circumference
to deliver to date unprecedented high brilliance X-rays
to the European research community. The ESRF is thefirst member of a new generation of Synchrotron Radiation Sources, in which the brilliance of the beam and theutilization of insertion devices are pushed to their present
limits.
Commissioning of the facility's storage ring will start inspring 1992. A full energy injector, consisting of a 200Me V
linear preinjector and a 6Ge V fast cycling synchrotron(lOH z) of 350m circumference have been successfully commissioned during the last months.
The machine control system for this facility, which isunder construction since 1988, is still under development,
but its initial on-site operation this year has clearly madeeasier the commissioning of the preinjector plant.
A description of the current system is given and application software for start-up is briefly described.

2

Architecture

The ESRF control system is based on a multi-level architecture of distributed hard- and software processing
units[2]. Logically the system is structured into four levels.
From top to bottom we call them:• Console Level (Presentation);

represents that level of the control system where practically all higher level control tasks take place and where
physics applications are processed. Powerful multitasking
capabilities and fast processing is mandatory on this level.
The presentation level presents the interface between theoperators and the system. Within this level data enteringfrom the lower level are presented graphically or are formatted to readable reports. Commands entered by meansof interactive devices are decoded into events and finallypassed as internal messages to the lower levels.
Physically the system is split into 2 levels. All nodes ofthe presentation and process level consist of UNIX based
workstations and file/compute servers interconnected by
Ethernet. The group level nodes are realised by VMEbus
crates, equipped with 68030 CPU boards. These systems
run the OS9 multitasking real time kernel/operating system. Every process level server connects to a private Ethernet segment onto which group level nodes it is in chargeof are connected.
The physical boder line between group level and fieldlevel is fuzzy. In our system some dumb devices are directly interfaced to VME 1/0-boards that are plugged into
group level crates, but most dumb devices are interfacedby means of G64 crates. Groups of G64 crates, that interface classes of similar devices, are connected to multidrop
highways that are mastered by group level crates. This
multidrop highway 2 was developed at ESRF. However, intelligent devices with embedded controlers are, in the majority of cases, directly connected to VME (group level)
crates3 .

• Process Level (Applica.tions);

3• Group Level (Device Servers);• Field Level (Equipments, Embedded Controlers).

On the lowest level, all equipments are interfaced; either
by intelligent controlers, as they are delivered from the
manufacturer, or by dumb interfaces. Equipments are logically grouped together on the group level. Grouping ofequipments is done by similar functionality. The grouplevel is responsible for hardware specific and real time
1/0-operations. Device servers perform the task of hiding
hardware specifics to the upper level. The process level

Networks

Modern control systems are distributed[3, 4]. The larger
the accelerator is, the more important is its network infrastructure. The ESRF control system is fully distributed
and relies strongly on a high speed computer network.
Figure 1 gives an overview of the logical and physicalimplementation of the control system and its network.
Apart from the home-made multidrop highway all computer connections are based on the Ethernet(IEEE 802.3)
2we named it FBUS
3 in the majority by RS422 or RS232 asynchronous serial links

1 (ESRF)S03SRD05
Status Reports: Design/Construction

121

121

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S03SRD05

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD06

Centralized Multiprocessor Control System for the Frascati Storage Rings DAcl>NE
Giampiero Di Pirro, Caria Milardi, Mario Serio, Alessandro Stecchi, Luciano Tra.satti.
INFN, Laboratori N azionali di Frascati
P. 0. Box 13, 00044 Frascati (Rm) ITALY. e.m. trasatti@irmlnf
andBarbara Caccia, Vittorio Dante, Raffaellino Lomoro, Eleuterio Spiriti, Stefano Valentini.
lstituto Superiore di Sanita' and INFN, Sezione Sanita',
Via Regina Elena, 299, 00161 Roma, ITALY, e.m.caccia@sanita.infn.it

Abstract
We describe the status of the DANTE (DAcl>ne New
Tools Environment) control system for the new DAc!>NE cl>factory under construction at the Frascati National
Laboratories. The system is based on a centralized
communication architecture for simplicity and reliability. A
central processor unit coordinates all communications between
lhe consoles and the lower level distributed processing power,
and continuously updates a central memory that contains thewhole machine status. We have developed a system of VME
Fiber Optic interfaces allowing very fast point to point
communication between distant processors. Macintosh II
personal computers are used as consoles. The lower levels are
all built using the VME standard.

level, implementing the human interface. Several consoles,
built on Macintosh personal computers, communicate withthe rest of the system through high speed DMA busses andfiber optic links.
PURQATORY (Primary Unit for Readout and GATing Of
Real time Yonder) is the second and central level of thesystem. It essentially contains only a CPU and a Memory in a
VME crate. The CPU acts as a general concentrator andcoordinator of messages throughout the system. The central
Memory is continuously updated and represents the prototypeof the machine database.
HELL. (Hardware Environment at the Low Level) is thethird level of the system and is constituted by many (about60) VME crates distributed around lhe machines.

I. DA<l>NE
DAc!>NE [1] is a two ring colliding beam cl>-Factory underconstruction at the Frascati National Laboratories (See Fig.
1).

Construction and commissioning is scheduled for the endof 1995.
The luminosity target is -1<>33 cm-2 sec-1.

10

DA<I>NE0

Mal>clll•

GS.....__

av

_,110

Fig. 2: Control System Schematic Diagram

·10

•10

0

10.

m

Fig. 1 : The DAc!>NE c!>-Factory layout

II. SYSTEM STRUCTURE
Fig. 2 shows the general architecture of the control
system. Three levels are defined:
PARADISE (PARAilel DISplay Environment) is the top

A CPU in every crate performs control and information hidingfrom the upper levels.
VME is used throughout Purgatory and Hell
A first estimate of the system gives about 7000 channels
to be controlled.

Centralized Communication Control
We have chosen an architecture based on a single central

S03SRD06
128

Status Reports: Design/ConstructionICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD07

THE OPERATOR VIEW OF THE SUPERCONDUCTING CYCLOTRONAT LNS CATANIA
D.GIOVE, INFN MILANLASA - V. F.LLI CERVI 201

SEGRA1E- ITALY

G. CUTTONE AND A. ROVELL!, INFN LNS
V.LE A.DORIA ANG. V. S. SOFIACATANIA-ITALY

Abstract
The upper level of a distributed control system designed forthe ~uperconducting Cyclotron (SC), will be discussed. In

particular, we will present a detailed description of theoperator view of this accelerator along with the tools for 1/0
poi~ts managem~nt, data rappresentations, data archiving andretrieval. A_ dedica~ program.• developed by us, working
under X-Wmdow will be descnbed as a starting point for a
new man-machine interface approach in small laboratories
opposed to the first industrial available packages.

I. INTRODUCTION
The SC developed at the Milan University, where was
performed the first test on the magnetic field, has been moved
to the final destination, at LNS in Catania. The work on theaccelerator will start at the begin of the next year with themagnet excitation and the installation of the RF cavities. The
extraction of the beam, injected in the booster by a 15 MY
Tandem, is foreseen before the spring of 1993. The mainfeatures of this heavy ions accelerating facility are reported
elsewhere [1] [2].
According to the experience gained in Milan on the control
system during the first magnetic measurements, we planned
improvements mainly on the upper level devoted to the manmachine interaction. The first console designed and realired in
19~5-1987 [3], followed an old philosophy. Altough themam hardware and software choices had been proved
satisfactory, it gave us a flexibility not so good as we
expected.
Nowadays the availability of standard graphic software andthe capability to create networks are the two features whichmake the workstation a pratical cost effective way to provide
an universal environment for the development of the operator
interface. It is possible to use powerful hardware and software
standards which make straightforward the setting up of a
network where hardware and software resources can be easily
shared in a really efficient environment.
In the follow we will discuss the hardware and softwarearchitecture of the Superconducting Cyclotron operator
console together with its performance measured during thetest.

II. THE OPERATOR CONSOLE
In 1989, during the shut-down of the SC in Milan we
decided to review the structure of the console. Some ge~eralrules were fixed for the projecL- The architecure must be independent of the number ofworksites in use: the insertion or the removal of a worksite
must be invisible to the whole system, realizing in this way
a real "easy expandible system".
- The ~chitecture would .allow to have the same graphicalworkstation conncted both m the main control room and in aremote place closed to the accelerator.
- The architecture of the console must be fully independentof the lower levels so that the choices made in process andplant levels don't influence the supervisor structure.
- The presentation level of the software must not require
any practice in computer science and must be picture driven.
The_ operator ~ust be .able to defme its own working
envrronment with few choices and the access to every
information that he wants to deal with has to be guaranteed.
- The operations on an accelerator subsytem must be
possible by each workstation but not at the same time. The
display of all machine parameter must be possible ondifferent workstations at the same time.
- The on line software configuration must be guaranteed bymeans dedicated programs taking advantage of a database.
- The allarms and malfunctioning logging task must be
managed by a dedicated unit able to provide particular tools to
help the operator in his trouble shooting job.
- Th~ maintanance of the whole structure must be easy andcentralized as much as possible on a single machine.
It was decided that the development of most of software
would take not more than 3 man-years of work. The choiceof the final solution was not easy and a lot of different
considerations, like our experience with graphicalworkstations and their operating system, the estimatedtechni~al support avilable from vendors in our country, weretaken mto accounL At last, we decided to implement ourhardware architecture on a Local Area VaxCluster (LAVC) of
3100 Vaxstations with a µVax 3100 as boot member. A
gateway was provided towards the lower levels. A µVax II
was dedicated to this task along with the storage of thememory map of all sensors and actuators. Two 80386 PCs
were dedicated to allarm logging and to manage the datanecessary for the application tasks.

S03SRD07
Status Reports: Design/Construction

131

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD08

The UNK Control System
V.N.Alferov, V.L.Brook, A.F.Dunaitsev, S.G.Goloborodko, S.Vlzgarshev, V.V.Komarov, A.F.Lukyantsev,
M.S.Mikheev, N.N.Trofimov, V.P.Sak:barov, E.D.Scherbak:ov, A.I.Vaguine, V.P.Voevodin, V.D.Yowpalov,
S.A.Zelepoukin, IHEP, Protvino, USSR, B.Kuiper, CERN, Geneva

Abstract
The IHEP proton Accelerating and Storage Complex(UNK) includes in its first stage a 400 GeV conventional anda 3000 GeV superconducting ring placed in the same underground tunnel of 20.7 km circumference. The beam will be
injected into UNK from the existing 70 GeV accelerator U70. The experimental programme which is planned to start in
1995, will include 3000 GeV fixed target and 400*3000 GeV
colliding beams physics. The size .and complexity of the
UNK dictate a distributed multiprocesssor aIChitecture of thecontrol system. About 4000 of 8/16 bit controllers, directly
attached to the UNK equipment will performlow level control and data acquisition tasks. The equipment controllers
will be connected via the MIL-1553 field bus to VME based
32-bit front end computers. The TCP/IP network will interconnect front end computers in the UNK equipment buildings with UNIX woikstations and servers in the Main Control Room. The report presents the general architecture andcurrent status of the UNK control

3. Colliding Beams at 3 + 3 TeV: the UNK-I will first inject into one superconducting ring and, after field reversal, into the second one.

NEUTRINO
AREA

HADRON
AREA

MAIN UNK RING
UNK·I • 400 GEV CONVENTIONAL RING
UNK-11 - 3 TEV SUPERCONDUCTING RING
UNK-111 - 3 TEV SUPERCONDUCTING RING

1.lntroduction
The UNK complex will combine ·in one tunnel of 20.7
km circumference - a 400 GeV conventiooal magnet synchrotron (UNK-I) and a 3000 GeV superconducting synchrotroo/storage ring (UNK-Il). At a later stage a second superconducting ring (UNK-fil) may be added with the aim of
doing proton-proton collider physics at 6 TeV (Figure 1).
The UNK-I is injected at 70 GeV from the existing
proton synchrotron U-70. For one filling up to 12 pulses
from U-70 may be stacked, accelerated to 400 GeV andtransferred to the UNK-Il which in tum accelerates them up
to3TeV.
Three main modes of operation are presently foreseen.
1. Fixed Target at 3 TeV: fast or slow extraction will send
the 3 TeV beam to the fixed target experimental area.
During the acceleration in the supen:onducting ring, U-70
may produce beams for its own 70 GeV experimental
area.

2. Colliding Beams at 3 + 0.4 TeV: the beams from the
UNK-ll and UNK-I are made to collide. For this the
UNK-I is operated first as booster and, after field reversal, as a storage ring run at 400 GeV.

Figure 1 Layout of the UNK Complex
The accelerator controls equipment will be distributed
over 24 on-surface buildings situated mainly along the accelerator ring. In ooe of the these is the Main Control Room
(MCR), the other ones house the remote nodes of the control
system. The latter are totally controlled from the MCR and
are in general not manned. The typical distance between any
two adjacent buildings is about 1.8 km and the maximum isabout 3.5 km.
The more than 3500 supen:onducting magnets require acryogenic plant and elaborate distribution, recovery andsafety installations and their concomitant controls in the surface buildings around the ring tunnel.
The UNK opetation is supported by general electricity
and water distribution oetwoiks, tunnel ventilation, radiation
protection, fire safety and other utilities which require highly
reliable controls with 24 b/day 365 d/year availability.
The secondaiy beamlines and external experimental areas cover an area of roughly 12 km length. Controls for their

S03SRD08
134

Status Reports: Design/Construction

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD09

MOSCOW UNIVERSITY RACE-TRACK MICROTRONCONTROL SYSTEM: IDEAS AND DEVELOPMENT.

Chepurnov A.S., Gribov I.V., Morozov S.Yu., Shumakov A.V.,Zinoviev S.V.
Institute of Nuclear Physics, Moscow State University
119899, Moscow ,USSR.
Abstract.
Moscow University race-track microtron CRTM) control
system is a star-shape network of l.SI-11 compatible
microcomputers. Each of them is connected with RTM
systems via CAMAC; optical fiber coupling is also used.
Control system software is designed on Pascal-I,
supplemented with real time modules and Macro. A unified
real time technique and reenterable data acquisition
drivers allow to simplify development of control drivers andalgorithms. Among the latter three main types are used:
DOC methods, those, based on optimization technique andalgorithms, applying models of microtron 's systems. Manmachine interface is based on concept of the "world ofaccelerator". It supports means to design, within hardware
possibilities, various computer images of the RTM.

INTRODUCTION.
Moscow University race-track microtron - when it'sconstruction will be finished - is to produce 17S Me V 100 %duty factor electron beam with low transverse emittanceand up to 0.01 % energy(0.0S mm•mrad)
monochromaticity [ 1,2 ]. To support means for easy
programming of microtron's behavior, when being
adjusted, and to meet requirements of experimental
work, computer-based control system is to be developed.
It's configuration is shown on fig. 1

HARDWARE.
Each micro computer of the control system is a 1-PCB
l.SI-11 compatible machine CEIS,FIS CPU; 1mips;56 Kb
RAM). In control station it's connected with CAMAC via
JCC-11 compatible crate-controller. Among CAMAC
modules the following types are used: output and input
registers (standard and specialized), FET multiplexers,
13,14,16 bit ADCs, step motor drivers. To prevent
inadmissible interference, control system is isolated
electrically from accelerator's equipment. For thispurpose optically coupled measurement devices are used.
Their terminal modules can be of three types: 19 bit TTL
transmitter or receiver, 16 multiplexed a dozen bit ADCsor eight 12-bit DACs. Control stations (three of them inoperation now) are connected via RS-232C interface in astar-shape network, formed by concentrator station. The
latter is also tied with host-machine, used for softwaredevelopment and system loading. Man-machine interface
and data-bases station is linked up with network like acontrol station. Concentrator machine and control stations
have no any extra memory storage except CPU RAM.
Man-machine and data bases station includes two
microcomputers. One of them supports graphics, anotherhandles data bases and communication protocols. This
station, as well as host machine, is supplied with discmemory - including electronic one. Alphanumeric displays(VT-100) and some other peripherals are also attached.
Among them - RS-232C interface, allowing to link up
control system with external computer or network. Manmachine interface will also be supplied with four infiniteturning knobs to facilitate manipulation with one, two or
three dimensional objects (control parameters value,
terminal cursors etc) .

Man-machine
To external computerinterface and realor network
time data bases - - - - - - - HostmachineNetwork
concentrator

Station 1
In·ector

Station 3
Preaccelerato

CAMAC modules, fiber optic devices,
constant-current power sources.
Local feedback systems and regulators,
alarm, and blocking systems

Accelerator's equipment
Fig. 1. Block diagram of Moscow University

RTM control system.
SOFTWARE.

Compilation tools.
Basic compilation tools are shown on fig. 2. Source Pascal
code with Macro insertions is being compiled with
Pascal-1. Then a specially designed improver heightens aneffectiveness of resulting Macro code. Afterwards, on
Macro stage, it's being combined with CAMAC support

S03SRD09
140

Status Reports: Design/ConstructionICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD10

Present Status of Control System at the SRRC
G. J. Jan*, J. Chen, C. J. Chen, C. S. Wang
Synchrotron Radiation Research Center, Hsinchu 30077, Taiwan• also Department of Electrical Engineering, National Taiwan University, Taipei 10764, Taiwan

ABSTRACTThe modern control technique was used to design and set
up a control system for the synchrotron radiation facilities
at the synchrotron radiation research center {SRRC). This
control system will be finally to operate the dedicatedmachine to provide the 1.3 GeV synchrotron radiation
light. The control system will control and monitor thecomponents of storage ring, beam transport and injector
system. The concept of the philosophy is to design a unique,simple structure and object-oriented graphic display control
system. The SRRC control system has the major
features such as two level architecture, high speed local
area network with high level protocol, high speed
microprocessor based VME crate, object-oriented highperformance control console and graphic display. The
computer hardware system was set up and tested. The
software in top level computers which include databaseserver, network server, upload program, data accessprogram, alann checking and display, as well as graphics
user interface (GUI) program were developed and tested. The
operational system and device driver on the field level
controller were implemented. The overall performance of the
SRRC control system were tested and evaluation. The
preliminary results showed that SRRC control system issimple, flexible, expandable and upgradable open system tocontrol and monitor devices on the small scale synchrotron
radiation facility.

I. INTRODUCTION
The 1.3 GeV synchrotron radiation facility is going toconstruct at SRRC to provide a low emittance and highbrilliance light source. The dedicated synchrotron light source
will include three subsystems that are a turn key 1.3 GeVelectron full energy injector, beam transport line and storage
ring. The 1.3 GeV full energy electron injector wasconstructed to Scanditronix AB at Sweden and installed at
SRRC site. The injector is going to commission within 2 or
3 months. The berun transport line has been designed and its
major component was also fabricated partially. The storage
ring with triple bend achromat lattice [l] has been designed
and the 'most components were constructed and passed its
qualification of the specification.
The control system at SRRC provides a unique control
and monitoring three subsystems which include the injector,
the beam transport line and the storage ring facilities. The 1.3
GeV energy electron injector is composed of a SO MeV linear
accelerator and 1.3 Gev booster synchrotron accelerator. The
control system of booster synchrotron can be run in a turnkey system and/or to be integrated into SRRC control desk toform an unique control system. The design concept is to
standardize the same computer architecture, digitalcommunication network with some protocols and somedatabase structure as well as some console computer. The
control system of the electron injector can play as a standalone subsystem to test and commissioning machine as wellas machine study for booster synchrotron.
The control system of SRRC is cost-effectively designed
by using recent developed computer technology [2,3] andmodern control technique [4-9]. Two level hierarchicalcomputers, process and console computer as a top level andmultiple intelligent local controllers (ILC) as a low level, wasconfigured. One process computer and several console
computers at top level provide the database management
and maintenance, devices control and monitoring, data
logging and archiving, machine modeling, object-oriented
graphical display.
The lower level computers are
multiple VME crate based system which handle device
related data acquisition and control as well as local
interlocking functions. It simplifies the architecture ofcontrol system at SRRC. The upper and lower levelcomputers are connected by ethemet using high levelprotocol.
The process computer will handle the static and dynamic
data base. It also offers to carry out the calculation of theelectron orbit and simulation of the machine physics
parameter. It is a high speed computing, multi-task and mutiuser virtual memory system (VMS), and high throughinput/output {I/O) capability. The console computers willplay a similar job as a process computer except maintenanceof the database. The console computer plays an important role
to operate and monitor the synchrotron radiation facility using
man-machine interface that is developed based on the conceptof the object-oriented graphic display. This is the most recent
development on the third generation of the synchrotron
radiation facility [7-9].
The ILC is a field level { or called device level ) controller
which performs the local data collection, local interlocking
and closed loop control for the components and/or theequipment o~ the various system. It is also very important for
the real time feedback control system.

IL COMPUTER HARDWARE SYS1EM
Two level hierarchical computer configuration has been
designed and installed partially at this momenL The hardware
configuration of the control system at SRRC is shown infigure 1. The top level computers are composed by one
process computer and several console computers. The VAX
6000 model 610 supermini computer is chosen as a processcomputer. The VAXstation 3100 model 76 is selected as aconsole computer. The big semiconductor and mass storage
capacity as well as high speed I/O peripheral devices are also
considered and configurafed.

S03SRD10
Status Reports: Design/Construction

143

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Status Report on Control System Development for PLS*
S.C. Won, S.S. Chang, J. Huang, J. W. Lee, J. Lee, J. H. Kirn
Pohang Accelerator Laboratory,

POSTECH, P.0.Box 125,
Pohang 790-600, Korea

Abstract
Emphasizing reliability and flexibility, hierarchical architecture with distributed computers have been designed into the Pohang Light Source (PLS) computer control system. The PLS
control system has four layers of computer systems connected
via multiple data communication networks. This paper presents
an overview of the PLS control system.
Introduction
The accelerator control system provides means for accessing
all machine components so that the whole system could be monitored and controlled remotely. These tasks include setting magnet currents, collecting status data from the vacuum subsystem,taking orbit data with beam position monitors, feedback controlof electron beam orbit, regulating the safety interlock monitors,
and so forth. To design a control system which can perform thesefunctions satisfactorily, certain basic design requirements mustbe fulfilled. Among these are reliability, capability, expansibility,
cost control, and ease of operation.

Considering above requirements, the PLS accelerator topology, available resources, special accelerator hardware requirements and personal preference, we propose a hierarchical systemarchitecture. To implementation of the control system, highly
commercial approach should be made because of the tight construction schedule. Using well proven technology will promotereliability, and reduce the development effort. A development environment is set up to develop the prototype of beam close orbit
correction system which is to damp up to 15Hz movements. The
Beam close orbit correction system will use DSP(Digita.I Signal
Processor) board for the fast computation. All BPM electronic
modules and corrector power supply interface I/O modules for
one acromat will be put into one VXI crate.

Hardware Hierarchy
To monitor and control the thousands of signals for PLS, it
is desirable and cost-effective to establish a distributed control
system based upon microprocessors. The PLS control system hasa hierarchical structure as shown in Fig.I. The hierarchy consistsof four layers, each of which has a different role. The four layers

Laborat0ry Network-------------------------------------·----------------~----------------Console
Compuiers

Local Console

I

B

Vaa.iwn I
Subsysicm:

~rol

MPS&
Vacuum

Mil-Std-l 553B
(Low Level
Network)

I

I:

Subsy"""8Control

Storage Ring
Control

MIU

Mil-Std-1553B(Low Level
Network)

LINRC Control

SCC : Subsystem Control Computer

MIU : Machine Interface Unit

Figure 1. PLS Control System Architecture• W?rk supponed by Pohang Iron & Steel Co., Ltd. (POSCO) and Ministry oi
Science and Technology (MOS1), Government of Republic of Korea.

S03SRD11
Status Reports: Design/Construction

147

147

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S03SRD11

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Design of SPring-8 Control System
T. Wada, T. Kumahara, H. Yonehara, H. Yoshikawa, T. Masuda, and Wang Zhen
JAERI-RIKEN Spring-8 Project Team
Honkomagome 2-28-8, Bunkyo-ku, Tokyo, 113 Japan
Abstracr
The control system of SPring-8 facility is designed. A distributed
computer system is adopted with a three-hierarchy levels. All thecomputers are linked by computer networks. The network of upper
level is a high-speed multi-media LAN such as FDDI which links
sub-system control computers, and middle are Ethernet or MAP
networks which link front end processors (FEP) such as VME
system. The lowest is a field level bus which links VME andcontrolled devices. Workstations (WS) or X-terminals are useful for
man-machine interfaces. For operating system (OS), UNIX is usefulfor upper level computers, and real-time OS's for FEP's. We will
select hardwares and OS of which specifications are close tointernational standards. Since recently the cost of software has
become higher than that of hardware, we introduce computer aided
tools as many as possible for program developments.

I. INTRODUCTION
The SPring-8 facility consists of an 8 GeV storage ring of 1436 m
circumference with a natural emiuance of7.0 nmrad, an injector linacof 1 GeV and an 8 GeV synchrotron. Figure I shows the layout of
the facility. Construction starts in 1990, and the first stored beam isforeseen in 1998 [1]. The construction of control system will start in1994.
From the designer's viewpoints, the control system consists of thefollowing parts:I) Computer System;1-1) Host and front end computers;
1-2) Network system;1-3) Software:2) Interlock System;
3) Analog Signal Observing System;4) Timing System;5) Television Network System;
6) Links with other System:

II. DESIGN CONCEPTS
Followings are the design concepts of SPring-8 control system:
1) Distributed processors system which are linked by high-speed
networks.
2) Sub-system control cornpmers are loosely coupled, due to different
accelerator construction schedules and for the convenience ofindependent operation at maintenance time.
3) In normal operation, all the accelerators are operated at one control
room by small number of operators.
11) VME and MAP for front end processors and networks,
respectively.
5) PLC (Programmable Logic Controller) for fixed control sequence.
6) Real-time operating system for VME.
7) For high productivity of application program;
7- I) Object-oriented programming;
7-2) Computer aided program developing tools;
7-3) Computer aided operation tools:
8) Standard hardware and software.

(l) l Ge V Electron I positron linac Build.

(2) 8 Ge V Synchrotron Tunnel(3) Storage Building(4) El<preimental Hall
(5) Experimental Hall using Radioactive Materials(6) Laboratories for users(7) Central Building(8) Long Beam Lines (1000 m)(9) Long Beam Lines (300 m)(10) Conirol Room
(11) Cafeteria( 12) Miharakuriyama Hill (345 m

Fig. 1 Layout of the SPring-8.

S03SRD12
Status Reports: Design/Construction

151

151

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S03SRD12Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD13

Design of a Control System of the Linac for SPring-8
H.Yoshikawa, Y.Itoh and T.Kumahara.
Accelerator Systems Development Group.
Office of Synchrotron Radiation Facility Project.
Japan Atomic Energy Research Institute.
Tokai-mura, Naka-gun, Ibaraki-ken, JAPAN.

Abstract

B.Software

The design of a control system of the linac which is a large
scale system including many unstable components like
klystron8 and modulatoIS. The linac for SPring-8 requires tobe operated automatically for injection to the synchrotron.
Under these conditions, we chose a distributed control systemarchitecture of a single layer net-work to simplify the
protocol of the net-work between the linac, the booster
synchrotron and the storage ring. A VME computer of 68030
is put in every modulator of the linac, and all control signals
are gathered to the nearest VME computer. OS-9 andOS-9000 are on trial for investigation of the performances.
TCP/IP is tentatively chosen as a protocol of the net-work,
but we expect that MAP/MMS ·makes a high performance,
and we are preparing a test of it.

The operating system is OS-9, and the language is C, andpartly assembler is used. To select OS, VxWorks, VRTX,
LynxOS, OS-9000 and others are check up. OS-9 is selected
at the points of reliability, ability of stand alone work without
development systems and suitability for bottom up build of asystem. Applications and libraries will be made from practicaluse of object oriented programming.

STRUCfURE OF PROCESS
Every task consists of a control process, file-managers
and device drivers. To get higher flexibility, all parameters aredescribed in several parameter-files, and processes have no
inner parameters.

INTRODUCTION

A.Communication process
We decided that all hardware should be selected fromready-made machines for security of reliability, and our needs
is satisfied at low cost without any customizing modules.
Because this linac will be used on commercial base, reliability
is the most importance for this control system. Moreover,easiness to use is necessary as a user oriented system. Thislinac consists of 26 pairs of a accelerator section and a
klystron, so control signals mainly exist around modulators.
Every signal is connected to the nearest vME computer in themodulator. 26 VME computers are connected to the fl.at
network of one layer. Each VME computer works for a
modulator, magnet power sources, vacuum pumps, RF phase
control and monitora. Software of 26 VME computers arealmost same, and it is easy to check whole performance of
this system by a test bench of one set.

The data format of communication between processes is
the same as the format of data through the net-work. If one
process send a event (or a signal) to the out of one's cage
through a network, the event is received by a communication
process. The communication process searches the network
address of the cage to which the target process belongs, andit send the event signal as a datagram to the cage. The addressof machines are not fixed. The machine address resolution
procedure(MAR procedure) defmed machine addresses. Whena searched process name belongs to a machine, the MAR
process of the machine answers its address by broadcast.

B.Logging process
Most of the data sets are logged by a double buffered
method. A double buffered method is combination of a ringbuffer and a event buffer. The ring buffer stores continuous
data of short interval, and if any troubles appear, shifting of
the ring buffer is stopped to trace of the origin of the troubles.
The event buffer stores log of status for long term.

CONFIGURATION OF THE SYSTEM

A.Hardware
MVME-147s(Motorola) is selected as a CPU board, and
it is set in a cage of 20 plots. Digital input/output boards arephoto-isolated type, and analog input/output boards are two
type of 12bit and 16bit. All signals directly come to thecomputer through a interface circuit of no CPU, but signals ofmonitors must have interface devices to establish satisfactory
performances.

C.Interlock process
Inter lock signals must be taken by bard wires without
computers. But it is able to reduce the wires by a inter lockbus system. In this linac, 26 modulators are almost same, andinter lock signals are classified into different emergency

S03SRD13
154

Status Reports: Design/Construction

154

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD14

CONTROL SYSTEM FOR HIMAC SYNCHROTRON
T. Kohno, K. Sato, E. Ta.kada., K. Noda., A. !ta.no,
M. Kana.zawa, M. Sudou, K. Asamit R. Azumaishii Y. Moriif
N. Tsuzukif H. Narusa.ka5and Y. Hirao
National Institute of Radiological Sciences
4-9-1 Anagawa., Chibai-shi, Chiba 260, Japan

Abstract
A control system for HIMAC synchrotron ha.s been designed. The system consists of a. ma.in computer, console
workstations, a few small computers and VME-computersconnected via. Ethernet. The small computers a.re dedicated to the control of an injection line, an extraction line
and a.n RF system. Power supplies in ma.in rings a.re controlled by the VME-computers through FDI/FDO, DI/DO
modules. This paper describes an overview of the synchrotron control system.
INTRODUCTION

HIMAC is a heavy-ion accelerator complex for theclinical treatment of tumors and now under construction
at National Institute of Radiological Sciences. It consistsof an injector, a synchrotron, a. high-energy beam transport and an irra.dia.tion sub-systems. Hea.vy-ions with acharge-to-mass ra.tio as small as 1/7 a.re accelerated up to
6 MeV /u through a.n RFQ a.nd Alvarez Una.cs a.nd injectedto the synchrotron sub-system.
The synchrotron sub-system ha.s a.n injection line, an
extraction line and a. pair of separated function type synchrotron rings with almost the sa.me structure. These rings
operate independently at diiferent energies a.nd same ionspecies except that power supplies of two rings a.re 180°
out of phase ea.ch other. The output energy of ea.ch ring isdesigned to be variable in a ra.nge of 100 - 800 MeV/u forions with q/A = 1/2. The general description a.bout the
HIMAC synchrotron was given in the previous a.rticle[l].
An overall control system for HIMAC consists of a. supervisor computer and four sub-system control computersconnected via. Ethernet as shown in Fig.l. The supervisor
computer is used for the global control of the whole system
of HIMAC. It is also linked by hardware and/or softwareto the other equipments in this facility such as a watercooling system, an air-conditioning system and a. radiation
safety system. The sub-system computers control individual devices and carryout progra.mmed sequences for device
groups. The control system for the injector was already reported[2]. The control system for the synchrotron is also
*Omih Works, Hiia.chi, Ltd., Hhachi-shi, iba.raki 319·12, Japa.ntToshiba Corp., Chiyoda-ku, Tokyo 100, JapaniFuchu Works, Toshiba Corp., Fuchu·shi, Tokyo 183 1 la.pan!Digital Equipment Corpora.don Japan, Toshima.-ku, Tokyo 170,Japan

SY SYSTEM

Ethernet

INJECTORSYNCHROTRONHEBTIRRADIATIONSYSTEMSYSTEMSYSTEMSYSTEM

Fig. 1: A total control system for HIMAC consists of a. supervisor computer and four sub-system control computers.
designed in the same manner, that is, 1) each system isoperated rather independently by reducing the data. to betransferred each other, and 2) hardware and softwa.re concerned with a man-machine interface must be standardized
among all sub-systems.
SYSTEM CONFIGURATIONThe synchrotron sub-system has many devices of different operational characteristics, for example, de power
supplies in the injection and the extraction lines, highvolta.ge power supplies in the RF system a.nd the power
supplies in the ma.in rings operated with patterns or pulses.
In order to handle these devices of different types efficiently
a.nd to reduce the load of the main computer, we adopted
a distributed and hierarchical structure. A schematic viewof the synchrotron control system is shown in Fig.2. Components and their functions are as follows.

A main computer and console computers
A ma.in computer serves mainly a.s a. man-machine interface a.nd a file server. DEC VAX4000/300 is proposed
for this purpose under VMS with 64 MB memory, 3 GB
disk and communication interfaces for RS-2320, GP-IB
and Ethernet. In the HIMAC system, para.meters sucha.s current values, current patterns, timing relations etc.
are sa.ved a.s a. para.meter file in the ma.in computer andreferred a.s the reference data in the next operation of theidentical condition. The main computer has to manage thisdata.base a.nd carry out programmed start-up and shutdown sequences using these files.
For a man-ma.chine interface two operator consoles areavailable corresponding to two rings. Two VAX Station

S03SRD14
156

Status Reports: Design/Construction156

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Digital Control of the Superconducting Cavities
for the LEP Energy Upgrade
G. Cavallari and E. Ciapala
CERN, 1211Geneva23, Switzerland

Abstract
The superconducting (SC) cavities for the LEP200 energy
upgrade will be installed in units of 16 as for the present
copper cavity system. Similar equipment will be used for RF
power generation and distribution, for the low.level RF
system and for digital control. The SC cavities and theirassociated equipment however require different interface
hardware and new control software. To simplify routine
operation control of the SC cavity units is made to resemble
as closely as possible that of the existing units. Specificcontrols for the SC cavities at the equipment level, thefacilities available and the integration of the SC cavity units
into the LEP RF control system are described.

I. INTRODUCTION
The RF system for LEP phase l consists of a total of 128
RF accelerating/storage cavity assemblies operating at
352 MHz, providing a total circumferal voltage of 400 MV.
The cavities have been installed around interaction points 2
and 6 in the form of eight individual RF units. Each consistsof 16 cavities, two 1 MW klystrons, DC high voltage power
converter, low-level electronics and controls. For the LEP200
energy upgrade to 90 GeV, requiring 2000 MV, a further 192
superconducting (SC) cavities will be installed in 12 new RF
units, two at each of points 2 and 6 and four at each of points
4 and 8. The RF frequency for the SC units is the same as forthe copper units and as far as possible they will use identicalequipment i.e. klystrons, power converter, low-level
equipment and controls.
The SC cavities are housed in groups of four in a common
cryostat to make up an ..RF module". Initially only one
klystron will be installed per unit but there is provision to add
a second for higher beam intensities.
Control of the SC cavities and associated equipment isbased on the same principles as for the copper cavities withthe same type of interface equipment and software. To renderoverall operation as straightforward as possible differences
between the two types of RF unit are taken into account bylocal software. Unlike the copper cavity units the SC units
can be run in different configurations e.g. four, eight, 12 or 16
cavities and with either one or two klystrons per unit. The
configuration must be taken into account by the local
software. With two klystrons SC cavity units could be
operated more effectively as two "sub-units" of eight cavities
and one klystron sharing the common HV power supply. This
option is allowed for in the hardware layout and software.

At present one unit with 12 SC cavities is operational in
LEP and funher units will be installed gradually up to thecompletion of the project, planned for the beginning of 1994.
II. CONTROLS AND INSTRUMENTATION FOR THE
LEP SC CAVITIESWithin the RF unit the various pieces of equipment
associated with each major element of the unit are grouped
together and controlled by a 064 bus standard based'Equipment Controller' (EC). As for the copper cavity units
there is one EC for each SC cavity but for each RF module
there is an additional EC for cryogenics data. The EC is ofmodular construction and maximum use is made of a small
range of interface cards. Standard modules are used to interface
the following equipment :Cavity tuning systems,
RF power measurement,
RF window and helium gas return heating,
HOM coupler fundamental mode power measurement,
Helium gas pressure measurement,
Helium gas valve control,
Cryostat insulating vacuum,
Cavity vacuum.
Interlock protection systems exist to switch off cavity
tuning, RF or the HV power converter in the event of a fault
or unsafe condition. These systems are largely contained
within the ECs in the form of standard interlock modules andG64 readout interfaces which provide fault status and record
trip sequences. For the SC cavities a "beam dump" interlock
has been added. In the event of very high helium gas pressure
or low liquid helium level, RF is switched off in all RF units.
For temperature measurements in the cavity a dedicatedmodule inside the cavity EC measures up to 32 temperaturesfrom signals from PtlOO sensors at various critical points.
Conversion of voltage levels to temperature values in degrees
Kelvin is done by the EC. Independent hardware logic inside
the module triggers RF or tuner interlocks in the event of achange outside preset levels stored in EPROM. Fault
information is stored and can be read via the the 064 bus.
A dedicated module in the cryostat EC provides a readout of
liquid helium level in the cryostat This, together with the gaspressure readings and RF levels, is made available via hard
wired links to the regulation system of the cryogenics plant
The design of the above equipment and interface hardware
has been finalised and the material for the 180 cavities yet to
be installed is being manufactured in outside industry.

S04SRS01
Status Reports: Subsystems

159
159

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S04SRS01

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS02

A PC BASED CONTROL SYSTEM FOR THE CERN ISOLDE SEPARATORS
R. Billinge, A. Bret, I. Deloose, A. Pace and G. Shering.
CERN, PS Division
CH-1211Geneva23, Switzerland

Abstract

Computers, Network and Control boards

The control system of the two isotope separators of
CERN, named ISOLDE, is being completely redesigned withthe goal of having a flexible, high performance andinexpensive system. A new architecture that makes heavy useof the commercial software and hardware available for thehuge Personal Computer (PC) market is being implemented
on the 1700 geographically distributed control channels of theseparators. 8 MS-DOS™ i386-based PCs with about 80
acquisition I control boards are used to access the equipments
while 3 other PCs running Microsoft Windows™ andMicrosoft Excel™ are used as consoles, the whole through a
Novell™ Local Area Network with a PC Disk Server used asa database. This paper describes the interesting solutions
found and discusses the reduced programming workload andcosts that are expected to build the system before the start ofthe separators in March 1992.

The Isolde Control system is simple. It has Olivetti
personal computers (PC) at all levels connected using thegeneral purpose Ethernet network available side-wide.
As console in the control room, Olivetti 386/25 are used.
i486 based PCs may be introduced next year. The console
computers are equipped with 21 inch monitors providing agraphic resolution of 1024 x 768 pixels on 16 colors. Apartfrom high resolution monitors, the console computers are
identical and fully compatible with the several hundred PCs
available in the offices as local workstations [6].

Oivelli38612S
Fiont End fol H W and Nln.morlalian

I THE ISOLDE PROJECTThe ISOLDE project consists of the move of CERN's
Isotope Separators and their experimental area from therecently de-commissioned Synchrocyclotton to a beamline
served by the Booster Synchrotron [l] [2]. A new control
system was required.
Traditionally, control systems for accelerators have been
designed based on specified functionality, and the hardware& software tailored to optimize potential utility. Frequently
however, this results in 'home-grown' products which remain
incomplete and are overtaken by the rapid advances of themassive industrial base of commercial products.
The ISOLDE Project was taken as an opportunity to
explore the extreme opposite approach for the control system.
Namely to use 'market-leader' commercial software &hardware available for the huge PC market, with in-housedevelopment limited to the necessary software & hardwareinterconnects. This represents an experiment in providing an
inexpensive, user friendly control system, requiring aminimum of manpower both for the implementation & forsubsequent maintenance.

II THE CONTROL SYSTEM ARCHITECTURE
The new architecture [3] [4] (5) being installed reuses theold camac hardware while allowing an evolution of thesystem towards modem solutions.

The Isolde control system architecture

The personal computers connected to the equipment are
called Front End Computers (FEC) and are also Olivetti
386(25. The performance of these computers is entirely
satisfactory and 80286 PCs have enough CPU power to drive
the equipment. In fact for some FEC applications, old IBM
AT computers are used, recuperated from the initial Large
Electron Positron Collider (LEP) front end controls, now
replaced by faster Olivetti PCs. The Front End PCs are
identical in configuration to the Office PCs except that they
have additional boards for control.
The kind of control/acquisition boards supported in thisarchitecture are:
CAMAC, to allow the recuperation of all the
hardware in the existing control system.
GPIB to drive sophisticated instrumentation
Industry Standard Architecture (ISA), alias
PC/AT, boards that plugs into the PC directly orin ad hoc extension chassis.
A wide offer of this last type of boards exists and it has,for the moment, being restricted to Analogue to Digitalconverters (ADC), Digital to Analogue (DAC), Digital Input
and Output (DIO), timer interrupts and external interrupt
boards and RS232.

S04SRS02
162

Status Reports: Subsystems

162

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

STATUS OF THE CONTROL AND BEAM DIAGNOSTICSYSTEMS OF THE CRYRING PROJECT
J.Starker and M.Engstrom for the CRYRING project group
Manne Siegbahn Institute of Physics
S-104 05 Stockholm, Sweden

Ab1tract-CRYRING is a facility for research in atomic,
molecular and nuclear physics. It uses a cryogenic electron beam ion source, CRYSIS, together with an RFQ
linear accelerator as injector into a synchrotron/storage
ring for very highly charged, heavy ions. The first circulating beam was achieved in december 1990. The statusof the systems for control a.nd bea.m diagnostics a.re described.

Light atomic or molecular ions can a.lso be injected froma. small plasmatron source (MINIS). Ions from the ion
sources are accelerated electrostatiea.lly to 10 keV per nucleon and transported to a radiofrequency-quadrupole linear accelerator (RFQ) which brings them to 300 keV per
nucleon. The ions are inflected electrosta.tically into thering where they are accelerated using a. driven drift tube.
The stored ions will be cooled by a.n electron cooler: Fig. 1
shows a. layout of the CRYRING facility.

INTRODUCTION
The control system is based upon the LEAR (Low Energy Antiproton Ring) control system at CERN [2]. The
prindples of the system, the ma.in pa.rt of the softwareand some parts of the actual hardware implementation
a.re copied from the LEAR system. A substantial a.mountof development work has nevertheless been put into the
CRYRING control system in order to adapt it to our operational needs which are partly different from the ones at
LEAR.

The CRYRING project [1) is centered around a synchrotron/storage ring of maximum rigidity 1.44 Tm, corresponding to a.n energy of 24 Me V per nucleon a.t a chargeto-mass ratio q/ A = 0.5. It is ma.inly intended for highly
charged, heavy ions produced by an electron-beam ion
source (CRYSIS).

Fig 1 CRYR.ING layout.

S04SRS03
Status Reports: Subsystems

167

167

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S04SRS03

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS04

MAGNET TEST FACILITY CONTROL SYSTEMFOR SUPERCONDUCTING MAGNETS OF UNK
A.l.Agueev, V.N.Alferov, K.F.Guertsev, V.I.Gridassov,
A.A.Gussak, A.F.Dunaitsev, V .A.Krendelev, A.F.Lukyantsev,
V.M.Proshin, V.E.Solovyov, A.N.Sytin, EA.Ustinov.
IHEP, PROTVINO, USSR.

1. INTRODUCTION

An UNK Magnet Test Facility (MTF) is being
constructed to provide cryogenic, electrical and magnet
tests of superconducting (SC) magnets of UNK. The mainparts of it are:
- The cryogenic system consisting in its tum of the centralliquefier, ten satellite refrigerators, two compressors,
purification system and trans/er lines. The central liquefiersupplies the satellite refrigerators with liquid helium. Theliquefier is manufactured according to the scheme

Item
1

2

Reference andcalibration
dipoles

Dipoles andquads
measurements

incorporating precooling by liquid nitrogen, two tuibine
expanders and a wet expander.
- Four 8 KA, 24 V, ramped Power Supplies (PS) for cold
testing of SC magnets, two 3 KA PS's for instrumentation
testing and calibration.
- Test facility in its tum consisting of:a) two dipoles and one quad benches for warni
measurements;b) eight dipoles and two quad benches for coldmeasurements;c) two benches for instrumentation.
Relevant parameters and technique are given on table:

Parameter
Axis field

Technique
NMR - method in thecentral region andHall - method at
the end parts

Multipoles

Rotating

Effective length
Multipoles

Rotating coils
NMR

coils

,.";:

Field angle
Magnetic axis

Stretched wires

Dynamic
multipoles

Stepwise coil rotation
Measurement oftransition process
after dB/dt-+O

The systems for warm measurements of SC coils and measurement stations) Control system is designed as acold measurements of quads, including measurements of mixture of 3 different subsystems with different
the magnetic axis location and alignment of the reference phylosophy, but connected by LAN, sharing the same Hosttarge4 are being developped jointly with Saclay (France).
Computers, and based on the same hardware andTotal production rate of facility intended to be 2,4 SC computers.
magnets per day.
Such a complex of equipment requires a Control sys2. HARDWARE CON FIGURATlON. tern which provides automatic monitoring, control ofequipmen4 data aquisition and storage into files of magThe hardware configuration is shown on Figure.
nets. Taking into account the difference between 3 pieces
PC/ATs were chosen as a suitable computers for real timeof an equipment (cryogenics, PS's and electrical/magnet
control of groups of equipment and measuring benches.

S04SRS04
Status Reports: Subsystems

171

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS05

BEAM EXTRACTION CONTROL SYSTEMSOF THE FAST-CYCLING SYNCHROTRON
A.Toumanian, N.Zapolski, V.Nickogosian, A.Ananian,A.Kazarian, H.Khoetsian, A. Agababian, A.ttatevosian
Yerevan Physics Institute, Armenia
Abstractofsystemcontrollingthedifferent
beams<gamma,A
compact
extractionofelectron, synchrotron
andsimultaneousradiation)

operation

in

modes

singleatelectromagnetic disturbances level basedusing one computer of IBM PC/AT type

the

using

additional

theonto two internal targets there is al!iOuseda system of changing the betatron oscillationonisfrequencies of·the circulating particl- withthe help of the lenses set on the orbit. To
realize the slow extraction of the pri111ary
beams

introduction

to

the

vicinityofthenonlinearresonance of the third order the conventional
system of magnetic elements <quadrupole andPhysical research program at the Yerevan
synchrotron pursues therealization

experi111ents generally with

the

use

the

is used.

ofthecoils of the electromagnet

extractionofprimarybPam~in single

andsi11ul taneous - opera ti on

GeVenergywithmagnetic

field

top.

processofextraction,thetuning

The

of

and

the

secondary

the

most

sextupole·lenses; septum and bending magnets>

of

slow

precision

with

high

described.

modes at 4.5

orbit

electromagnetic coils of the guiding aagnetic
field. At the beam guidance simultaneously

4-8

beam

ele11ents

and

are

additional
suppliedthe current pulses of the complicatedbyshape,

produced ·by the reSCll'lance for111ing lines withthe use of the thyristor switches. The tuningµs

complicatedrequiring

Magneticof the fcrm

thepulses is

extraction

and- amplitude
realized

by

of

the

means

of

current
thefacecontrol ·of thyristor switches with the use ofdPvices and not having analog in the world isthe synchronizing pulses from the synchrotron

the lllQde of simultaneous beam guidance to thetwo internal targets, one of which is a thintimer device.

pulse form and the intensitychangesduringcrystal, the other one is of

out

many

and

is

put ·intheThe

controlofthicktungsten

the beam extraction is carriedneighbouring

focusing

pickups.

thecurrent
byinterval of the synchrotron. At the same time
it isnecessarytoprovideasignificant

decrease of the beam pass factor through1. Architecture and the control systemthethin target by screening from theparticles,

once passed through it by means oftarget ru.

theconstruction principles
The

thin

the

Due to the'developed and described

firstcontrolsystemsynchrotron extraction device

below

controlcomputersofwasEC1010

the

based

and

on

EC1011synchrotron

CVideoton fir111, Hungary> C2l. But the lack ofreliability in their MDrk and the relatively

extraction devices it was managed to increase

expensive·-intenance showed the necessity ofthecontrol

the

ratio

bremsstrahlung

system
of

of

the

the
pick

coherent

from

the

thin

crystal target to the amorphouspartalmost2.5-~

radiationoftoparllllleters, that isthetoextracted
say

to

the

computers•

The

for

It

PC/AT

was

chosendetermined the architecture

ti11es with keeping unchanged the common

requirements

replacing them by the modern
computerofsystem frOlll the one hand and from

beam

the

stablerequirements

flexibi.lity

at

of
high

that.
the

control

the

other

reliability

and

level

the

of

uniformity and duration of the extraction,effectiveness of the extraction and so cm·.

electromagnetic noises were satisfiedbyhaving an intensive information flaw, a large

Secondary beam extraction of the Yerevan
synchrotron is based on the local disturbanceThat's why ·a mixed

number of the control paratnet.ers·and
3-levelSDarchitectureon.
of

S04SRS05
174

Status Reports: Subsystems

174

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS06

Instrumentation & Control System For PLS-IM-T 60 MeV
LIN AC
D.K.Liu, K.R.Yei, H.J.Cheng, L.P.Yang, C.Z.Chuang
W.Yue, P.Lu, Y.H.Su, Q.Lin, H.Huang
Institute of High Energy Physics
P.O.Box 918 Beijing.

AbJtract
The PLSJ MT is a. 60 MeV LINAC as a preinjector for
2 GeV LINAC of PLS project. The instrumentation andcontrol system have been designed under the institutional
collaboration· between the IHEP (Beijing, China ) and
POSTECH (Pohang, Korea). So far, the I&C system arebeing set up nowadays at the POSTECH of Pohang. This
paper describes its major characteristics and present status.

I. INTRODUCTION* Powerful software support such as RMX286 and
RMX51 are an excellent developing environment. The
function that have to be explicitly coded can be greatly
reduced by making system calls. A BITBUS drive canbe run under the RMX286 which allows messages passing
across the SBX interface on down the BITBUS network.
* More second source: We should consider the situationthat developing this system is in China, and commissioning and maintenance is in Korea. So we must get theseproducts easily from the market of both country.
VOICE COITTROLUR

VOICE COHTIIOLURThe Concept Design Research(CDR) of PLS 60 MeV
LINAC has been completed in 1989. The construction of
PLS 60 MeV started in July, 1991. The accelerator column and electron gun have been installed earlier. The
gun pulser has been tested with 3.5A 2ns pulse width withsuccess and Modulator, microwave system and I&C sys.tem
will be set up soon. The commissioning of whole system
would be completed around the end of this year or next
spring.
The l&C system of PLS 60MeV is a compact and complete hierarchical distributed control system. Therefore itis small system and it includes all of the essential control
structure and various beam monitor, high speed electronics
modules etc. for LINAC operation.

To ltam
Monitors i

From Rr.vSWR.

HY,Vocuum,rtrt,
Caft,ttc•.

II. SYSTEM STRUCTURE

To Modulator

In a centralized control system, computer failure will ca.use
a failure that will shut down the entire system. However, a
distributed system is more costelfective and becomes easily
modified.
According to the requirements of physics and our previous experience, and considering the entire budget, scheduleof l&C of PLS 60MeV, we compared various structure ofcontrol system [lJ, and adopted the Intel BITBUS architecture. The major reasons are as follows:* BJTBUS distributed control system is a commercial
product* High performance microproc.essor could be useful for
local station.

Flg.1 ltc orchteciure for Preln!ecior of PLS

i Kly11ron

E11ctronl1:1

According to the considerations above, the system architecture is illustrated in Fig.I.
There are four stations linked with BITBUS network,
each station has its own resource and tasks respectively.
Those local stations are Modulator-Klystron Sta.tion(MK),
Magnet power station(MG), Beam diagnostics station(BM) and Interlock sta.tion(IL).
In general, entire task are hierarchically managed. Each
local station completes data acquisition and data control
during the 5rns period. the details of MK local station

S04SRS06
Status Reports: Subsystems

177

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS07

Multi-Microprocessor Control of the Main Ring Magnet Power Supplyof the 12 GeV KEK Proton Synchrotron
T. Sueno, K. Mik:awa, M. Toda, T.Toyama and H. Sato
National Laboratory for High Energy Physics
and S.Matsumoto,Physics Division, Dokyo University School of Medicine
l.INTRODUCTION

Abstract
A general description of the computer control systemof the KEK 12 GeV PS main ring magnet power supply isgiven, including its peripheral devices. The system consists ofthe main HIDIC-V90/2S CPU and of the input and output
controllers IDSEC-04M. The main CPU, supervised byUNIX, provides the man-machine interfacing and implements
the repetitive control algorithm to correct for any magnet
current deviation from reference. Two sub-CPU's are linked
by a LAN and supported by a real time multi-task monitor.
The output process controller distributes the control patterns
to 16-bit DAC's, at 1.67 ms clock period in synchronism
with the 3-phase ac line systems. The input controller logs
the magnet current and voltage, via 16-bit ADC's at the same
clock rate.

..1 r·i

66KY

lsml
YC:•

Ism!

•-z

[ill]
YC:W 0T. zxv

vca ·~

T. llYeL.l

The main ring magnet power supply consists of 10
twelve-pulse thyristor rectifiers with de filters, of 2 reactive
power compensators [1] with tuned ac harmonic filters [2] andof an analog and digital hybrid control system (3]. A
schematic diagram of the power supply is given in Fig. 1.
Fig.2 shows the principle layout of the hybrid control
system. Eight rectifiers feed the bending magnets and theother two excite the horizontally and vertically focusing
quadrupole magnets. Fine adjustment of the current 111
injection and of the ratio between currents of the bending andthe quadupole magnets is required to tune the acceleration.
The current of the quadrupole magnets must be tracked
separately from the current of the bending magnets for precise
Q-tuning and optimum beam acceleration.

7., 2:itV

900A
iSOlllY4,...-.........___,

•Ga4

•oOA

(S0WY6tSOMV•....---......

31 6.UY....

lsml Ism I Ism!
lZlt"f'

3 5

ff

ff
I'

D II II

"

M

2 3 3
MMM

2

M

v

e
M
v

A

AAA

A

A

p

2 I
MM

I

A A

v v

ff

3It T
' T
7

It T

D ff

v

v v v

D. C.

FlLTER

Baraouic

FlLTER(A. C. FILTER)

"'

M

v

A

I

e
v

M

A

..

{ ···"""
lr,;n;;;;;;.__---IJ It--__;;=-.

·------···--~~..··
...

\ •.
\

8•1!11neh

Fig.I Schematic Diagram of the KEK 12 GeV PS Main Ring Power Supply.

S04SRS07
180

Status Reports: Subsystems

180

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS08

VME COMPUTER MONITORING SYSTEM OF KEK-PS
FAST PULSED MAGNET CURRENTS AND BEAM INTENSITIEST.KAWAKUBO, A.AKIYAMA, T.ISHIDA*, E.KADOKURA
National Laboratory for High Energy Physics, 1-1, Oho, Tsukuba.-sbi, lba.ra.ki-ken, 305, Japan•'Mitsubishi Electric Company, 1-7-4, lwamoto-cho, Cbiyoda.-ku, Tokyo-to, 101, Japan

Abstract
For beam transfer from the KEK-PS Linac to the
Booster synchrotron ring and from the Booster to theMain ring, many pulse magnets have been installed. It
is very important for the ma.chine operation to monitor
the firing time, rising time and peak value of the pulsed
magnet currents. It is also very important for magnet
tuning to obtain good injection efficiency of the Booster
and the Main ring, and to observe the la.st circulating
bunched beam in the Booster as well as the first circulating in the Main. These magnet currents and beam
intensity signals a.re digitized by a digital oscilloscopewith signal multiplexers, and then shown on a graphic
display screen of the console via a VME computer.

2. PURPOSE OF THIS SYSTEM AND
REQUIRED SIGNALS
A. Observing pulsed magnet current
In order to observe the opera.ting conditions of thepulsed magnets, the following magnet currents should
be observed with proper time scale:• For Booster Injection:- four Bump magnets in series• For Booster Extraction:
Bump(#l,#2)- Septum(#l,#2)

1. INTRODUCTION- Kicker(#lrv#4)

There are many pulsed magnets and beam monitors which concern beam injecti<m and extraction of the
KEK-PS-Booster as well as beam injection of the Main
ring. In order to tune the ma.chines and to search trouble
points, it is very important to display these signals using
proper trigger timing. Because we must select a proper
signal and trigger among many connectors and choose aproper time scale, voltage range and trigger level, only
a few trained crew members had been able to observe
the expected signals within a short time. By using signal multiplexers, a digital oscilloscope with GPIB anda VME computer system, however, we can now observe
the expected signals without any great effort using atouch panel of a. console desk in the PS-control room.

*When you observe rapid changing figures as a kicker current
and a fast beam intensity in the control room, the figure deterioration through a long co-axial cable becomes problem. We havere-shaped the deteriorated figure to the original by the "equalizer" ma.de by Dr.S.Ninomiya. We would like to acknowledge him
for his offering of his instrument.

• For Ma.in Injection:- Septum(#l,#2)- Kicker(#lrv=lf.5)

B. Checking the magnets' firing timing
For beam transport from the Booster to the Mainring, just after firing the Booster extraction septums
and carrying out time-matching of an RF bucket of the
Booster ring with one of the Main ring, Booster extraction bumps are fired; after a.bout 20µ sec, four kickers
are fired at the same time. After a transfer time fromthe Booster to the Ma.in, firing of five Main injection
kickers follows. In order to check these timing, it is convenient to display the concerning magnet currents anda bunched beam intensity with a "mountain view"*.

S04SRS08
184

Status Reports: Subsystems

184

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS09

Magnet Power Supply and Beam Line Control
for a Secondary Beam Line K6
Y.Suzuki, M.Takasaki, M.Minakawa, H.lshii,
Y.Kato, M.leiri, K.H.Tanaka, H.Noumi,
and Y.Yamanoi
KEK National Laboratory for High Energy Physics
1-1 Oho, Tsukuba, Ibaraki 305, Japan
Abstract
K6 is a secondary separated-beam line with
momentum range up to 2.0 GeV/c in the north experimental
hall al the KEK 12 GeV Proton Synchrotron (KEK-PS). On
1he construction, newly developed magnet power supplies(MPSs), in each of them a microprocessor is embedded, areintroduced. The features of the MPS are as follows:
1, The MPS is connected to an upper-level beam line
controller (BLC) by GPIB highway for exchanging simple
messages.
2, All the operations of the MPS are supervised by the
microprocessor, which has its individual parameters and fault
messages. IL reduces the load of the upper-level controller.
3, The MPS has functions to inspect itself and to report theresult. ll saves much time and labor of maintenance.

These design concepts were reported several years
ago, [3], [4]. Though effective, those design concepts havebeen applied to few devices on the accelerator field up lo
presenl
We introduced this design concept in to beam line
control system, and developed MPS. Now we are saving cost ,time, and trouble.
This paper report this MPS's PSC and beam line
control for K6. The details on soft program and hardware will
be reported elsewhere.[5]POWER SUPPLY CONrROLLER (PSC)

Hardware
PSC consists of five boards (STD: IEEE-961):(1) CPU board: Z-80, GPIB communication interface.

lNrRODUCTION(2) DAC board: 16-bit DAC, for reference voltage.
On the KEK-PS site, there are two experimental halls
for high energy physics experiments. The one is the East
experimental hall (E-hall), that has been servicing since 1977.
The other is the North experimental hall (N-hall) built in
1990, where the construction of the new beam line K6
construction is under going.
In N-hall, the beam lines were designed for highimensity proton beams against high radiation field. The R&D
for the beam line components has made during the last few
years. The design of the magnets and vacuum system werereported in [l]. On the other hand, magnet power supply(MPS) and control system have also been developing [2].
On the construction of the K6 beam line, newly
developed MPSs were introduced. Each MPS has a
microprocessor, ADC(analog to digital converter), DACs
{digital to analog converter), relay J/O(input and output), andGPIB(IEEE-488) interface. The digital processing unit i.e.
magnet power supply controller (PSC) is incorporated into the
MPS to have functions; ON, OFF, reset of interlocks circuit,polarity switch, current/ voltage control mode, current settingwith appropriate speed, and checking the health of the MPS
without help of upper-level beam line controller. These
functions are invoked by a simple message, for example;
current setting message; "A 1234.0" means to set outputcurrent to 1234.0 ampere. This message is sent to MPS froml3LC through a single coaxial cable; GPIB highway.

(3) ADC board: 16-bit ADC, for monitoring DCCT (oulpul
current).
(4) ADC board: 12-bit ADC, 16-channel multiplexer.
This board is used for monitoring the following
values:1, Reference voltage (16-bit DAC).
2, MPS's DC output voltage
3, MPS's output voltage for monitoring Wave Form.
4, MPS's AC input current .
5, Input voltage of firing module.
6, Seven points on low-voltage power supplies.
(5) Relay 1/0 board: for control and monitor.
The control points are:1, ON/OFF2, Reset of interlock logic.
3, Polarity switch.
4, Regulation mode (voltage or current).
5, Remote or Local
Input points for monitoring status are:1, Control power ON/OFF.
2, Remote/ Local.
3, Main switch, ON/OFF.
4, Polarity +/-.

S04SRS09
188

Status Reports: Subsystems

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS10

SPECIFIC BEAM DELIVERY SYSTEM OF MEDICAL ACCELERATOR HIMAC
S.Minohara, T.Kohno, M.Sudou, M.Endo
T.Kanai, F.Soga and K.Kawachi
Division of Accelerator Research
National Institute of Radiological Sciences
Chiba , JAPAN
2) Irradiation time per patient must be less than a few
Abstract
A specific beam delivery system for radiation therapy in minutes. The reason is that the patient is immobilized on
HIMAC is being designed. This report describes an outline . the couch by the shell or capsule, and immobilization of
longer time gives much stress to the patient with illness.
of the beam delivery control system and its operation.
Now we are estimating that it takes about ten minutes to
set a patient for positioning on the couch. Therefore,
I. INTRODUCTION
HIMAC is a heavy ion accelerator facility designed for treatment time that a patient stays in the treatment room isradiation therapy[l]. Beam delivery system of HIMAC is about fifteen minutes. HIMAC has two synchrotron rings
very specific and different from the ordinary facilities for and three treatment rooms (Fig. 1). In the room B,
experiments of general physics. The treatment control horizontal and vertical beams can be utilized at the same
system for irradiation of patients is closely Jinked with time, and the room A and the room C have the vertical andoperation of accelerator and beam transport. We report an
the horizontal beam course respectively. Accordingly, twooverall idea of HIMAC beam delivery system and its
beams are delivered to four beam ports alternately. The
operation for radiotherapy.
course of each beam is changed at interval of about ten
minutes,and the beam should be immediatly adjusted in
II. CLINICAL REQUIREMENTS
The clinical requirements for radiation therapy are compliance with medical requirement for each patient. To
realize such a rapid change, all magnets along the beamdescribed as follows.
I) At the end of irradiation, three dimensional dose transport lines are actuated by corresponding treatment
distribution at the tumor volume in the patient must be schedule and the beam course can be changed by setting
achieved with an error of less than a few% compared to only one switching magnet in HEBT(high energy beam
the precalculation of the dose distribution by the physician. transport) line. For these reason, switching magnet must
Above all, overdose to the patient must be absolutely have accurate reproducible setting of field strength andavoided.
high stability.
The tumor of the patient as a target is set at the beam
iso-center with an accuracy ofless than Imm. In case of the
Ion Source
abdominal organ as the target,
ECRIS
it is subject to move by
breathing, and the margin of
Injector
irradiated field should beconsidered in thetreatment
planning. Since the shape,
Irradiation
volume and position of patient's
target and the planned dose
distribution are different foreach patient, setting of manykinds of devices in the beam
Therapy A
port varies at the time of each
irradiation. The size of mosttreatment is satisfactory witliina maximum field of22cm indiameter which is based on
Treatment Roomclinical experiences at NIRS.
On the other hand, small fields
such as less than lcm are often
required. Hence, devices ofBeam Transportbeam port must be accurately
adapted for wide range of fieldsize.
Fig. 1 A schematic view of acct:lerators and beam lines

S04SRS10
192

Status Reports: Subsystems

192

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN01

A CONTROL SYSTEM
FOR A FREE ELECTRON LASER EXPERIMENT
D.GIOVE
INFN MILAN -LASA, Via Fili Cervi 201 Segrate (Milan), Italy

Abstract

II. BASIC CONTROL PHILOSOPHY

The general layout of a control and data acquisition system for a Free
Electron Laser experiment will be discussed. Some general considerations
about the requirements and the architecture of the whole system will be
developed.

A preliminary analysis of the characteristics required to the control
system for ELFA pointed out the following items:

I. INTRODUCTION
The aim or the ELFA (Electron LiL,er Facility) experiment is to
study the physics of a single pass FEL amplifier operating in the highgain Compton regime using a short electron pulse beam. The experimental
purpose is the production of high peak power (0.3-1 GW) of microwave
radiation, with a basic wavelength of Ar=3 mm, and the possibility oftuning from ~ = I cm to ,\ r=0.1 mm. In order to achieve this goal anelectron beam of very high current (400 A) in short pulses (6 cm) and witha maximum energy around 10 MeV will be injected into the wiggler
midplane.
The accelerator consists or two sections: a photocathode injector
providing a 3.5 MeV beam and a superconducting LEP II module toincrease the energy up to 10 MeV. The wiggler will be a composite one,consisting of two coupled sections: the first part made with an hybrid
structure (iron poles and pennanent magnets) and a second part with ane.m. structure. A complete review of the project is given in [I) and ageneral layout of the experiment is showed in fig. I.
The ELFA project has been funded by INFN and a lot of work has
been done in order to define the conceptual design of the major
components and to deeply investigate the FEL physics.

INJECTOR- ELFA needs both a control and a data acquisition system. Since ELFA isan experiment iL-;elf it is mandatory to have a complete data acquisition
system for the measurements which have been planned to verify the basic
ideas of the projecL It is not possible to separate machine operations fromphysicist work. The two systems must be designed at the same time,sharing , as much as possible, the same philosophy and allowing an easy
exchange of data.
- ELFA would take at least one year to "freeze" the characteristics of the
major components. Nevertheless before of these period the control
philosophy has to be fully developed and tested, in order to be an intrinsic
feature of every componenL A control system must play a central role in
the whole design of a machine, to be really effective and to justify its
budget requirements,. It is an old-fashion, money-wasting philosophy that
one which consider the control system as just an "add-on" of the machine.
In this way the control equipments just duplicate features already present
and does not provide any improvement in performances. At the samecareful attention bas to be paid in order to evaluate the trend ofdevelopment of computer technology. One bas to balance today
requirements and needs, with tomorrow availability and costs. This is moredifficult to do since the different growth rates of the two basic components
of a computer system : hardware and software.

4 CELL LEP II MODULE
Nd-YLFLASER

HYBRID + E. M. IJIGGLER

CJJTPUT

WIAT~

..,.
352

MHz

ACCELERATOR

Fig.1 -General layout of the ELFA experiment

S05SRN01
Status Reports: Non-Accelerators

195

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN02

Control System for JAERI Free Electron Laser
Masayoshi Sugimoto
Japan Atomic Energy Research Institute,
Tokai-mura, Naka-gun, Ibaraki-ken, 319-11 Japan
Table 1Main characteristics of JAERJ FEL(first phase)

Abstract
A control system compnsmg of thepersonal computers network and the CAMAC
stations for the JAERI Free Electron Laser isdesigned and is in the development stage. It
controls the equipment and analyzes theelectron and optical beam experiments. The
concept and the prototype of the control
system are described.

Electron Energy
Energy Spread
Peak Current
Pulse Width
Repetition
Undulator Pitch
Laser Wavelength
Laser Peak Power

I. IXTB.ODUCTIOXThe Free Electron Laser (FEL) facility,
SCARLET (Superconducting Accelerator for
Research of Light Emission at Takai), is now
under construction at JAERI[l-31.
It is afirst step of the FEL program and the aim is
the R&D of the superconducting accelerator(SCA) based FEL system in 10-50 µ,m range.
The SCA is employed due to the suitability
for the cw operation in the second phase of
the project. The layout is shown in figure 1
and the main characteristics are described intable 1.
Resonnator

Superconducting Accelerator(single cefl, Pre-accelerator)

Superconducting Accelerator(5 cells, Main accelerator)

Figure 1. Plan view of the accelerator roomof the JAERI free electron laser facility.
The accelerator itself is a small sizewith less than 20 m length, however, it would
be expanded to 60 m in the second phase.
In the design of the control system of the
JAERI FEL, which will be also used in thenext phase, the requirements were posed as:
1. Flexibility for evolving the system,
2. Reliability of hardware and software,
3. User interface for operator console,
4. Integrity of control and simulation,
5. Distributed control for fast response.

SPECIFICATION

ITEM

14 - 23 MeV< 0.2 %
> 10 A
40 ps
10.4 MHzll:i 3 cm
10 - 50 µ,m
1 MW

II. H!B.DWA.B.E A.B.CJllTECTUB.E

In this project, the flexibility has thehighest priority to accommodate the frequentchange and upgrade of the hardware devices
in the development stage and at the next
phase. The devices in the facility are divided
into three subgroups: (1) the injector section(electron gun, sub-harmonic buncher, buncher,and injection beam transport line), (2) theaccelerator section (superconducting cavities, rf
power supply, refrigerators, momentum filter,
achromatic bend line) and (3) the optics
instruments(undulator,
mirrors,
opticaldetectors).
They are well isolated by thelocations and their functions.
Each subgroup is controlled by a local
unit equipped with:• a 32-bit personal computer (NEC PC
9801:cpu i80386 16/20MHz, 3-5 MB
RAM, 14-in CRT) with minimal
peripherals to control the local unit
alone,• a dedicated CAMAC crate system withparallel bus crate controller, whichcontains analog i/o, digital i/o and
GPIB interface modules,• an Ethernet interface.
The main console unit consists of two
personal computers, one is used to control thetasks in the network and another is used toanalyze and display the acquired data or
on-line processed results in a 21-in CRT.
These ate connected by Ethernet and SCSIS05SRN02
198

Status Reports: Non-Accelerators

198

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

Control Software for the ESO VLT
G.Ra.ffi, European Southern Observatory (ESO)
8046 Garching, Germany
Abstract
The Very Large Telescope (VLT) project of ESO consistsof an array of four optical telescopes of 8m diameter, tobe installed at a new site in the Atacama desert in Chile
starting in 1995.
The control software is completely distributed, being
based on LANs interconnecting microprocessors and workstations, where several users and operators will be activeat the same time.
Microprocessors are used in a variety of control functions, including the active control of the shape of themain mirror and compensation for atmospheric turbulence.
Dedicated links and antennas are planned for direct communication and remote observation from various European
centers.
The main concepts and novelties of the software design
are explained.

The use of a chopping secondary mirror has been proposed.
The VLT site is the Paranal mountain in northern Chile,in the Atacama desert at an altitude of 2700m.
Figure 1 shows the telescope layout foreseen for the topof mount Par anal. The first telescope is due to be installedat the end of 1995, with each following telescope being
installed at time intervals of one year.
The whole VLT program including instrumentation will
be concluded some years later. This gives a very longtimespan for the installation of the VLT and of the control
system in particular.
\
I
\
\
I

I

\

I

I. THE VLT PROJECT
A

I
I
I

Main characteristics

The VLT project has been initiated with the aim to provide
European astronomers with a ground based telescope oflarger size than those presently available [l].
The VLT concept consists of an array of four identicalmain telescopes, each having a thin monolithic mirror of
8m diameter. This gives an equivalent total size of 16m,
when the four telescopes are used together, which shall be
the largest size available on ground telescopes at the endof the 90s. The large size of the array will allow a very
high angular resolution (the possibility to resolve details).
Each main telescope has an Alt-Azimuthal mount andis equipped with instruments at the two Nasroyth foci,Cassegrain focus and Coude focus.
The four main telescopes can be used independently, orin several combined modes. One of the combined modesis the incoherent beam combination in a combined Coudelaboratory.
The other combined modes foresee coherent beam combination in an interferometric laboratory. In this case theuse of two or more auxiliary telescopes of l.8m diameteris also foreseen. These should be moveable on tracks. Optical path differences will be compensated with the use ofdelay lines and the optical beams are brought to interfere.
Astronomical images can then be reconstructed startingfrom the interference patterns.

I

\

\
I
I
I

r
I
I

I

I

I

I
I

' ..... _----Figure 1: VLT observatory

B Special aspects
Special aspects of the VLT telescope with respect to othertelescopes are:• system distribution
This is implied by the fact that the VLT is an arrayof four telescopes.

S05SRN03
202

Status Reports: Non-Accelerators

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN04

Distributed Control And Data Acquisition For The
EUROGAM Gamma Ray Spectrometer
ECG Owen
Daresbury Laboratory
WARRINGTON WA4 4AD

UK

Abstractwith the overall system structure being arranged in a
distributed computing architecture. Figure 1 shows thelayout of the system and its component parts.

EUROGAM is an Anglo/French Gamma Ray
Detector which will alternate between the Tandem Van
der Graaf at Daresbury and the Vivitron at Strasbourg.
Because of the need to confonn to the standards ofLaboratories in two different countries, and the very
sensitive nature of electronics for Germanium Ganuna
Ray telescopes. the newly emerging VXIbus (YM.Ebus
E,Xtensions for Instrumentation) was chosen as the basis
for control and data acquisition. This entailed a major
progranune of development for both the · signal
processing front end modules for Germanium andBismuth Gennanate detectors, and also for the hardware
and software management of resources from within the
VXI environment The paper will concentrate mainly on
the latter areas.

''

''

''

i.a:pfmqiMI "m1Mcnrloc',

I. INTRODUCTIONEUROGAM is a high · resolution gamma-ray
detector which is being constructed to answer the many
exciting questions raised through recent discoveries in
Nuclear Physics. Phase I of the EUROGAM arrayprovides 45. Germanium (Ge) detectors with surrounding
Bismuth Gennanate (BGO) detectors being used toprovide the suppression shields. A second phase isplanned which will provide a 70 detector system.
EUROGAM is a joint development project between
lnstitut National de Physique Nucleaire et de Physiqueles Particules (IN2P3), France, and the Science andEngineering Research Council (SERC), UK. The arrayis expected to come into operation at the Nuclear
Structure Facility at Daresbury Laboratory, UK, early in
1992 and will run for one year following which it will betransferred to France to operate on the new Vivitron
accelerator which is being commissioned at Centre deRecherches Nucleaire, Strasbourg (CRNS).

EURQGAM Phase I sya!em ln!grconnes:!lons,
FIQJR.£ 1~

VXI is used to front-end the system and has enoughelectric and magnetic shielding to allow the treatment of
analogue signals to very low noise levels This permits ahighly integrated approach to be taken in the electronics
units designed for the processing of pulses from detector
channels. VXI also :minimises the inter-unit cableconnections required and hence increases reliability.
VXI also provides a full implementation of a 32 bit
VME bus for general control of cards in the crate,
read-out capability and multi-master processor access.
The enhanced features contained in the VXI standard

It TECHNOLOGYTo provide data acquisition, control and monitoring
functions for EUROGAM, a mixed solution based on
VXI, VME and UNIX workstations has been chosen

S05SRN04
208

Status Reports: Non-Accelerators
208

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN05

A Control System of the Nobeyama Millimeter Array
Koh-Ichiro Morita, Toshikazu Takahashi, Hiroyuki Iwashita,
and Tomio Kanzawa
Nobeyama Radio Observatory, National Astronomical Observatory
Minamimaki, Minamisaku, Nagano 384-13, JAPAN

Abstract
We have developed a control system of the Nobeyama
Millimeter Array which is a radio interferometer for astronomical observations at millimeter wavelengths. The
system consists of three sub-systems (MANAGER, ENGINE, and STATUS CONTROLLER). Observers conduct
their observations with MANAGER sub-system, which run
on a UNIX workstation. ENGINE is a rigid system on
an IBM compatible mainframe. It controls the accurate
tracking of astronomical radio objects, and acquires a large
amount of observed data from a receiver backend. STATUS CONTROLLER consists of several personal computers which control and monitor the receiver system. These
sub-systems are connected with an ethernet.
Figure 1: The Nobeyama Millimeter Array.

1

INTRODUCTION

The Nobeyama Millimeter Array (NMA) [1] is a radio interferometer for astronomical observa,tions (Figure 1). The
main purpose of the NMA is the high spatial resolution
imaging of celestial objects at millimeter wavelengths.
The array has five 10-m diameter antennas which canbe moved to various stations along two rail tracks of about
600 m. Averaged surface accuracy for five antennas is 71µm rms. Each antenna has an Alt-Azimutial mount andis equipped with SIS receivers [2] at 2.6 mm and 2.0 mm
wavelengths which contain important molecular spectral
lines. The maximum spatial resolution at 2.6 mm wavelength is about 111 • The receiver backend is a 320 MHz
FFT spectro-correlator with 1024 frequency channels percorrelation, called as the Nobeyama FX [3].
The most important requirement for a control system ofsuch an interferometer for astronomical observations is to
track celestial objects accurately [4J. For an interferometer,
the tracking control is much more complicated than thatfor a single dish telescope. To satisfy this requirement,
we constructed a centralized control system for the NMA
on an IBM compatible mainframe [5]. However, since thesoftwares of the system were very rigid, there were somedrawbacks in it ..
'lb overcome t.hese drawbacks, we have developed a newcontrol system for the NMA. It is a distributed system,

based on a UNIX workstation, an IBM compatible mainframe, and personal computers connected with an ethernet. In this report, we will describe the concept and thestructure of the new system.

2

CONTROL FOR OBSERVATIONS WITH THE NMA

2.1

Tracking

Normal observing mode of this array is aperturesynthesis[6]. Figure 2 shows a schema.tic diagram of aperture synthesis observation with two element radio interferometer. A correlator multiplies two radio signals fromeach antenna and averages the product. When antenna
tracking to a celestial object and compensation of opticalpa.th difference between two antennas (delay tracking) are
done accurately, the correlator output is equaJ to a spatial Fourier component of the brightness distribution at a
projected baseline (u, v). After the synthesis observations
at many different baselines, the brightness distribution canbe estimated with inverse Fourier transform.
As shown in Figure 3, we use a heterodyne system for afrontend receiver and frequency of the input signal to thedelay tracking system is lower than receiving frequency.

S05SRN05
214

Status Reports: Non-Accelerators

214

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN06

Present Status of the JT-60 Control System
T. Kimura
Nak:a Fusion Research Establishment
Japan Atomic Energy Research Institute801-1 Mukohyama, Nak:a-machi, Naka-gun, Ibarak:i-ken 311-01 JapanThe JT-60 tokamak is a large scale fusion experimental
device for the study of magnetically confined plasmas near thethermal break-even condition. Since the first plasma obtainedin April 1985, studies on impurity and particle control,
confinement of high-power heated plasmas and steady state
operation by radio-frequency wave current drive and productionof the bootstrap current discharges were performed. The JT-60
tokamak has been upgraded in order to push forward thesefusion researches conducted in the past five-year operation [I].
In the JT-60 upgrade (JT-60U) we can perform deuterium
discharges with plasma current up to 6 MA and additional
heating power of 50 MW. Throughout these investigations
we intend to obtain physical and technological databases forthe next-step machines.
This paper reports the present status of the JT-60 control
system including its original design concepts, progress of thesystem in the past five-year operation and modification for the
upgrade.

features [2]:(1) Hierarchical structure
JT-60U consists of more than ten subsystems such as avacuum pumping system, magnet power supplies and plasma
heating apparatus. These subsystems have to be separately
operated in their preparatory stages before plasma operation.
Moreover, they have to be organized into one system toperform plasma operation.· Hence, the JT-60 control system
has hierarchical structure of its central control system named
ZENKE! and subsystem controllers.
(2) Computer control
Computer control was introduced for the operation of the
JT-60 tokamak. Eight minicomputers and about a hundred
microcomputers are used for a wide variety of control
functions from fast feedback control of plasma discharge tohandling of a large amount of monitoring and control data. In
addition to 16-bit computers in the original control system,
advanced 32-bit microprocessors and workstations have been
newly introduced in the control system.
(3) CAMAC interfaces
Since fabrication for each subsystem was contracted toindustry separately, various kinds of standards for both
hardware and software were decided as IT-60 standards at Japan
Atomic Energy Research Institute (JAERI). CAMAC
standards were adopted for input/output signals from sensors/to actuators and for data transfer between the computers.
(4) Protective interlock by both software and hard-wired
systems
The safety philosophy was established by taking into
account certain key requirements in the design of the JT-60
control system. One of the most important requirements is
personnel safety. This stems from use of high electric
voltage, high magnetic field and possible radiation in the JT60 tokamak. Hence, the protective interlock system with
hard-wired relay logic backs up the computer system from theview point of reliability and safety. Moreover, the concept ofprecaution and protection was introduced in the system design.

2. REQUIREMENTS AND DESIGN PHILOSOPHY

3. SYSTEM CONFIGURATION

Abstract
The present status of the control system for a large fusion
device of the JT-60 upgrade tokamak is reported including its
original design concept, the progress of the system in the past
five-year operation and modification for the upgrade. The
control system has the features of hierarchical structure,computer control, adoption of CAMAC interfaces andprotective interlock by both software and hard-wired systems.
Plant monitoring and control are performed by an efficient data
communication via CAMAC highways. Sequential discharge
control of is executed by a combination of computers and atiming system. A plasma feedback control system with fast
32-bit microprocessors and a man/machine interface withmodern workstations have been newly developed for theoperation of the JT-60 upgrade.

1. lNIRODUCTION

Since the JT-60 tokamak is a large-scale device with 3. 1 Control Configuration
respect to the number of components, their occupied space, theThe control concept of the JT-60 tokamak can be classified
amount of electric power consumption, etc. Since intrinsicallyinto
two categories. One is control for plant control andunstable plasmas are produced and maintained, the control
system is required to have high reliability and high speed. monitoring and the other is for plasma control via actuators
Besides these features it has to possess the characteristics of . used for tokamak discharge.
The concept of plant support control is similar to that inflexibility, expansibility and safety. Hence, the JT-60
otherlarge-scale facilities such as manu~cturing and power
control system was designed and fabricated with the following

S05SRN06
218

Status Reports: Non-Accelerators

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN07

Conceptual Design of Centralized Control System for LHD
H.Kaneko,K. Yamazaki,Y.Taniguchi
National Institute for Fusion Science
Chikusa-ku, Nagoya 464-01, Japan
Abstract
A centralized control system for a fusion experimental
machine is discussed. A configuration whereby a number ofcomplete and uniform local systems are controlled by a centralcomputer, a timer and an interlock system is appropriate forthe control system of the Large Helical Device(LHD). A
connection among local systems can be made by Ethernet,
because a faster transmission of control data is processed by aspecific system.

I. IN1RODUCTION
The National Institute for Fusion Science(NIFS) wasestablished by The Ministry of Education, Science and Culture
in 1989 to integrate all of the inter-university collaboration in
Japan for nuclear fusion research. The new and main projectof Large Helical Device(LHD)[l] at NIFS was approved
during the 1990 Japanese-fiscal-year(JFY). The LHD systempresently under construction at the new site of NIFS in Tokicity, Gifu-prefecture, will be completed in the 1996JFY[2].
The LHD system, with superconducting coils, will be thefirst machine which can sustain the stationary magnetic fieldcomposing nested magnetic surfaces. A magnetic surface isgenerated from a combination of the toroidal magnetic field
and the helical magnetic field. It is the outermost magnetic
surface, which determines the confinement area. A ringplasma with a major radius 3.75m and an averaged radius ofcross-section 0.6Sm is confined. A schematic view of LHD isgiven in Fig. I. The magnetic field is generated by a pair ofFig. I Schematic view of The Large Helical Device

superconducting helical coils and three pairs ofsuperconducting poloidal coils. The stored magnetic energy ina typical 4T operation (the strength of the average toroidal
magnetic field at the plasma center) is 1.63GJ. The initialplasma is usually produced by radio-frequency(RF) power atthe electron-cyclotron-resonance(ECR). The plasma is
subsequently heated by arbitrary use of 20MW neutral beam
injection(NBI), 1OMW ECR heating and 9MW ion-cyclotronrange-of-frequency(ICRF) heating.
The control system for LHD operation must be designed
to ensure the safety of the whole LHD system which contains
sensitive electronics as well as rough facilities handling large
stored energy, high power, high voltage and high current
within the same environment. It also has to manage an
efficient performance of the plasma experiment. There aresome distinctive characteristics in the control of such a large
fusion machine still in an experimental phase.
The reliability is the most important factor in the present
system. Since the power used is sufficient to cause fatal
damage, the safety must be garenteed, including the case of an
accident. A choice of reliable materials and an additional
backup can ensure this reliability, but finally it is related to theavailable cost. Here, we consider only the logical reliability of
the control system.
The flexibility of a configurational setup is very important
for a machine in an experimental phase. Besides replacement,
new types of facilities should be easily added to the system.
Thus, the control system should be flexible.
There are various time scales to be controlled within. The
real-time control in a pulsed plasma experiment is usually too
fast to be treated by an operator's manipulation. Hence, thecontrol of the plasma by an operator is made through preprogramming. Thus, the function of fast control necessary forplasma operation should be excluded from the role of a global
controller. If necessary, such a function must be treated in a
specific controller.
The pulsed characteristics of the plasma experiment, on
the other hand, make the target very clear and simple. All
facilities are operated in order to produce a high-temperature
high-density and well-confined plasma.
'
The last requirement is a possible local operation of somepart of the facilities. When such an operation is demanded,
global safety must be assured by the central controller.'Co~sidering the characteristics of the LHD operation, we
have discussed the conceptual design of the centralized
control, which can more easily establish a logical relation
between various manipulations. By the way, the dataacquisition is closely related to the machine operation.
However, the transfer of the vast plasma data from the dataacquisition system to the control system is not necessary.
Instead, a small amount of diagnostics signal will be directly
provided to the local controller which needs the signal for thecontrol. The diagnostics are loosely coupled to the central
control system.

S05SRN07
224

Status Reports: Non-Accelerators

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN08

STATUS OF LHD CONTROL SYSTEM DESIGN
K, Yamazaki, H. Kaneko, Y. Taniguchi, 0. Motojima and LHD Design Group
National Institute for Fusion Science,
Chikusa-ku, Nagoya 464-01, Japan

Abstract

In this paper, the present status of the control system for
operations and experiments of the LHD system is presented.

The present status of LHD (Large Helical Device) control
system design is described, emphasizing on the plasma
operation modes, the architecture of the LHD control system,
the real-time plasma feedback system with PID or Fuzzy
controllers and the construction schedule of the LHD control
system. The conceptual and detailed designs are under way
taking flexible and reliable operations for physics experiments
into account.

I. INTRODUCTION
The Large Helical Device (LHD) fusion system (1-3) using
1.6 OJ superconducting (SC) magnet is now underconstruction and its plasma experiments will be started in
April, 1997. For this purpose, a new national institute(National Institute for Fusion Science) was established in
May,1989, and a new site (Toki city; one-hour drive from thepresent site in Nagoya) were prepared for these experiments.
The main objectives of the LHD project are(1) the study of the behavior of high temperature I highdensity plasmas using helical torus device forcomprehensive understanding of toroidal plasmas, and(2) the exploration of the prospect to the steady-statehelical system reactor.
The major plasma radius of LHD is 3.9 m , and the magnetic
field strength is 3 Tesla (4 Tesla in the second experimental
phase), which is the largest SC fusion machine now underconstruction. To keep flexible and reliable operations of thisSC machine, a new control concept is required.

II. LHD MACHINE DESIGN AND CONTROLCONCEPT
The LHD system consists of one pair of SC helical coils,
three pairs of SC poloidal coils, plasma vacuum vessel,
cryostat, vacuum pumping system, electric power supplies,
plasma production system, liquid helium refrigerator, three(NBI, ECH, ICRF) plasma heating systems, many plasma
diagnostic systems and so on. All these equipments should bemonitored and controlled mainly from the LHD Control
Building. Especially, the control system should be flexible asa experimental machine and reliable as a large plant.
In contrast to present helical devices, the LHD ischaracterized by the steady-state operation using thesuperconducting helical coils and the built-in divertor, which
requires the elaborate control scheme for operational safety
and the new plasma feedback system for experimental
fie xi bili ty.
These LHD machine and central control systems areschematically shown in Fig.I.

III. LHD OPERATION SCENARIOSThe LHD machine operation is divided into three modes; all
shut-down mode, facility operation mode and experimentmode. The experiment mode consists of the SC magnet
operation mode and the plasma experiment mode (Fig.2).
These modes are defined for clarifying the personnel entrance
permission, magnetic field hazard and possible radiation
exposure. Aside from software interlocks, the hardwareinterlock logic should be determined independent of thesemodes.
Superconducting
Poloidal Coils
Superconducting
Helical Coils~~"-'#11-LL..:·piasma Vacuum

VesselCryostati
Figure I Schematicdrawings of LHD machine (right)
and its control system (left).

S05SRN08
228

Status Reports: Non-Accelerators

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN09

control and Monitoring System Design study
for the UNK Experimental Setups
A. Ekimov, Yu. Ermolin, M. Matveev,
S. Ovcharov, V. Petrov, V. Vaniev.
Institute for High Energy Physics,
USSR 142284 Moscow region Protvino P.O.Box 35

Abstract
At present a number of experimental setups for the new
UNK project are under construction. A common approachto the architecture of control/DAO/trigger systems will be
used in the development of electronics for all thesedetectors. The system analysis and design group has been
formed for this purpose. The group activity is aimed at thedevelopment of such unified system. The group has started
with control and monitoring system as one of the mostimportant parts and the environment for the DAO/trigger
systems. The group activity status report is presented.
1.INTRODUCTION
The construction of several experimental setups isplanned in the frame of the new UNK project at theInstitute for High Energy Physics (Protvino) [1-4]. The sizeand complexity of these detectors is by an order ofmagnitude bigger as compared with those al the existing
proton synchrotron. Table 1 shows the number of channels,
event size and readout event rate for old and new(proposal) experiments.
TABLElNumberof ch.

Event
size(kbyte)

Event
rate
(Hz)

100
250
100
1000
1000
500
600
50-100Exper.

*H>3

FODS-2PR OZASPHINX

1
1.5
25

VES

13

0.1
0.5
1.5
1

NEPTUN
GLUON
MPS
MMS

100

25-50

13

3

80
60

25-100
15-20

The general requirements to the electronics for thedetectors have been formulated in the technical proposals.
The electronics will be developed both at IHEP and atother institutes and organizations who take part in thedetector preparation. The use of industry electronics is also

foreseen. Such a distributed method of the development
requires management and technical coordination when
designing the electronics. A working group for the
preliminary study of the design approaches and electronics
architecture has been formed at IHEP.
2. DESIGN APPROACH

At the beginning it was decided to choose the approachfor the design of the electronics for different experimental
setups, namely: to use specialized electronics designed forthe specific experimental setups, or to use unified
electronics adapted for a specific experimental setup. Bothof them have well-known advantages and disadvantages.
The choice is defined by the size and complexity of thedetector, available funding and manpower, time scheduleand so on. For the experimental setups at UNK it is possible
to note the following points:- experimental setups for the UNK are constructed
practically at the same time,- IHEP will participate in the design of the electronics forseveral (or all) experiments,- the preliminary analysis of the electronics requirements
for different experiments shows the existence of common
functional elements.
With an account of the experience in using unified
electronics for the experimental setups at the existing
accelerator it seems reasonable to use the second approachfor the electronics design at UNK.
As a second step the number of points to be studied at
this preliminary stage have been defined with the aim to
make some recommendation for the following
investigations:- standard modular unified architectures of the electronics
for the experimental setups divided by the numbers offunctional subsystems and levels with the definition of an
unified interfaces,- more detailed definition of this general architecture withthe standard implementation of some parts of the systemand possibilities of adapting these parts to the specificdemands of the experimental setup,- standard framework of the electronics development (tools,
test setups management and so on),- existing experience at IHEP in these areas.

S05SRN09
232

Status Reports: Non-Accelerators

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingHard- and Software for Measurement and Control of thePulse Thermonuclear Installation
V.V.Bulan, E.l.Dudorova, V.l.Zaitsev, A.V.Kartashev,
Yu.H.Lusin, A.l.Hebogin, G.M.Oleinik, Yu. V .Papazyan,
V.H.Savochkin, V.P.Smirnov, V.M.Chikovsky
Branch of l.V.Kurchatov Institute of Atomic Energy,
Troitsk, 142092, USSR

Abstract
This paper describes control and measuring systems of the pulse thermonuclear installation "Angara511. The "Angara-5" operates in a monopulse mode. It
takes a long time to prepare the installation to thework shot . The main information flow about the installation output parameters and the target processes
comes for 10-1-10-B sec. The measuring-control
equipment has a multi-level hierarchy structure
where the lower level is local systems controlled byown computers. Measuring systems containwaveform digitizers different types. The supervisor
console system realizes the communications with thelocal systems, as well as the data acquisition,
processing and storage. Hardware and software
structures are given. Careful equipment shielding
and grounding have provided level of noise 30 mV.
Fast signals processing features are discussed.

It's allows to design systems on base interfaces like
CAMAC,-high risetime of currents and voltages (-1014
V/sec, A/sec) provoke high level electromagnetic
noise and requires the special design on electromagnetic compatibility of equipment.
Such installations are specific systems and requires design the special hard-software for effective
working.
This paper describes the realization experience ofcontrol and measuring systems on the pulse thermonuclear installation "ANGARA-5" (4). The installation consists of 8 modules worked synchronously on common load. Parameters of installation (U = 1.5MV, I =4MA, T = to-7 sec) allow toprovide a. different experiments on thermonuclear
targets heating.

II. HARDWARE

Hardware consists of separate local systems andhas multilevel structure. Local system fragment isHigh power pulse generators had been using at shown in fig.1. The C::AMAC crate blocks or theirfirst as accelerators of high current electron beams VECTOR [5] analogs are placed at the low level and[1), lately have founded use as a driver technology for are controlled by means of CC. The CAMAC crates
inertial confinement fusion experiments. Such are connected in systems by help UNIBUS andgenerator can produce electromagnetic pulses with controlled by means of PC computer through adapter.
power 1013 - to14 Wand duration < 10-7sec on load. Local systems are united in complex and connected
Type of load is determined by experimentally with host computer center by ETHERNET.
program taken place at the installation. High voltage
The technological parameters system ST (realizes
diodes producing intense ion beams are used as load control before-starting preparation) and theat some experiments. Beams energy has been synchronization system SS (determines moments oftransporting on thermonuclear target [2]. Gas jets or switching on installation parts and measuring sysliners different types are used as load at other tems) are control systems in the usual sense. Let's
experiments. In this case ions of load are accelerated consider of structure (fig.2) and functions of local systo axis by means magnetic field of current through . terns.
load [3). It's necessary to note next features of such
Supervisor system SD produces local systems coninstallations that determine structure of control and trol and · provides date acquisition, archiving,measuring systems:
processing and display imaging of information from-small duration of processes in installation after . all local systems.
start (- 10-6 sec). It excepts possibility of control atTechnological preparation system ST realizes all
regime "on line" and requires application of fast necessary operations before installation shot. A main
analog-to-digital converters with buffer memory,
operations are measurement of slow changing-seldom work starts of installation (few starts in parameters ( distilled water resistance, gases pressureday) make easier requires to systems of before-start- In switches, voltage on condensers etc.) and control
ing preparation and to data processing rate after shot. of gases pressure and condenser charges processes.

I. INTRODUCTION

S05SRN10
Status Reports: Non-Accelerators

235
235

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S05SRN10

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

A Control & Data Acquisition Syatea for
Photoelectron Spectroscopy Experiaent Station
at Hefei National Synchrotron Radiation Laboratory
Weiain Xu

HESYRL

Yiain Liu

USTC

Hefei, Anhui 230029
Abstract
The paper describes system configuration and software
design, The system has the following features: flexible.user interface, succinct control levels, strict
protection and high intelligence. It can .run EDC, CFS,CIS experiment modes very conveniently with SR lightsource. Its construction and design idea of . the system
can be applied to other data acquisition systems.

1, Introduction
Photoelectron Spectroscopy Experiment Station at
HEm'RL works from VlN to soft x-ray T"velength(lOev -lOOO~iJ with resolution
E/E 10- and flux 1010
i:hs/s•The present photoeleotron spectraneter isimported from VSW (V&CUID Scientific Instruments) Co.,
U.K. 'Jhe software pe.ckage also provided by VSW is mainly
designed for regular light source and regular'(:hotoelectron spectroscopy analysis techniques, but notsuitable for the special requirement of experiment modes
with SR source. Up to now, having modified and developed
the control system and software, the completely
compatible system can not only carry out regularanalysis techniques such as Auger Electron Spectroscopy(AES), UV-Photoeleotron· Spectroscopy (UPS), X-ray
Photoelectron Spectroscopy (XPS), but also bring about
Synchrotron Radiation Photoemission Spectroscopy(SRPES), Angle Resolved Photoemission Spectroscopy(ARPES), Near F.dge X-ray Absorption Fine Structure(NEXAFS) and Photoelectron Diffraction (PED)
withcontrollable SR source. We hope it will praoote further
research oo surface science and material science.

The2)
1ntegrity of the original software manager
level structure is to be preserved, All the extended
peri~ drivers are iriserted into Software/Hardwareinterface layer. The Function layer is expanded andother layers are developed,
3) We assure a oomplete ccmipatibility with original
software both in general and details. In general, it
includes the folloWing fielda: llll!.lll""ll interface,experiment queue, file system, image display andprotection measure, specific processing such as exciting
source selection, experiment technique selection,
parameters input and collection, the experimentcondition recorded in data file, status diilplay and soon are caopletely ccmipatible,

3. General description.General mnager level struct.ure'Jhe system structure can be divided into the following
layers: User interface layer, Analyzer, Scheduler,
F\mctioo layer, Software/Hardware interface layer andHardware layer, as shown in Fig. 1.

2. Design principle

User Interlace
AnalyserSoheduler
Function

S./H. Interface
Hardware• Special requirement
The basic principle of photoeleotron spectroscopy is

Fig.1 General manager level structure
to irradiate 88111Ples with monochromatic light source,
User Interface layer
causing '(:hotoemission fromatoms or molecules. then'Ibis level accepts and analyses preliminary user's
analyze the electron energy and angular distribution and input, it cnecks whether input is legal, displays
get the useful information, So a control system for perii;heral equipnent status and corresponding processing
photoelectron spectroscopy experiment is focused on two messages.
points: to change exciting source and aoquiring methods
Analyzerof electrcin energy.
It makes a concrete analysis of user's input, then
E!cci ting source
generates some legal results according to user's
The system must control beam line availability, such . requirement and hardware environment. At last, theas wavelength acanning for different users in different results are sent to the Scheduler,
experiment techniques, zero order scan, photon intensity
Scheduler
detecting and other analog signal measurement.
'
It issues different function calls in the light of theFour different Sf.herical gratings and entrance/exit results sent by Analyzer. If it must be supported byslits are installed in the besmline. It is demanded that peripheral devices, it will transfer commands or
the rotation of the grating and translation of stepping parameters to peripheral devices and get status backmotor driven entrance and exit slits follow the Rowland through Software/Ha.rd"'8.re interface. The calling skill
circle.
is obtained by use of a special dictionary made ofOperating modes
function pointers which Ju.st belongs to c language.
'lbree operating modes with SR source must be inserted
Function layer
to the system: me mode, CFS mode and CIS mode.
It eirecutes various concrete functions such as realtime image display, reading and writing data files,
queuing different experiments, running experiment and.Design principle & impl-.itation sd.-t1) It is necessary not only to meet the spec~al acquiring data, 'Ibis layer and scheduler are the core of•
requirement above, but also to ass1.1111e the most succinct the system,
Software/Ha.rd"'8.re interface layer
118ll-machine interface, Beam.line control is an example.
It is the lowest level of the software system, At this
Although there are so lll!U'l1 parameters of intelligent
motor controller, and the gratings and slits tracing level, CClllllll.tldS lirrl data are transferred bl,ltween system
movement is complex, there are just three necessary and peripheral devices. This layer includes allparameters in the user's interface to execute besmline interface drivers and check of perii;¥ieral device status.
scanning: grating mmiber, initial and final energy of If a certain device g0es wrong
or is not ready,photon. The new added GPIB interface supports all a warning message will occur at the user interface,besmline control.

S05SRN11
Status Reports: Non-Accelerators

239

239

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S05SRN11

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA01

Overview of the Next Generation of Fennilabl Collider Software

Brian HENDRICKS, Robert JOSHEL
Fermilab, P.O. Box 500, Batavia, Il... 60510, USA

Abstract
II. OVERVIEW
Fermilabl is entering an era of operating a more complex
collider facility. In addition, new operator workstations areavailable that have increased capabilities. The task ofproviding updated software in this new environment
precipitated a project called Colliding Beam Software (CBS).
It was soon evident that a new approach was needed fordeveloping console software. Hence CBS, although acommon acronym, is too narrow a description. A newgeneration of the application program subroutine library has
been created to enhance the existing programming environment
with a set of value added tools. Several key Collider
applications were written that exploit CBS tools. This paper
will discuss the new tools and the underlying change inmethodology in application program development for
accelerator control at Fennilab.

AU the new tools are layered on top of the older lower-levelroutines. These subroutines reside in a shareable image. This
allows easy growth of a large number of routines without
affecting the application programmer. This was necessary sothat application development could be done in parallel with thematuration of the CBS environment. The tools handle fileaccess, data acquisition, graphics screen management, window
management, inter-program communication and error logging
facilities. These utilities also provide their own logging andstatistics that are viewable by the user during program
execution. Tools that access centralized facilities, such as
reading a database, cache infonnation to reduce the load on thecentralized processes and the network. Any of the tools with avisual interface follow standards. This provides a consistentuser presentation to the operators. This is a more effective
way to enforce user-standards, rather than administrative
dependenL approaches that have failed in the past.

I. MOTIVATION
ill. DATA ACQUISIDON
Digital VAXscations running X-windows under VMS have
replaced the PDP-I ls formerly used to control the accelerators.
This more powerful platform coupled with the demands of
The first major component in the CBS utilities involves
more complicated Collider operation led us to move from an input and output to accelerator hardware as well as reading
approach of single application-per-need to using fewer database information concerning that hardware. This involves
applications that draw on a large toolbox of resources. reading, setting, controlling, and scaling values as well as
Application programs are now viewed as hooks into a pool of handling alarms and miscellaneous device attributes. The
integrated tools. At the same time we must maintain previously available interface routines required separate requests
compatibility, while encouraging migration to new tools, for for real-time raw data as well as stored data from the database
the existing application programs which number in Lhe in order to read or set data in engineering units. This required
hundreds. This is done by providing calling sequences which seven low level function calls to retrieve or set a single value
are not too divergenL from the existing ones. The new console in engineering units. In addition to the function calls,
platform also opened the door for the use of C as an additional code was required to perform such necessary tasks asapplication programming language. Calling sequences are retrying data retrieval until the data is actually received. All ofoften provided both in call-by-reference for the FORTRAN this functionality has been replaced by a single, simple
users and call-by-value for the C users.
function call. For lists of devices the procedure is only
slightly more complex in that there is a function to build thelist of devices and a second function to read or set the lisL
The database infonnation for scaling and necessary interface

co front end software is cached locally. This reduces redundant
1 Operated by Universities Research Association for the

Department of Energy

database access and network traffic. The data acquistion
routines perform the access and caching such that it is

S06SA01
System Architecture

243

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPS'91 KEK, TSUKUBA November 11 - 15

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA02

IDEAS ON A GENERIC CONTROL SYSTEMS BASED ON THE EXPERIENCE ON THE
4 LEP EXPERIMENTS CONTROL SYSTEM
R. BARILLERE, J. M. LE GOFF, H. MILCENT, R. STAMPFLI
CERN, European Organization for Nuclear Research, 1211 Geneva 23, Switzerland

Most of the large slow control systems in the LEP collider experiments are distributed heterogeneous andmulti-standard. But in spite of the appearances, they have a lot in common. From our direct experience on
the L-3 slow control system and from the informations we obtained on the 3 other LEP experiments control
systems we have come to the conclusion that it should be possible to build a Generic Control Package fromwhich any control system could be derived. This software package is entirely based on relational
databases and is intended to provide all the necessary tools to build a modular, coherent, easy to update
and to maintain control system. Among other things this package should include user friendly interfaces,
expert systems, and powerful graphic monitoring and control tools. This paper will present our generalideas about the realization of such a package.
1. Inlroduction

The need for large and dedicated Slow Control
Systems for the High Energy Physics Experiments
at CERN only became clear with the constructionof the LEP collider. The large number ofparameters involved in the controls as well as
their wide distribution over the sites forced
physicists to reconsider the entire organization ofsuch systems. In this paper, the 4 LEP experiments
control systems will be presented in some details
followed by a summary of their main
characteristics. Out of this study some generalideas which could be used for the elaboration ofgeneric tools for future Slow Control systems will
be presented.
2. The 4 LEP experiments Slow Controls

The 4 experiments are composed of many subdetectors and several thousand operationalparameters which have to be set and monitored inorder to insure that the experiments are in acorrect state for data-taking. These include
quantities such as high and low voltages,
temperatures, pressures and gas mixtures. The roleof these Slow Control Systems is to monitor theexperimental conditions locally and generate
alarms in the main control room when faults are.detected. Operators alerted by the alarm signals
correct for the fault either manually or remotely
via a computer. The systems are also used for theroutine setup of operating conditions for example
high voltages, general monitoring and logging ofoperating conditions.
Since the quantities to be monitored vary only ona time scale of seconds the slow control systems

need not to have very fast responses. However,they must be very reliable and able to handle alarge number of very different parameters.
2.1 The ALEPH Slow Control [1]The ALEPH system is implemented in a number ofdistinct parts which are listed below:
1) Independent control and monitoring programs foreach sub-detector run on VAX™ computers
configured in a VAX™ cluster. These main displaysof the currently monitored equipments allow
operators to control the detectors and log theinformation to storage media.

2) All the sub-detectors slow control programs
communicate with their equipment via a single
server program running on a dedicated microV AX™
3100 workstation in the cluster (fig. 1). The slow
control server is the only program which
communicates directly with the microprocessor
system outlined below, which monitors and control
the equipment. An interactive graphical status
display showing the layout and status of thesystem is also implemented on this station.
3) Low-level monitoring and control functions are
performed by programs running in a distributed
system of microprocessors attached to the subdetector hardware. They are capable ofunderstanding, executing and replying to simple
commands sent to them from the VAX server
program.
4) Networks are used for communication between
the slow control server and the microprocessors. The
processors are connected to a number of UTI-NET

S06SA02
246

System Architecture
246

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA03

The LEP Alarm System
M. W. Tyrrell
CERN - European Organisation for Nuclear Research
SL Division. Controls GroupCH-1211 GENEYA 23, Switzerland

Abstract
Unlike alann systems for previous accelerators, the LEP
alarm system caters not only for the operation of theaccelerator but also for technical services and provides the
direct channel for personnel safety. It was commissioned
during 1989 and has seen a continued development up to thepresent day. The system, comprising over 50 computers
including 5 different platforms and 4 different operating
systems, is described. The hierarchical structure of the software
is outlined from the interface to the equipment groups,
through the front end computers to the central server, andfinally to the operator consoles. Reasons are given forchoosing a conventional, as opposed to a 'knowledge based'
approach. Finally, references are made to a prototype real time
expert system for surveying the power converters of LEP,
which was conducted during 1990 as part of the alarmdevelopment program.

By definition, if there is nothing wrong with the process, it isassumed that the overall state is good, and therefore no alann
information is presented. On the other hand, whenever a pieceof equipment does not work, or an abnonnal state is detected, adescription of this situation should be passed to the system.
This description is tenned a Fault State (F'S) and covers both
warning and aiann situations. The alarm system concerns theacceptance, treatment and display of these FS's.

B. Organisation

The project began in earnest in 1987 and has been
continually staffed by I permanent and, on average, 3
temporary personnel. During the 5 years of system design,
implementation and development, 16 temporary personnel,
each working on average I year have contributed 18 man years
to the project. These people were all trained in computerscience, apart from I who was an experimental physicist The
permanent member managed and coordinated the project which
I. lNIRODUCTION
was divided into 4 areas: display and presentation of
The Large Electron Positron Collider (LEP) was infonnation to operators, a Central A1ann Server (CAS), an
constructed during the years 1983 to 1989 and is situated in a interface to the users responsible for the equipment, and a
27km tunnel of diameter 3.8 meues at a depth varying dalabase.
between 50 and 175 meb'es. It contains 4 experimental halls
As part of the organisation of the LEP project, it was
situated symmetrically around the ring of size approximately stated that each equipment group should be responsible for its
80 metres long and 23 metres in diameter. From the very own equipment surveillance. It was envisaged that the main
outset it was decided to survey the whole complex both for part of this task would be done in the equipment groups' local
personnel safety and equipment status by I alarm system due control environment called Equipment Control Assemblies
to the sheer size of LEP and cost of system installation. This (ECA's). Unfortunately, in reality little surveillance of
laSk was given to an 'Alarm Team'. A major milestone for the equipment was implemented at that level. This required thatproject was the use of a complete prototype for the LEP the interface between the alarm system and the equipment
Injection Tests' in July 1988. By 1989, in time for LEP groups, in many cases passed beyond the ECA right down to
Switch On' the system had become stable and operational, but . the level of the equipment. For this reason it was even morewith an incomplete coverage of the complex and only a important to define exactly where each line of responsibility
rudimentary display for infonnation presentation. A continued was drawn. Jn practice this was always done at the level of adevelopment concentrated on improving the Man Machine database definition, either at the FS description level or aInterface (MMI), and extending the scrutiny of the surveillance combination of a command/response definition to acquire ansystem while investigating alternative techniques to improve equipment state and ilS corresponding FS definition.
the overall system.

C. Influencing Factors
II. THE ALARM SYSTEM PROJECT

A. Definition
The a1ann system can be thought of as a window throughwhich operators can view the status of any part of the process.
Here the process concerns the whole accelerator, equipment
associated with personnel safety and the conlrol system itself.

The main influencing factors were the following:
I. At the very beginning of the project various groups at
CERN were evaluating the possible uses of Expert Systems(ES). At one time an 'Expert System Inter~t Group' was set
up which encouraged a free exchange of ideas and helped keep
abreast of developmenlS. Although nothing of practical value
resulted for LEP, one area, a project in the Controls Group of

S06SA03254

System Architecture

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA04

The Software for the CERN LEP Beam. Orbit Measurement System
Giulio Morpurgo

CERN/SL, 1211 GENEVE 23, Switzerland

The Beam Orbit Measw:ement (BOM) system of LEP consists of 504 pickups, distributed all around the accelerator, thatare capable of measuring the positiollll of the two beams. Their
activity has to be synchronised, and the data produced by them
have to be collected together, for example to form a "closed orbit measurement" or a "trajectory measurement". On the userside, several clients can access simultaneously the results fromthis instrument. An automatic acquisition mode, and an "onrequest" one, can run in parallel. This results in a very fiexible
and powerful system.
The functionality of the BQM system is fully described, as wellas the structw:e of the software processes which constitute thesystem, and their interconnections. Problems solved during theimplementation are emphasized.

Introduction

The Beam Orbit Measurement (BOM) [l, 2] system is one of
the most vital instruments of LEP, and it is potentially very
powerful. 504 pickups, connected to 40 VME crates, are distributed all around the LEP ring • Each pickup can acquire asignal induced by the passage of each single bunch of particles
and record it in a VME compatible memory card. Each crate
is equipped with two such cards, ("Main" and "Secondary"),which can store signals coming from up to l 800 ( 450 for thesecondary) tw:ns. The signals are processed locally by microprocessors in the VME crates (called DSC, from Device StubController), and then finally collected in a single computer toproduce the final result (typically, the LEP orbit).
Due to various reasons (limited CPU power in the VME crates,
incompleteness of the software, unfriendliness of the RMS68K
programming environment on the VME crates and the reorganisation of the CERN accelerator divisions), the potential of thesystem had never been fully exploited. For this reason, in July
1990 it was decided to upgrade the computer part of the BOM
system, both from the hardware and from the software side.
Major points of the upgrading were :l. Replacing the DSC 68010 CPUs with 68030 CPUs
equipped with fioating point coprocessor.
2. Replacing the RMS68K microprocessor operating systemof the DSCs with OS9. The new DSC systems would be
diskless and would load system and application programsfrom a common file server. This would make the overallsystem cheaper, more reliable and easier to maintain.
3. Using a dedicated Apollo workstation (the BOM Server)
to collect the data coming from the DSCs and to deliver
the results to the users of the BOM system.
4. Implementing direct network connections, based on the
TCP /fP protocol, between the DSCs and the Apollo workstation where the data have to be put together.

5. Finally, a complete redesign and rewriting of the software
to be nm both on the DSCs and on the Bom Server • This
will be the main subject of this article.

Constraints (and :flexibility)
How the system works.
When upgrading an existing system, some degrees of freedom
are frozen. A preliminary step to perfonn is to e:xami:ne thethings that cannot be changed; the new system will have tolive with them.
In the LEP BOM system, the data acquisition in the 40 DSCs is
triggered and synchronized by the Beam Synchronous Timing(BST) system [3, 4 1 5]. This system interprets "tasks" written
in a pseudo-assembler language. At each LEP turn the BST
distributes an identical message to all 40 DSCs. This message
contains a part which can be read by programs running in. theDSC, and a part directly received by the hardware installedin the VME crate. As mentioned in the Introduction, in eachcrate there are two "Acquisition" memory cards. By software it
is possible to independently set the access to these memories in
one of two modes ,"intern" or "extern". In the "intern" modethe memory is made accessible to the processes running on the
DSC CPU, whereas in "extern" mode the memory can receive
data from the BOM data acquisition electronics (FADCs). The
FADCs produce data every time a bunch of particles crosses
the pickup. If the access to a memory is set as "extern", anda certain bit of the BST message received at a given LEP tw:nis set to l, then the data produced by the FADCs dw:ing thatturn will be written into the memory, together with the arrival
times of the various bunches.
The pickups close to the intersection points are equippedwith Wide Band electronics, while the rest of the pickups areequipped with Narrow Band electronics. The Narrow Band
pickups can measure, during the same turn, the signal generated by each bunch of each beam circulating in LEP. The Wide
Band pickups only measure the signal generated by bunches ofa preselected beam.
The fact that the system has two acquisition memories provides
a certain flexibility. It is able to perform two different operations at the same time, one in the Main memory, the other in
the Secondary memory. The two memories can be considered
as belonging to two different instruments.
There are, however, a few constraints which have to be dealt
with:l. While the Narrow Band systems can acquire both beams
at the same time, the Wide Band systems cannot. Theirsettings have to be changed if one needs to change the type

S06SA04
260

System ArchitectureICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA05

A VMEbus General-Purpose Data Acquisition System
A. Nina.ne, M. Nemry, J.L. Ma.rtou and F. Somers
Institut de Physique Nucleaire, Uni11ersite Catholique de Lou11ain
Ch. du Cyclotron, 2 - B-1348 Lou11ain-la-Neu11e1 Belgium
November 8, 1991
Abatract - We present a general-purpose, VMEbus
based, multiproceBSor data acquisition and monitoring
system. Events, handled by a master CPU, are kept at
the disposal of data storage and monitoring processes
which can run on distinct processors. They access either the complete set of data or a fraction of them,minimising the acquisition dead-time. The system isbuilt with the VxWorks 11.0 real time kernel to which
we have added device drivers for data acquisition andmonitoring.
The acquisltion is controlled and the data are displayed on a workstation. The user interface is written in c++ and re-uses the c:laases of the Interviews
and the NIH libraries. The communication between
the control workstation and the VMEbus processors ismade through SUN RPCs on an Ethernet link.
The system will be used for, CAMAC based, dataacquisition for nuclear physics experiments as well as
for the VXI data taking with the 4?1' configuration(100 neutron detectors) of the BruBBels-Caen-LouvainStrasbourg DEMON collaboration.

II.
A.

SYSTEM ARCHITECTURE

Distributed Hardware

The system is designed following a distributed architecture (Figure 1). The real-time data acquisition is performed by a VMEbus system. It allows to connect a wide
variety of interfaces to external hardware as well as torun data acquisition processes by various processor boards.
The user acquisition control and data handling is delegatedto a standard workstation connected to the VHEbus system
by an Ethernet link.

From Detectors & Exp. Area

Digital Em;;oders
A A 'l'

D D D

I.

c c c

INTRODUCTION

Experiments differ in the way they produce data: theyuse different standards of hardware to digitize data (VHE,
VXI, CAMAC 1 ••• ); they generate data varying in byte lengthand counting rate. However, the last stages of data acquisition systems have many things in common: the data are
analyzed on-line to control the experiment and are written
on storage devices for further off-line analysis.
We have defined a common framework for a generalpurpose data acquisition system. It meets the following
requirements:- the data source is open: the system can be enabled toacquire data from various instrumentation buses;- the data sink is open: data can be analyzed on-line byconcurrent processes and can be stored on different
types of mass storage devices;• the system is scalable: it can be used for low count rate
nuclear physics experiments (20 byte events at 200 Hz)
as well as in larger experiments such as the 100 neutron detectors of the DEMOll' collaboration [1] (300 byte
events at 5 kHZ);- the user sits at the highest level of the data acquisition
system with the modern conveniences of workstations.

c

CAMACBUS

A

M

A

r r

K K Ill

z z

vvv

E

T
H

c c

KM M
& & &

E
R

••

1 1 1
4 4 4
7 7 7

N
E

2 2
3

3

0 0

c

c
B

D

B
R

I

A

2
1
0

c

N

H

VMEbusT:~~:1~~~@~~~~)tl~~~~m~~~)t~~~~··I

UNIX System 11-,..

:~~;~~~~~~ii~~~w~~~:1~*:~Jt~~~~~l1:~~~t

Figure 1: A Simple Distributed Architecture
In such an architecture, both parts are loosely coupled
and may be evolved on their own. The UBer workstation or
the VHEbua system may be replaced or upgraded without
redesigning the entire system.

S06SA05
System Architecture

265

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC01

Interfacing Industrial Process Control systems to LEP/LHC
Michel Rabany
CERN
CH-1211Geneva23
Abstract

solutions. One may profit today of this opportunity, in our
new era of restricted human and financial resources.

Modem industrial process control systems have developed tomeet the needs of industry to increase the production while
decreasing the costs. Although particle accelerators designers
have pioneered in control systems during the seventies, it has
now become possible to them to profit of industrial solutions
in substitution of, or in complement with the more traditional
home made ones. Adapting and integrating such industrial
systems to the accelerator control area will certainly benefit to
the field in tenns of finance, human resources and technicalfacilities offered off-the-shelf by the widely experienced
industrial controls community; however this cannot be done
without slightly affecting the overall accelerator control
architecture. The paper briefly describes the industrial controls
arena and takes example on an industrial process control
system recently installed at CERN to discuss in detail the
related choices and issues.

II. THE COMPONENTS OF AN ACCELERATOR
A. Inventory of components
Components may be classified into two categories
depending whether or not they actively participate in the
production of particles: the first category will be referenced as
active in this paper and the second as passive (see figure 1).
Magnets, RF cavities, electrostatic separators, power
converters, beam instrumentation are active components. All
play an active role in keeping an accelerator state as well as inperforming the transitions from one state to another.
Electricity, vacuum, cooling & ventilation, cryogenics,
personnel protection, site access are passive components.

I. INTRODUCTION
Computers have gained a major importance in the overalldesign, construction, operation, maintenance and exploitationof today's accelerators and it is not exaggerated to say that,without them, physics research would not have become what
it is, and conversely that the development of computers was
highly due to the needs of basic research.
Pioneering in a statistic based research domain like particle
physics leads the engineers and physicists to work at the limitof what is possible in fields like electronics, mechanics,
computing, materials,etc .. They have to look pennanently forand to try to make profit of new promising technologies, assoon as these emerge from laboratories. They then get used tolive ahead of industry in a lot of scientific fields. They finallyaccept as a fact of life to develop everything they need, because
they do it better, tailored to their needs, with higher
performance than what they can readily find.
This is the case at CERN where people have felt in theearly days the potential embedded in the computers to help
them solving controls problems. Many of the basic
components which make up a particle factory are now wellknown and currently manufactured by industry. The particle
accelerators are quite comparable to other industrial machines.
The running of a particle factory leans mostly on domains forwhich industry has developed several control systems

II aa:elerator a>ntrol
Ill :;:~nt 1pedllc

Im 1cttve components
0 pa.aslve components

Figure 1. Accelerator components

S07IC01
Industrial Control

269

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC02

SPS/LEP Beam Transfer Equipment Control
Using Industrial Automation Components
A. Aimar, G. Berard, J. -L. Bretin, E. Cartier,J. H. Dieperink, M. Laffin, V. Mertens, H. Verhagen
European Organization for Nuclear Research (CERN) - SL Division,
CH - 1211 Geneva 23, Switzerland
II. SELECTION CRITERIA

Abstract
Several control systems for SPS and LEP beam transfer
equipment have to be commissioned in the near future. Tools
for fast software development, easy maintenance andmodifications, compliance with industrial standards, andindependence of specific suppliers are considered to be
essential. A large fraction of the systems can be realizedusing off-the-shelf industrial automation components likeindustrial 1/0 systems, programmable logic controllers, or
diskless PCs. Specific electronics built up in G-64 can be
integrated. Diskless systems running UNIX and X Windows
are foreseen as process controllers and local access media.
I. INTRODUCTION
Within the SPS and LEP Beam Transfer sector at CERN,
there are currently several control systems being prepared forthe application in both accelerators. Among those are, indifferent phases of progress, the control for the LEP beam
dump and for the LEP Pretzel beam separators.
Whereas the size and the complexity between our
different systems varies considerably - from some 10 1/0channels to nearly 1000 - all systems can commonly becharacterized as 'slow controls', i.e. the required response
times as seen from the main control room are only in theorder of seconds for most actions. Specific fast responses,
e.g. for beam dumping, are supported by special hardware.
The size of data exchanged between the main control roomand the equipment is relatively small. However, thesignificance of the equipment for the machine operation
requires a continuous monitoring of its perfonnance andefficient diagnostic tools for debugging in case of failure.
To facilitate the running of an increasing number ofsystems with different functionality and different
composition with the available manpower we are looking for
rationalization opportunities. Inspired by investigations in thefield of industrial process automation several areas have been
identified. In this .article we try to demonstrate how we plan
to apply our findings in the coming generation of control
systems.
In the following we shall first discuss the criteria which
we consider essential for the selection of the appropriatecomponents. Afterwards, the characteristics of the preferredfield bus will be given. Then, the full concept will bepresented complemented by a brief status report.

A. Hardware Interface
While the prices for equipment electronics in general are
decreasing, any cabling, either inside crates and racks or
between racks and equipment, is becoming a dominant cost
factor, besides being error prone. Therefore all data should be
picked up by remote 1/0 systems where they arise, wheneverpossible and if not totally inconvenient. All 1/0 systems
belonging to the same logical system should be hooked to a
field bus connected to a process controller.
A second factor is a clean and simple rack cabling scheme
including appropriate connection systems pennitting a fastand cost saving installation and modifications and an easy
maintenance of the electronics.
Other important criteria concern the economic use of rack
space and the cost, reliability, and the technological lifetimeof the selected l/O systems.

B. Local and Remote Access Facilities
Since the equipment to be controlled is, for technicalreasons, sometimes far away from the process control
computer or even the 1/0 system, one has to provide means
to influence or monitor the process locally (i.e. without theneed to communicate to somebody in front of the computer),e.g. for debugging or calibrating an equipment. This can bedone using local hardware, e.g. panels with DVMs, switches,and potentiometers, hand-held tenninals in the case of
programmable logic controllers, or portable PCs. It isessential to enable the person in charge of maintenance to get
access to all important parameters of the system in a userfriendly fonn and to pennit to develop or to modify test
procedures rapidly.
Adequate facilities have to be added on the processcontroller level and on other systems from where people haveto access the equipment, which should be as complete as
possible, preferentially without much adaption work for
different platfonns.

C. Software
The equipment software can be a particularly problematicarea in that here the user requests have to be translated into
specific instructions by comparatively few specialists. The

S07IC02274

Industrial Control

274

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC03

EPICS Architecture*
L.R. Dalesio (LANL). M.R. Kmimcr (ANL). A.J. Kozubal (LANL)
Mail Stop H820. Los Alamos National Laboratory Los Alamos. New Mexico. 87545
Argonne National L'l~oratory Argonne, Illinois , 60439

subsystems. Programs at various installations haveapplied EPICS successfully with no modifications tothe software. demonstrating adequate performance.
functionality and extensibility.

Abstract

The faperimental Physics and Industrial Control
System (EPICS) provides control and data acquisition
for the experimental physics community. Because thecapabilities required by the experimental physics
community for control were not available throughindustry. we began the design and implementation of
EPICS. It is a distributed process control system built
on a software communication bus. The functional
subsystems. which provide data acquisition.
supervisory control. closed loop control. archiving. andalarm management, greatly reduce the need forprogramming. Sequential control is provided througha sequential control language. allowing theimplementer to express state diagrams easily. Data
analysis of the archived data is provided through aninteractive tool. The timing system provides
distributed synchronization for control and timestamped data for data correlation across nodes in the
network. The system is scalable from a single test
station with a low channel count to a large distributed
network with thousands of channels. The functions
provided to the physics applications have provenhelpful to the experiments while greatly reducing thetime to deliver controls.

Alarm
ManagerArchiver
Sequencer-:gr

Display
Mana ercApplicatiot
Programs~
ChannelAccessDistnbuted
Run Time
Database

Input-Output,____~

Figure 1.

Functional subsystem layout of EPICS.

II. THE DISTRIBUTED DATABASE
A distributed database is used to provide local
EPICS is currently being co-developed by the control. A portion of the distributed database is
Accelerator Technology controls group at Los Alamos loaded in each J/O Controller (IOC). The database
National Laboratory and the Advanced Photon Source provides data acquisition, data conversion, alarm
controls group at Argonne National Laboratory. Its detection. interlocks. and closed loop contro1[1J[2J.
architecture· provides a wide range of functionality.
The IOCs. in which the database segments are
rapid application development and modification, and loaded and executed. consist of a VME or VXI
extensibility at all levels to meet the demands of backplane. a 68020 CPU running the vxWorks
experimental physics. The hardware and software for real-time kernel, an ethernet connection, and aneach functional subsystem was seleceted to meet these optional complement of 110 [Figure 2J. The J/O buses
requirements. The subsystems are: the Distributed supported are: VME. VXI. Allen-Bradley Industrial
Database. the Display Manager. the Alarm Manager. 1/0. GPIB. BITBUS. and CAMAC. The benchmarks
the Archiver. the Sequencer. and Channel Access for the database scan tasks show the ability to close
Ifigure 1J. Technology changes. to be incorporated. will 4,000 analog loops per second leaving about 40% of afurther extend the performance of the EPICS 68020 available for the sequencer and channel accessI.

INTRODUCTION• Work at LANLsupporleu anu funtletl unuer the I >cparlmenl of
Defense. US Army Stmlcgic Defense Commanu. under the
auspices of the Department of Energy.

Work at ANL supported by U.S. Dept. of Energy. Office of Basic
Energy Sciences. under Contract No W-31-109-ENG-38.

S07IC03278

Industrial Control

278

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC04

A Front-End System for Industrial Type Controls at the SSC
D.R. Haenni
Superconducting Super Collider Laboratory*

2550 Beckleymeade, Dallas, Texas 75237 USA
Abstract
The SSC control system is tasked with coordinating theoperation of many different accelerator subsystems, anumber of which use induslrial type process controls. The
design of a high-performance control system front end ispresented which serves both as a data concentrator and a
distributed process controller. Io addition it provides strong
support for a centralized control system architecture, allows
for regional control systems, and simplifies the constructionof inter-subsystem controls. An implementation of thisdesign will be discussed which uses SID·Bus for accelerator
hardware interfacing, a time domain. multiplexing (IUM)
communications transport system, and a modified reflective
memory interface to the rest of the control system.
I. ~NTRODUCTJON
11Je design of a control system for the SSC faces
significant challenges arising from its inunense physical size,
plethora of control points, and wide range of time scales forcontrols. At the slow end of the time scale there areaccelerator subsystems like cryogenics, vacuum, low·
conductivity water, and induslrial cooling water which use
industrial process controls. For a proper perspective consider
the vacuum controls. A recent estimate indicates that there
will be S0,000 to 60,000 points divided among 200 niches
around the ring. This number, which does not include
vacuum conuols for the injector accelerators or beam lines,
is roughly comparable to the total FNAL control system.
The cryogenic system is 2·3 times larger than the vacuum
system. The controls for these SSC accelerator subsystems
totaling more than 250,000 points dwarf most large industrial
and high-energy physics control systeillS. The present paper
describes a possible front-end system for process controls at
the SSC. An earlier discussion of this system can be found in
Ref. [I).

U, DESIGN REQUIREMENTS
The controls for these subsystems at the SSC must
support process controls and smoothly integrate into the restof the SSC conttol system. A general list of requirements
appropriate for this discussion are as follows:'opcra!Cd by lhe Universities Research Association, Inc., for lhe
U.S. Department of Energy under Contract No.
DE·AC02·
S9ER40486.

I. Provide industrial process controls.
2. Minimiie hardware in hostile or radiation areas.
3. Use open, widely available industrial standards.
4. Prefer commercial products to custom hardware.
5. Set no limits on the number of control points.
6. Execute control functions at different system levels.
7. Support a centralized control system architecture inwhich the entire complex is operated from a single
location.
8. Provide regional level coo1rols to support commissioning
and maintenance of large accelerator components.
9. Eliminate accelerator hardware data hiding in the control
system architecture.
I 0. Facilitate near real time inter subsystem information
sharing and implementing geographically distributed orinter subsystem control loops.
11. Contain costs.
12. Maximize reliability.
13. Follow the overall SSC conttol system architecture.
While meeting many of the process coottol requirements
for individual subsystems, conunercial process conlrol
systems have problems supponing either the large number ofconlrol points or extended geographical area or desired levelof integration.

Figure I. Front-end system components in relationship to
the rest of the conlrol system.
111. FRONT-END SYSTEM DESIGNIn Fig. I the basic components of the front-end system areshow in relationship to the rest of the system. The front end
consists of the interface hardware, communications, andprocessors to execute low-level coottol functions. It supports
data J/O and functions such as loops, alarm monitoring, andinterlocks. The back end is commercial and SSC developed
software providing operator interface and high-level control
applications such as complex sequencing, expert systems foralann analysis, data logging, and process simulation.
Effectively the high-speed reflex-like control activities are

S07IC04
Industrial Control

283

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The Influence of Industrial Applications on a Control System Toolbox
Peter Clout
Vista Control Systems, Inc.
134B Eastgate Drive, Los Alamos, NM 87544, USA

Abstract
Vsystem is as an open, advanced software application toolbox
for rapidly creating fast, efficient and cost-effective control anddata-acquisition systems. Vsystem 's modular architecture is designed for single computers, networked computers and worksta·
tioos running under VAX/VMS or VAX/ELN. At the heart of
Vsystem lies Vaccess, a user extendible real-time database andlibrary of access routines. 1be application database provides thelink to the hardware of the application and can be organized as
one database or separate databases installed in different comput·
ers on the netwodt. Vsystem has found application in chaigedparticle accelerator control, tokamak control, and industrial research, as well as its more recent industrial applications. This
paper describes the broad features of Vsystem and the influencethat recent industrial applications have had on the software.

1be Vaccess database bas many real-time features includingchange notification, alarm and warning checking, dynamic linking of hardware access and data conveISioo subroutines, and automatic 1/0. There are many fields in each channel, or record, ofthe database that allow the modelling to be complete. Each chao~
oel is known by a name up to 40 characters long which is definedby the project. Database channels support most data types as either single valued or array channels. Table 1 lists the channel
fields of Vaccess V2.2.
ChannelFieldsChannel Name
Current Value
Current Value Significant Change
Equipment Limits
Clipping Enable
Channel Data Type
Read Only Enable, Constant Channel
Channel Tuxt LabelInterest Count

Conversion
FieldsConveISioo Subroutine Name
ConveISion Enable
Conversion Parameters (10)Built-in Linear Conversion Parameters (2)Alarm

Alarm and Warning Checking Enable
Alarm and Warning Limits
Alarm Label
Alann Type (Integer Channel)

I. INTRODUCTION
Developing control systems for physics research from basic
components requires considerable effort and the acceptance ofrisk. Now, software products that can form the basis of an experimental physics conttol system are entering the product made.et.
This paper describes one such product. Software products exist
that were developed originally for factory automation but experience bas shown that these products do not network well and are
difficult to apply in a research envirorunent, often costing morein total than a home-written system I Vista Control Systems hasgone the other way-finding industrial markets for control system software originally developed for physics research. These
new industrial applications have added to the flexibility of the
Vsystem software in a way that benefits all users without threatening the flexibility and openness of Vsystem.

FieldsHardwareFieldsAutomatic 1/0 Enable
l/OType
Hardware Type
Hardware 1/0 Subroutine Name
Hardware 1/0 Function
Hardware Parameters (10)Survey Rates
Automatic Survey Enable
Input or Output

Display
Fields

Display Limits
Text Display FoIDlat
Data Units

Vsystem consists of several modules: Vaccess, Vdraw, Vscript,
Valann, Vlogger, and a number of utilities.

II. vSYSTEM'S REAL-TIME,
NE1WORKBD DATABASE

1be architecture of Vsystem requires that all components of theapplication, be they supplied with Vsystem or user-written,
communicate only through the Vaccess database. A system's
Vaccessdatabase is defined by Asen files and installed as global
sections. The overall application database is usually made up
from individual components distributed among the computers of
the system. Collectively, the databases are a data model of theapplication, modelling both the actual connections and derived
data.

Table 1. Vsystem Database Fields

A. Database Access Routines
A library ofaccess routines allows full access to the run-time database. Routines are included to search the database in various
ways and to request and cancel change notification by wake-up

S07IC05
Industrial Control

287
287

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S07IC05

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC01

ARCNET as a Field Bus in the Fennilab Linac Control System

M.F. Shea, R.W. Goodwin, M.J. Kucera and S. Shtirbu
Fennilabt, P.O. Box 500
Batavia, Illinois 60510

without being polled. A single message may contain all theanalog and digital data collected by a node.

Abstract
Data acquisition hardware in accelerator control systems isconnected by a field bus to networked computers that supply
data to consoles. Industry attempts to standardize on a low
level field bus have not succeeded in providing a single wellsupported bus. This paper describes a data acquisition chassisthat connects to VMEbus computers using ARCNBT, a fullfeatured token-passing local area network, as the field bus. The
performance of this technique as implemented in the control
system for the Fennilab Linac is given.

I. INTRODUCTION
A field bus is the connection between local computers andthe interface hardware that controls accelerator equipment.
Various field buses have been used by control systemdesigners, but no single bus has emerged as a widely used
standard. Example field buses are MIL-1553, Bitbus, and
CAMAC.

This paper describes the use of ARCNBT as a field bus in
the Fennilab Linac Upgrade project. The output energy of the
Linac injector is being increased from 200 MeV to 400 MeV
by replacing the last four of the nine 200 MHz Alvarez tankswith 800 MHz side-coupled structures. This upgrade doubles
the beam energy in the same accelerator enclosure. The
control system being designed as part of the upgrade, will be
installed for the preaccelerators and the remaining five 200
MHz tanks as well as the new 800 MHz sections.

II. ARCNET AS A FIELD Bus
If the interface hardware that connects to accelerator
equipment is dumb, then the field bus must be register-based.
Such buses have limited addressing capacity and the amount ofdata transferred per transmission is small. Nodes on registerbased field buses usually operate as slaves that must be polled
by a master computer to collect their data.
If the interface hardware contains a processor, then a local
area network can be supported. Benefits of using a local area
network include longer messages, higher data transmission
rates, longer distance connections, and peer protocol
communications that allow a remote node to source a message

t Work supported by the U.S. Department of Energy undercontract No. DE-AC02-76CH03000

Characteristics of ARCNEf include:
2.5 MHz serial bit rate
508 byte maximum message lengthBus, multiple star and daisy-chain topology
Coax, twisted pair and fiber optic transmission media
Maximum distance without repeaters >600 m. (coax)
Transformer isolated cable drivers
Deterministic token passing access protocol
Built-in acknowledgment of successful message
reception
Network configuration and timeouts implemented incontroller chips
Compared with the characteristics of ARCNEf, typical fieldbuses are much lower in performance: MIL-1553 operates at
one MHz, has a maximum message length of 32 words andcan address 32 locations per node; Bitbus is not transformer
coupled and is limited to 375 kHz for reasonable distances;normal CAMAC commands access only three bytes. All ofthese buses use master-slave communication protocols.

III. ARCHITECTURE OF THE LINAC SYSTEM
The overall design of the Linac control system follows thestandard architecture of local VMEbus 68020 computers
networked to each other and to console workstations by an
IBBE-802.5 Token Ring. A separate ring is used for the Linac
VMEbus stations and the connection to the central control
system is made by a commercial multipon Token Ring-toToken Ring bridge. This organization isolates the traffic on
the Linac ring from all other network traffic.

A. System Hardware
Individual VMEbus computers, called Local Stations,contain a core set of five cards; a 68020 processor, a lMByte
non-volatile RAM card, the Token Ring adapter, a crate utility
card and an ARCNEf adapter. All but the crate utility card arecommercially available. Each VMEbus station acts as a standalone control system complete with its own database andsoftware resident in the non-volatile RAM. Following a power
outage, these systems reset, reconnect to the network. and send
the last known settings to the hardware. Because they havenon-volatile RAM, Local Stations do not require routine
downloading. Local Stations run synchronously with the 15

S08NC01
Network and Communication

291

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC02

Multi-processor Network Implementations in Multibus II andVMECharlie BRIEGEL, Fennilabt
P.O. Box 500, Batavia, IL 60510, USA

II. ACNET OVERVIEWACNET (Accelerator Controls Network) is Fermilab's
proprietary network protocol implemented in 1980. It consistsof both a software protocol and a .calling sequence
ACNET (Fennilab Accelerator Controls Network), a proprietary specification.
network protocol, is implemented in a multi.processor
The software protocol consists of a 9 word header
configuration for both Multibus II and VME.
The
I)
preceding each message and provides a specification(figureimplementations are contrasted by the bus protocol and software
for the routing of messages between tasks. The protocol
design goals.
The Multibus II implementation provides for multiple maintains a connection between cooperating tasks through aprocessors nmning a duplicate set of tasks on each processor. For status reply and/or cancel messages. These notifications
a network connected task, messages are distributed by a network enable tasks and the network to maintain connectivity andround-robin scheduler. Further, messages can be stopped,
cleanup network resourees with minimal overhead.
continued. or re-routed for each task by user-callable commands.
The calling sequence provides a consistent user
The VME implementation provides for multiple processors
nmning one task across all processors. The process can either be interface across heterogeneous machines and enables afixed to a particular processor or dynamically allocated to an request/reply paradigm for communication.
Bothavailable processor depending on the scheduling algorithm of the asynchronous communications (traps, signals, or event flags)
multi-processing operating system.
and synchronous communications (polling, wait, or wait with
time-out) are supported by the calling sequence.
This calling sequence has enabled Fennilab to isolate
effectstousers due to changes in either the software or
I. INTRODUCTION
hardware protocol. While the implementation imposes
inherent software costs, there is an advantage in providing a
The motivation for a multi-processor platform inconsistent layered approach for other software protocols.
Fermilab's Accelerator Controls Group was to support our
The proprietary protocol does not restrict the use ofextensive commitment to CAMAC. The goal was to provide
For instance, by tunneling or
standard protocols.
a replacement for PDPl 1 front-ends improve the effective
encapsulating software protocols, ACNET has beenutilization of the CAMAC serial link. Since CAMAC can
implemented through a DECNET protocol and will be
have only one master, the link hardware allows ownership toimplemented with TCP/IP in the near future. The primary
be passed between cooperating processors. One of thereason for not implementing a standard protocol stack has beenrequirements for this configuration was to implement ACNET
the lack of support by vendors for the current set ofcommunications for several duplicate processors runningheterogeneous processors and operating systems at Fennilab.
identical set of tasks. Thus, processors can be transparently
added to the configuration with a corresponding increase inperformance. This requirement provided the impetus for a
multi-processor network connection to the existing network.
The VME implementation provides support of multi-processor
networks by using MTOS-UX MP (multi-processor version)
operating system for transparent distribution of tasks among a
set of processors.

Abstractt Operated by Universities Research Association for the
Department of Energy.

S08NC02
Network and Communication

295

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC03

A DISTRIBUTED DESIGN FOR MONITORING, LOGGING, AND REPLAYING
DEVICE READINGS AT LAMPP *Mary Burns
Los Alamos National Lalx>ratory
Los Alamos, NM, USA, 87545

Abstract

II. FUNCTIONALITY OF TIIE SOFTWARE

2.1 The Sampling Software
As control of the Los Alamos Meson Physics linear
A large number of beam line devices can be sampledaccelerator and Proton Storage Ring moves to a more
distributed system, it has been necessary to redesign the periodically for the purpose of monitoring the device tosoftware which monitors, logs, and replays device readings detennine if its reading is within a given range, logging thethroughout the facility. The new design allows devices to be device reading to a history file, or both. The frequency atmonitored and their readings logged locally on a network of which each device is sampled can vary from once a second toco~puters. Control of the monitoring and logging process is once every eight hours. If a device which is being monitored isavadable throughout the network from user interfaces which found to have a reading outside its given range (ie. it is out ofcommunicate via remote procedure calls with server processes tolerance) the accelerator operators are notified via the operator
running on each node which monitors and records device console and an error log. An alarm action may also bereadings. Similarly, the logged data can be replayed from initiated. If the device reading is being logged to a history filefor replay the reading is recorded together with a device
anywhere on the network.
Two major requirements influencing the final design were identifier, a compressed timestamp, and the status of the read.
the need to reduce the load on the CPU of the control
machines, and the need for much faster replay of the logged 2.2 The Replay Software
device readings.
The device readings can be replayed for a selected time
period and displayed as graphs. Readings from several devices
can also be combined in an arithmetric expression and plotted.
I. INTRODUCTION

III. THE SOFTWARE DESIGNThe Los Alamos Meson Physics Facility (LAMPF) linear
accelerator, the injection lines, the experimental areas, and the
The sampling software is divided into two parts; theProton Storage Ring (PSR) contain over 16,000 beam line
programwhich collects the data and monitors and logs it, anddevices (approximately 11,000 in the LAMPF Control Systemtheoperator
interface software which allows the operators to(LCS) and 5,000 in the PSR control system) which can beaccessed through the LCS Data System [I]. These devices interact with the sampling program. Interactions include
include both monitoring and control devices which occur stopping and starting the sampling of individual devices or
throughout the facility. Many of the devices are accessed lists of related devices, changing the parameters associated withthrough remote microVA.Xes which are connected by Ethernet a device, such as the frequency of sampling, and requesting an
to fonn a DECnet LAN with the main control computer, a immediate monitoring of a set of devices.
VAX 8650. This system is becoming more distributed as
3.1 Problems with the Original Design
remote computers are added to allow access to related groups ofdevices, and some of the CPU load is being off-loaded from theOriginally the sampling software was designed to run on
main computer to remote machines.
The increasedthemain control computer and to monitor and log data from
distribution of the system has made it necessary to redesign
some of the software to take advantage of the changes. One throughout the facility in a large, central, history file. Replay
such system is the software that monitors, logs and replays of device readings was carried out on the same computer.
As more nodes were added to the network the demand forreadings from devices located throughout the facility. Before
distributed
replay grew. Also the number and frequency of
the redesign of the software was started, a complete redevice
sampling
increased, so that the load on the control
evaluation of the requirements of the software was carried out
computerbecamemore noticeable causing a degradation in theso that other improvements could be included in the new
speedofexecutionof other applications, and affecting thedesign.
ability of the facility operators to respond quickly to requests
from experimenters or to emergencies. Due to the increasing*Work supported by the U.S. Department of Energy
size of the history file, replay of the device readings was also

S08NC03
Network and Communication

299

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC04

Synchronous Message-Based Communication For Distributed
Heterogeneous Systems
N. Wilkinson
TRIUMF

D. DohanSSC

4004 Wesbrook Mall
Vancouver, B.C

2550 Beckleymeade Avenue
Dallas, Texas

Canada V6T 2A3

USA 75237

Abstract
The use of a synchronous, message-based real-time operating system (Unison) as the basis of transparent interprocess and inter-processor communication over VMEbus is described. The implementation of a synchronous,
message-based protocol for network communication between heterogeneous systems is discussed. In particular,
the design and implementation of a message-based session layer over a virtual circuit transport layer protocol
using UDP /IP is described. Inter-process communicationis achieved via a message-based semantic which is portableby virtue of its ease of implementation in other operating
system environments. Protocol performance for network
communication among heterogeneous architectures is presented, including VMS, Unix, Mach and Unison.

1

Introduction

The use of domain-driven object modeling techniques inthe specification of the KAON Factory Control System[l]was in contrast to the more. traditional emphasis on im. plementation and technology details and the consequentimposition of the technology on the requirements. Whenthese object-oriented methods were used to model the
KAON Factory Control System and to allocate the requirements specification to processor units[2], a logical architecture was derived which consisted of a network of distributed processors connected by two specialized communications buses: the control bus, a fast communication link
responsible for the deterministic transport of control information and the data bus, a wide bandwidth link responsible for non-deterministic, data-intensive communication.
Since no generic processor platform can economically perform all of the functions required, the distributed
network of computing platforms utilized by the KAON
Factory Central Control System (KF CCS) will be nonhomogeneous and will undoubtedly consist of both realtime and non real-time platforms. It is therefore important that a consistent software architecture be employed
to implement communication among these platforms.

2

Message Based Architecture

The message-based semantic is a candidate for implementing the transparent, high performance inter-process andinter-processor communication required for the KF CCS.
Message passing can elegantly encapsulate both task synchronization and data transfer into a small set of simple
primitives having well-defined semantics[3). Since a message header can identify a particular method to be usedby a task instance, the use of the message-based semantic
provides a convenient means of implementing an objectoriented architecture in a distributed environment.
In the synchronous message-based semantic, threeprimitives are employed for inter-process communicationand synchronization: send(}, receive(} and reply().
The send primitive implements the dispatch of amessage to a destination task followed by the receipt ofa reply from that task. Once it has called the send primitive, a task remains blocked until the receipt of a reply
from the destination task.
The receive primitive is used to receive messages
from other tasks and, typically, to wait for signals from interrupt service routines. Tasks which use the receive primitive remain blocked until a message or signal arrives, or until a user-determined timeout occurs. The use of the receive
primitive for the receipt of both messages and signals at asingle point of execution considerably simplifies the structure and design of tasks which must simultaneously deal
with external events and communicate with other tasks.
The reply primitive is non-blocking. It is used bytasks, such as servers, which cannot block while dispatching a message. A reply is always made to a task which has
used the send primitive to send a message to a given task
and is waiting for that task to reply.
Task synchronization is implicit in the communications primitives employed. For instance, a sert1er object
should never block when posting a message to anothertask. For this reason, servers employ the receive primitive
to receive messages from clients and the reply primitive
to respond to clients. Courier objects are used to carrymessages between servers, as a server would block if it employed the send primitive to communicate directly withanother server.
A synchronous message-based semantic may be constructed from the more primitive inter-process communications semantics offered by operating systems such as VMS
or VxWorks, or it may be obtained as the native semantic

S08NC04
302

Network and Communication

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC05

The Transmission of Accelerator Timing Information around CERN
C.G. Beetham, K. Kohler, C.R.C.B. Parker and J.-B. Ribes
European Organization for Nuclear Research (CERN)CH - 1211Geneva23, Swit7.erland

Abstract
Prior to the construction of the Large Electron Positron(LEP) collider, machine timing information was transmitted
around CERN's accelerators using a labyrinth of dedicatedcopper wires. However, at an early stage in the design of the
LEP control system, it was decided to use an integrated communication system based on Time Division Multiplex (TDM)
techniques. Therefore it was considered appropriate to use
this facility to transmit timing information over long distances. This note describes the overall system, with emphasis
placed on the connectivity requirements for the CCITT
G.703 series of recommendations. In addition the methods
used for error detection and correction, and also for redundancy, are described. The cost implications of using such a
TDM based system are also analyzed. Finally the performance and reliability obtained by using this approach are dis-cussed.

I. INTRODUCTION
In the planning phase of the LEP collider it was recognized that the much greater physical sire of LEP comparedwith previous accelerators would result in a radical change inthe way communications systems of all types would be implemented. The larger sire implied correspondingly longer
cables and more signal regenerators, and consequently much
more expense. Moreover, most cables had to be routed
through the LEP tunnel itself, significantly limiting the space
available for future exploitation of the tunnel. It was evident
that the number of cables would have to be reduced by multiplexing information for several different users onto one
cable. Consequently, it was decided to install a multiplexed
system throughout LEP as a general user facility.

II. ACCELERATOR TIMING SYSTEMS
A. General Features
Typically, computer control systems have a real-time
response in the order of 10 to > 1000 ms. Whilst this is adequate for many applications there is always a need to trigger
selective hardware equipment with a finer time resolution.
This is achieved by means of a timing system.

An accelerator timing system is simply a fast broadcast
message transfer system. The messages (events) are normallyshort (typically less than 32 bits) and should have a maxi-

mum time resolution of 1 ms. The jitter of each message isdetermined by the transmission medium and by the sampling
processes at the generator and receiver. Depending upon thetype of machine, the events are either pre-programmed, according to the specific machine cycle, or triggered by external stimuli, such as emergency beam dump.
A principle difference between a timing system and acontrol system is that when a transmission error is detected,
the control system normally retransmits the message. This is
inappropriate with a timing system as, inherently, the message contains a timing reference.
Although the timing and control systems may be considered as two separate identities they are in fact strongly
coupled to the machine that they are controlling. For thisreason timing systems have always been designed in-houseand tailored to the specific accelerator concerned. This implies producing timing equipment compatible with the chosen
control system. Equipment of this type is normally not available commercially.
For a large accelerator a typical timing system consists ofthree parts:•

a central timing generator•

a long distance transmission network•

a local distribution system.

The timing system chosen for LEP and subsequently

used on the SPS has been described elsewhere[l]. This article
concentrates on the long distance transmission network.

B. Long Distance Transmission
In the case of CERN's Super Proton Synchrotron (SPS)
machine, "long distance• refers to the distance between two
adjacent auxiliary surface buildings located above the SPS
tunnel. For the LEP machine it refers to the distance between two adjacent tunnel alcoves. For both scenarios the
distance is between one and two kilometers.
For the original SPS machine the accelerator timing information consisted of a 1 ms clock and short (7 bit) trigger
messages called events. The events were Manchester encoded
and transmitted to each building over a video cable containing two good quality twisted pairs. One pair was used totransmit the lms clock whilst the other carried the events.
The transmission rate was 333 kbit/s and no error detection
or correction was employed. "Tap-off" amplifiers were in-

S08NC05
306

Network and Communication

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC06

Time and Load Measuring in the SPS/LEP Control System
J. Navratil
Czech Technical University
Zikova 4, 166 35 Praha 6, Czechoslovakia
information. (The counters of the number of transmitted
Abstract
This paper describes the experiences with the SPS/LEP packets and bytes are a part of the standard communication
Control System during its first operational days from the software.) Data is collected by the RPC mechanism by thecommunication point of view. The results show difference standard Rply_data program which is running on almost all
between hardware possibility of the local communication based hosts as a standard server. All the information from theon the modem technology and the possibility to use it by PC selected ring can be collected in a few seconds.
The analysing program generate 3 tables. The first gives
machines. There is also several figures describing the activity
the total overview about the measured values, the second tableon the communication lines.
gives an extract of the most active hosts and tries to express
the values in a pseudo graphic form. The third table shows theI. INTRODUCTION
activity in the time picture (the same data was collected in
The control system of the SPS/LEP is based on distributed regular time intervals).
If we have a look on the tables in detail, then the firstmicrocomputer network which contains more then 300 hosts
and many thousands of different devices used for the control. table contains 5 originally measured values (time in sec.,
Backbone is created by the communication system which can number of input packets, number of output packets, number ofbe divided into two parts. The horizontal plane is based on the input bytes and number of output bytes) for each host. All
Token Ring system to which are connected hosts used for other values in the table are calculated from these values. As
control of particular processes on high level and many vertical the best representation of the activity of each host I have usedplanes provide connection onto the control devices (computers, the percentage of the total activity in the network. These
interfaces, VME creates, etc.). MIL-1553 B is used here as the figures were calculated for each measured value (input packets,
output packets, input bytes, output bytes). The last calculated
standard for the communications.
Such control system is very interesting first of all by its value for each host is the "average speed", it is the activity ofsimple design where the total computer power is obtained by the communication interface - sum of the input and output
the relatively small quantities of hosts (IBM PC clones) and bytes divided by measured time. On the bottom of the tablealso for the sophisticated combination of a different communi- are summary values and an "actual average speed" in the ring.
cations devices (TDM, gateways, bridges, etc.) which ensure
The second and third table are self-explanatory. An extract
flexible services in the large area and long distances (27 km) of the hosts in the second table is done on the basis of the[1](2].
minimum trash value. In our case the trash value was selected
My activity was concentrated on the Token Ring services as 1.5%. From the ghraphic interpretation it is immediate toand because my programs had to communicate through the get a picture of the hosts activity (the most used one). The
whole network it was interesting to know the environment in third table shows all hosts but for better reading of thewhich I had to work and its basic characteristics as the response information there are shown only relative values of these hosts
time, speed of data transport and the load of the system (from in which the activity is higher than the trash value. This table
the point of view of communication). Detail results are gives a good overview about the "long term behaviour" or the"stability of needed service". (See examples shown in tables.)reported at CERN SL/CO/Note 90-05.
II.

NETWORK ACTIVITY

During November and December 1989 when LEP started
normal operation and all parts of the control system were
working nonnally I collected some data about the activity of
all hosts in the Token Ring communication network of theControl system. The aim of the measurement was to get a
general overview of how much the Token Ring network wasused by users for real control work.
For this purposes a set of programs were developed which
are part of the Network Management System [2]. The results
and evaluation of the activity in the network was used mainly
to get an overall picture about the use of particular parts of the
network and for long tenn planning.
For described experiment I have used three programs. The
first of them collects data from the selected hosts and twoothers are used for processing and analysing the data andprinting reports. The interface counters are used as the basic

III. MEASUREMENTS OFRESPONSE TIME
There are several tools for the network communication but
I have used only two of them, FTP or (TFI'P) and RPC(Remote Procedure Call). Both tools ar also heavily used inmany others applications. My effort has been concentrated on
the RPC implemented via Network compiler [5] from thepoint of view of the normal user. This is because this facility
was the principal tool for many programs in the Network
Management System which we are developing in our section
and also because RPC is a very powerful tool in itself.
Some timing measurement were done in the past. For
FTP and transport of short messages by the UDP facility(which artificially simulates the possibilities of real RPC [4]),the work was mainly concentrated on analysing the communications properties of different operating systems. Anotherstudy [6] measured response time of an implemented RPC, but

S08NC06
310

Network and Communication

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC07

THE ELETTRA FIELD HIGHWAY SYSTEM
D. Bulfone, P. Michelini, M. Mignacco
Sincrotrone Trieste, Padriciano 99, 34012 Trieste, Italy

Abstract
ELETIRA is a third generation Synchrotron Light Source
under construction in Trieste (Italy); it consists of a fullenergy linac injector and a storage ring with beam energies
between 1.5 and 2 GeV. The ELETIRA control system has a
distributed architecture, hierarchically divided into three layersof computers; two network levels provide communication
between the adjacent computer layers. The field highway
adopted for the connection of the middle-layer local processcomputers with the bottom-layer equipment interface units is
the MIL-1553B multidrop highway. This paper describes the
hardware configuration and the main communication services
developed on the MIL-15538 field highway for accelerator
control. As an additional feature, typical LAN utilities havebeen added on top of the basic MIL-15538 communication
software allowing remote login and file transfer; these tools
are currently used for software development in our laboratory.

I. INTRODUCTION
The ELETTRA Control system is distributed over theabout 260 m Storage Ring circumference and 170 m
Linac-plus-Transfer Line, with an architecture based on threecomputer levels (presentation, processing and equipment
interface) and two network layers.
High performance UNIX workstations with excellent
graphical capabilities are used as operator consoles at thepresentation level. The upper layer network, which is based on
Ethernet and the TCP/IP communication protocol, connects
the control room workstations and the distributed process levelcomputers called Local Process Computers (LPC).
The LPCs, bridging the two network levels, are the "core"of the control system, where all the main application control
tasks are executed, acquiring and processing data from theequipment interface level; the ELETTRA LPC consists ofassemblies of VMEbus single-board computers (SBC),
running the OS-9 operating system. In order to enhance both
performances and modularity, a multiprocessor-multimasterarchitecture has been developed for the LPC, where each board
is allowed to take VMEbus mastership and execute its own
data transfers.
Separate lower level network branches connect each LPC
to the equipment interfaces, called Equipment Interface Units(EIU). Following a definition widely accepted by the control
system designers community (l], the term "field highway" isused to indicate the communication system between the local
process computers and the interface-level processors.
The VMEbus standard and the OS-9 operating system are
adopted also at the EIU level; the typical EIU configurationconsists of one microprocessor board associated with several
input/output boards of different type.
Exploiting the high performances of the field highway, we
have assigned the LPCs with operational criteria, which
enhance system design clarity at the same time: 2 LPCs and48 Ellis are foreseen for magnet power supplies control, 1
LPC and 7 EIUs for vacuum, 1 LPC and 12 EIUs for storage
ring beam position monitors, 2 LPCs and 3 EIUs for linac
control, etc. A total number of 14 LPCs and 88 Ellis is to be
finally installed.

II. 1liEMIL-1553B MULTIDROPHIGHWAY
In the project of an accelerator control system, the choiceof the field highway is strategic: in spite of the growing ofstandards in the informatics and electronics world, manydifferent solutions are currently used and proposed. The main
parameters considered in the choice of the ELETTRA field
highway are: communication topology, electrical noise
immunity and data integrity, deterministic response, cost andperformance. After a careful investigation of the
non-proprietary commercially available products, we decided toadopt the MIL-1553B standard [2), slightly modified foraccelerator control.

A. Communication topology
The MIL- l 553B standard, originally developed for theaircrafts by the U.S. Department of Defense, defines a serial
Time Division Multiplexing (TDM) highway on which one
Bus Controller (BC) can communicate with up to thirty
Remote Terminals (RT) in a multidrop configuration; the BC·
always provides data flow control and is the sole source ofcommunication. This hierarchical scheme perfectly fits into
our control system architecture: placing the BCs and the RTs
at the LPC and EIU levels respectively, separate MIL-1553B
branches connect each LPC to the Ellis it supervises. A
typical configuration is shown in figure 1. Moreover, amultidrop highway topology together with the appropriate
communication software permit to add and/or remove EIUs
with no system shutdown, catering for future upgrades,
requests or simple maintenance.
B. Electromagnetic noise immunity and data integrity
In order to guarantee a very good immunity from theelectromagnetic noise of an accelerator environment, a shielded
twisted-pair cable is adopted as MIL-1553B highway physicalmedium on which Manchester II biphase coded differential
signals are transmitted.
In addition to that, the following intrinsic "acknowledged
message" exchanging mechanism is used to assure data

S08NC07
Network and Communication

313

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC08

Network Communication Libraries for the Next Control System of the KEK e·/e+ Linac
Norihiko Kamikubota, Kazuro Furukawa, Kazuo Nakahara and Isamu Abe
National Laboratory for High Energy Physics (KEK)
Oho, Tsukuba, lbaraki 305, Japan
II. NE'IWORK COMMUNICATION LIBRARY

Abstract
The network communication libraries for the next
control system of the KEK Linac have been developed. They
are based on TCP/IP sockets, and show high availability
among the different operating systems: UNIX, VAXNMS,
and MS-DOS. They also show high source portability of
application programs among the different computer systems
provided by various vendors. The performance and problems
are presented in detail.

A. Principles for the Ubrary
The library "SCLIB" has been developed for the
TCP/IP protocol. It was designed as a tool for real-time datatransfer between processes, which is different from a filetransfer tool (like FTP), a file-sharing tool (like NFS), and an

workstation t

I. INTRODUCTION
The KEK 2.5-GeV electron/positron linac has been
controlled with a distributed processor network since its first
operation in 1982 [1,2]. Since, however, the system resources
have become inadequate for increasing demand, we haveintroduced several subsystems in order to extend the systemcapability [3]. Furthermore, we have studied the possibility ofsystem rejuvenation by a complete replacement of theminicomputers and their associated fiber-optic network withnew ones. The proposed next control system comprises Unixbased workstations as a man-machine interface, an Ethernet asa high-speed communication network, and VME stations as
front-end systems [4].
It is apparent that the tools for communication
between workstations and VME stations are needed in the
proposed system. In addition, some of the subsystems (theoperator's console subsystem which comprises DOS-based
personal computers [5], a diagnostic expert system for the
linac injector developed in a Unix workstation [6], a beamcurrent monitor developed in a VAXstation [7], and so on) are
expected to be used with the next control system. Thus,
communication availability between different operating
systems is important in our case.
We have developed a network communication librarycalled "SCLffi" for the media of Ethernet with the TCP/IP
protocol. Details are described in section II. Another libraryused to control the magnet power-supplies in the KEK linac,
called ."MGLIB", has been developed as an improved versionof the SCLIB. The features are demonstrated in the section m.
A discussion related to these libraries is presented in section
IV. We hope that our present experience will provide good
guidance for those who intend to introduce a similar network
communication system.

clientprocess
SCLIB(sendm)Ethernet(TCP/IP protocol}

workstation 2
SCLIB(recvm)serverprocessmain() r clienl process .,{int sc_open(), sendm(), sc_errend(), ac_c:lose(); r sclib •/extern Int sc_errno; r error c:ode holder for sclib functions *I
sd • sc_open( •servioe_name@nodename• ): r open connection •tif( sc_errno < O) sc_errend(); 1• error message & exit•/
rtn. sendm( ad, •message•);If( sc_errno < 0) sc_errendQ;r send a charcter siring •1

sc_c:lose( sd );r close connection •t}

Figure 1
Example of transferring a character string from a client
process (workstation 1) to a server process (workstation
2). The basic flow of the SCLIB function calls is also
shown.

S08NC08
318

Network and Communication

318

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC09

A Program Development Tool for
KEK VME-MAP Control System
H.Nakagawa, T.Katoh, E.Kadokura, A.Akiyama,
K.Nigorikawa and K.Ishii
KEK National Laboratory for High Energy Physics
object oriented programming, but 'OBJP' is notcomplete object oriented programming. So the'OBJP' is acommunicatable
multi-tasking
program development tool. But we think thatboth the 'OBJP' applications
andobjectoriented programming found on a same basic
idea;
each
functionisisolated
andcommunicate with each other by message.
Let's show the 'OBJP' programming, andthe configuration of the VME-MAP computer
system for the 12GeV PS control.

Abstract
The control system for KEK 12 GeV Proton
Synchrotron
has
been
replacedwithadistributed VME-bus based microcomputer system
and a MAP local area network. In order tosimplify programming for network application
tasks, a set of a preprocessor for a PASCAL
compiler and a network communication server
has been developed.
Application programsforaccelerator
control system have blocks with similar codes;
sending, waiting for,receiving, analyzing
messages, etc. The preprocessor called "OBJP"
incorporates such common codes into the sourcecode written by an application programmer.
In case of a simple program, the size ofthe source code is reduced by one tenth of afull coding.
I

IIThis control system consists of two major
devices; 26 VME-bus computers and a MAP local
area network.[2] All the VME-computers arelinked together in the same level. Their
physical connection is bus style, but logicalconnection is ring style by token-passing. All
computers are equal to each other in the
logical ring.
Eachcomputerdedicatestoeachspecialized function. There are computers of
one network manager, one program development,
four console and many device controllers asshown in fig.l.
The network manager is "UNIX", whichchecks computer condition and makes logging of
its information. The computer "ROLA". offers
multi-user programming environment, and sends
applications to other computers at rise-up of
the computer. The console computer works forhuman interface.
The
devicecontrollers
control the power-supplies and monitor theirstatus.
Video information
signalsarealsotransmitted through the MAP network cable.

Introduction

The present control system for the KEK
12GeV PS has been modified by using VME-bus
based computers and MAP local area network. On
these computers, application tasks work underthe
VERSAdos;
real-time
multi-tasking
operating systems. In this case, tasks in one
group run onsomecomputers
andtheycommunicate with each other by network. Then,
most important factor of such programs is thatany programmer can write the communication
function of applications easily. By reason ofthese
thoughts,
thenetwork
supportprogramming tool 'OBJP' has been created.
The 'OBJP' is preprocessor of PASCAL
compiler, but the source
file
of
OBJP
programming seems to be a new language system
like PASCAL.[l] And it also seems like the
NETWORKSOFTWARE¥ANAGEllENT

DEVllLOPllENT

UN IX

ROLA

IEEE

ff. E.

802. 4

10-110

170

lll!z

450

llHz

OPE4
CONSOLE

l

113

BT40

CONTROL

(-

-)
llAP

OP El
CONSOLEDEVICE

System configuration

4

PROF
llONITORING

ALRll
INFOR!IAT!Offt-----,----,...---.---l{IL-15538

SUBffETllORK

DEVICESFig.l

A scheme of MAP-VME control system.
The computers are connected with the MAP local area network.
The head end remodulator(H.E.l repeats signaling from the reverse
channel on the forward channel.
Each box shows a computer and ID named after the function
There are some broad-band amplifiers.

S08NC09
322

Network and Communication
322

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC10

Network Performance for Graphical Control Systems
Peter Clout, Mark Geib, and Robert Westervelt
Vista Control Systems, Inc.
134B Eastgate Drive, Los Alamos. NM 87544. USA

Abstract

Vsystem is a toolbox for building graphically-based control systems. 1be real-time database component, Vaccess, includes all
tbe networking support necessary to build multi-computer control systems. Vaccess bas two modes ofdatabase access, synchronous and asynchronous. Vdraw is another component of Vsystem that allows developers and users to develop control screens
and windows by drawing ratberthan programming. Based on Xwindows, Vsystem provides the possibility of running Vdraw either on the wodcstation with the graphics or on the computer withthe database. We have made some measurements on the cpu loading, elapsed time and the network loading to give some guidancein system configuration perfonnance. It will be seen that asynchronous network access gives large perfonnance increases andthat tbe network database change notification protocol can be either more or less efficient than the X-window network protocol,
depending on the graphical representation of the data.

I. lNTRODUCTION

Performance is one of the considerations when configuring computer control systems. Other considerations are equipment andsoftware costs. In order to help our customers to make intelligent
decisions we have made some initial perfonnance measurementson network real-time database access for both synchronous andasynchronous remote access, as well as some measurements tocompare network database change notification against network
X-protocol for graphical data presentation.

II. VSYSTEM'S REAL-TIME, NETWORKEDDATABASE

process that can take many milliseconds. The network messages
contain few useful bytes leading to inefficient cpu and network
utilization.
With asynchronous access, a program can make many calls andthen call a wait routine, at which point the program will not continue execution until all the calls have been completed. Not requiring an immediate answer means that the Vaccess routines can
include many, if not all, the remote database access requests ina single network packet with a consequent dramatic increase in
cpu and network utilization.
The arrival of X-windows and X-terminals bas recently given
the implementers of graphical control systems more configura·tion options. One can use wodcstations all running tbe graphics
software and all accessing the data over the network, or one canuse a single, powerful, processor running a single copy of thegraphics software and serving the users at X-terminals. Bothconfigurations have advantages and· disadvantages. Here we attempt to quantify the network issues in this choice.

m. REMom DATABASE AcCBss
MEASUREMENTS
Vsystem supports VAX/VMS and VAX/ELN. All of these measurements were made between two VAXstation 3100 model 30
wodcstations rated at 2.7 VUPs, running VAX/VMS V5.4-2,
current VAXstations have performances about four to five times
that of the VAXstation 3100 model30. It is important to note thatthese measurements were intended to compare the different protocols and they can never replace benchmarks on the proposedcomputers as many factors affect the system perfonnance apartfrom the cpu rating.

Vaccess is the real-time database component ofVsystem [l]. A
library of access routines allows for full access to the run-time
database. Routines are included to search the database in various
ways and to request and cancel change notification by wake-up
or interrupt routine (AST) execution. The library of access routines handles the network transparently to the user. Network access can be either synchronous or asynchronous.

The network protocol used by Vsystem in these measurements
was DECnet. The test consisted of a program running in one
VAXstation 3100 model 30 which called multiple "RPUT"s and"RGET"stoadatabasechanneiinadatabaseonanotherVAXstation 3100 model 30. "RPUT" and "ROBT'' are Vaccess librarycalls to put and get a real number to and from a channel. Standard
VMS library calls were used to access the elapsed time and cpu
time, and VMS NCP was used to report the network bytes andmessages.

With synchronous access to a remote database, the program mak·ing the Vaccess routine call will not continue execution until therequest bas been sent over the network and a reply received, aTable 1 on the following page lists the measurements made for1000 calls. Measurements for larger and smaller numbers ofcalls
scaled with the measurements in Table 1.

S08NC10326

Network and Communication

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC11

A New Approach in Development of Data Flow control and Investiqation
system for computer Networks

I.Frolov, A.Vaguine, A.Silin
USSR Academy of Sciences
Moscow Radiotechnical Institute
Warshawskoe shosse, 132, 113519 Moscow
follows: ALISA as a first step, and DECNET for our
perspective, when we will get a more powerful corr-.:iuters.

ABSTRACTThis paper describes a new approach in development
of data flow control and investigation system for c~ter
networks. This approach was developed and appl led in theInstitute forcontrolandMoscow Radiotechnicalinvestigations of Institute c~ter network. It allowed
us to solve our network current problems successfully.
Description of our approach is represented below alongwith the most interesting results of our work.

INTRODUCTION
Seven years ago we started the development of a
new control
system for an experimental electron
accelerator in our institute. It was planned at the
beginning to apply
six computers PDP 11/70 and six
computers PDP 11/23. These c~ters were interconnectedby lines DL Kl/SI ( These lines were developed andmanufactured in the USSR. The throughput is about 500
kbit/sec). The operating systems are RSX11M/S.

OUR PROBLEMS
It was planned to control the accelerator from a
dedicated console. Console consists of four graphicalstations. Each graphical station is a ordinary network
node (from viewpoint of network service). In addition one
c~ter was planned for a database management. And thefirst task for us was to investigate application
efficiency of network graphical stations and network
database. At that time first users of our network
appeared. This period is characterized as a period ofdevelopment and debugging of software for accelerator
automation. Terminals and c~ters were placed indifferent rooms. And often the main problem for users was
to find a free terminal. If free terminal was connected toanother c~ter he used either virtual (remote) terminal
service or virtual disk. Also network services were used
for transfer of files, and copying of disks and magnetic
tapes. In addition another problem for us was the<:::::)PDP 11123O
PDP uneFigure 1. Network structure (1988).
The main our problem was a choice of network software. Inthat time we knew the DECNET and the so called ALISA, andhad two class of software simultaneously on each conputer.
One week we used DECNET and next week ALISA. The DECNET isa more powerful network package, but the main problem for
us was a limited size of available operating memory. Firstof all it is valid for PDP 11/23. The compromise was as

development and . enhancement of our network. Many
colleagues from other experimental systems asked us toconnect their c~ters to our network for use ofgraphical stations, plotters, densitometer. Figure 1
illustrates a structure of our conputer network ( 1988).
And the vital problem for us was the creation tools for
network investigations to solve correctly all our
problems.

S08NC11
Network and Communication

329

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP01

Concurrent Control System for the JAERI Tandem Accelerator
S, Han as him a, T. Shoji, K • Horie and Y. Tsukihashi
Japan Atomic Energy Research InstituteTokai-mura, Naka-gun, Ibaraki-ken 319-11, JapanOn an usually available multi-tasking
operating system, it is possible to describe the above concurrency. But it isConcurrent processing with a multi-processor system is introduced to thenot practical because of the overhead to
manage too many processes and commuparticle accelerator control system region.
The control system is a good application
nications. Thus we must divide thein both logical and physical aspects. A
processes only at a moderate level andrenewal plan of the control system for the convert many concurrent processes toseveral sequential programs in the actual
J AERI tandem accelerator is discussed.
implementation, The resultant programs
are difficult to understand. The multi
Introduction
tasking operating system is not ideal forthe above modelling,·
Progress in the micro electronics
region makes real concurrent(parallel)
The merit of concurrent programming
processing reasonable for various applica- is enhanced by use of multi-processor,
tions today. In the logical aspect, a con- The concurrent program distributed on
multiple processors can give us dramaticaltrol system of a particle accelerator is a
merit of performance, because computing
combination of many processes concurpower of the multi-processor is proporrently working for control and monitoring. This implies that the control system tional to the number of processing elements. It depends on the concurrency of
may be a good application of the concurthe application (explicit or implicit) andrent processing. In the JAERI tandem,
current state of the computer technology.
we are working to renew the computer
control system. A multi-processor system Digital Integrated circuit technology isand concurrent programming language will advanced to increase density of circuits
and the performance, Today,
be used in the new system.
high-performance micro processors areavailable with a low cost,
Concurrent processing in the control
systemWell organized multi-processor system has
good cosf performance ratio.
We can treat a control system of a
Communications are important in thesystem. They are ones between procesparticle accelerator as a set of processes
sors and ones between processor andto monitor and to control many devices •external elements. Not only high transfer
They have different tasks(roles) weakly
rate of the data, but also short leading
coupled with each other. We can depict
time are necessary to get good response.
the system with a model of processes
We are interested in Transputer/2/,
communicating with each other by message
transmission, called communicating process OCCAM/3/, /4/ and CP architecture as abase. OCCAM and transputer werearchitecture (abbreviated as CP architecdeveloped together by INMOS limited asture) /1/. A concurrent programming
parallel programming language and milanguage based on the model simplifies
cro-processor to execute the concurrent
programming of the control system,
program respectively. Both are commerbecause of easy description of the intrinsic concurrency and communication in the
cially available with a program developsystem,
ment system.
Abstract:

S09DPP01
Distributed and Parallel Processing

333

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP02

Palantiri:
A distributed real-time database system for process control.
BJ. Tummers, W.P.J. Heubers
bas@nikhefk.nikhef.nl, wimh@nikhefk.nikhef.nl
National Institute for Nuclear Physics and High-Energy Physics, section K
P.O.Box 41882, 1009 DB Amsterdam, The Netherlands

I. INlRODUCTION

Abstract

The medium-energy accelerator MEA, located in

The National Institute for Nuclear· and High-Energy

Amsterdam, is controlled by a heterogeneous computer

Physics (NIKHEF) operates for about ten years a linear

network.

A large real-time database contains themedium-energy electron accelerator (800 MeV). Currently

parameters involved in the control of the accelerator and

Lhe accelerator is extended with a pulse-stretcher ring. At

the experiments. This database system was implemented

the same time the experimental facilities are renewed andabout ten years ago and hns since been extended several

according to the plans the first experiment with this newtimes. In response to increased needs Lhe database system

set up will sLarL in the summer of 1992.

has been redesigned.

All these facilities are controlled by a number of

The new database environment, as described in thiscomputers running a home made real-time operating

paper, consists out of two new concepts:

system in a point to point communication network and a• A Palantir which is a per machine process that stores

number of Unix based machines (ref[l]). To preventthe locally declared data and forwards all non local requests

possible conflicts all hardware control is performed underfor data access to the appropriate machine. IL acls as a

Lhe supervision of a device, which historically is called astorage device for data and a looking glass upon the

database, in which all values are stored before they areworld.

sent to the hardware. This database was designed ten years• Golems: working units that define the data within theago, uses one (real-time) machine as central storage

Palantir, and that have knowledge of the hardware Lhey

device. Although this system is functioning well and has

control.

proved its reliability in the past years, it has some

Applications access the data of a Golem by name (which

disadvantages: it offers two different way to access data

do resemble Unix path names). The palanlir Lhat runs on(by name, and by number), changing its layout isthe same machine as the application handles the

cumbersome and maintaining it appeared to be quite

distribution of access requests.

difficult.

This paper focuses on the Palantir concept as a distributed
dara storage and event handling device for process control.

Obviously, we wanted something new. This paper
describes the aims, the concept and some details of theimplementation of the new system. In the last section thecurrent status of the project and plans for the future are
discussed.

S09DPP02
336

Distributed and Parallel Processing

336

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP03· Intelligent Trigger by Massively Parallel Processors for High Energy
Physics Experiments
Francois Rohrbach
CERN, CH-1211 Geneva 23, Switzerland
G. Vesztergombi
Central Research Institute for Physics (KFKl)i H-1525 Budapest 114t POB 49, Hungary

EPFL-Lausanne (CH), University of Brunel (UK), University of Geneva (CH) 1 CRIP/KFKI Buda.pest (H) and
The CERN-MPPC collaboration concentrates its effort Thomson-TMS (F), as associated partners. The applicaon the <levelopmen' of machines based on massive paral- tions are dominated by but not exclusively driven by thelelism with thousands of integrated processing elements, problem of triggering events in HEP; EPFL, as MPPC
arranged in a string. Seven applications are under de- partner, is indeed working on a first application in image
tailed studies within the collaboration: three for LHC, processing for HDTV. More generally, it can be expected
one for SSC. two for fixed target high energy physics at that the same basic processing elements will find their way
CERN and one for HDTV. Preliminary results are pre-- into quite different application fields. Indeed, the almost
sented. They show that the objectives should be reached infinite scalability of the ASP architecture[l] and its imprellllive performance targets (in terms of cOilt, power andwith the use of the ASP architecture.
achieved density) will attract other suitably parallelized
projects (e.g. relational data processing, simulation, computer vision, cellular automata, neural networks) in appliL INTRODUCTION
cations such as, high-definition TV, autonomous guiding
vehicles, artificial intelligence, medicine, space science, meHigh luminosiLy hadronic colliders (LHC & SSC) will re- teorology, plasma physics, etc. Even one can think aboutquire novel detectors, both highly time-sensitive and selec- possible application for on-line accelerator control.
tive. Potentially, Megabytes data will be produced at rates(66 MHz at LBC) that ate beyond performance of todaymodern transmission and recording technology. From thisII. THE ASP ARCHITECTURE
huge a.mount of information, however, only a tiny fractio11
is possessing any real interest. The required high selectivity is assumed to be achieved by a two steps procedure. A
The choice of the ASP, as a R & D platform for the
first-level decision based on simple "hard-wired" logics can Collaboration, was based on the exceptional potentialities
provide significant rate reduction, it leaves, however, for offered by this new architecture which allows a wide range
the second* level decision so complex patterns which require of applications.
a detailed analysis similar to what is done today in off-line
programmes, but with an event frequency of typically 100
The main hardware task is to build four ASP machines,
kHz. Such decisions, based on a huge number (10 to 100 one for each main partner, with 16384 APE array, refened
Mbytes) of digitised local or global data. coming in a narrow to as the "MPPC array". It is based on the.existing VASPtime window, will require the fast execution of precisely 64 VLSI ASP chip used for the TRAX-l machine, anothertuned algorithms in extremely fa.at computer-like deviees. ASP project dedicated for off-Jine image processing [6,7].
Industry and computer science make: serious efforts in this The MPPC.array design allows for maximum processor elfield. The MPPC (Massively Parallel Processing Collabo- ement density and maximum direct parallel interfacing via
ration) is concentrated on problems that are likely to bene- conventional electronics to the readout of particle deteefit from massive parallelism of SIMD type. Such massively tors, For this task, dense packages of ASP must be conparallel machines operate with thousands of processing el· structed. This is based on a modular design, using hybriements, all highly integrated and controlled under a sin- dation on insulators of the VASP-64 chips. These modules
gle controller. Taking advantage of the application needs are built by PolyCon (USA) ; they eontain a string of 1024
and of the coincidence between technological opportuni- APEi (16 chips) with two parallel I/O per module. The&eties • the development of a new kind of SIMD machine by modules will be installed on boards to make 8K strings.
ASPEX Microaystema (UK): the ASP (Associative String Two ASP boards and a low level controller (LAC) in exProcessor [l]) and the continuous improvement in silicon tended VME standard (in order to be compatible with exintegration (VLSl/WSI) - a. Research and Development isting industrial modules) are under construction for eachprogramme "The MPPC Project" has been launehed (2- 16*K MPPC.Array machine.
5] between ASPEX (UK), CERN (CH), CEA/CEN-Saclay
and CNRS/IN2P3-LAL-Oraay (F), as ma.in partners, andAbstract

S09DPP03
340

Distributed and Parallel Processing

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS01

Realtime Aspects of Pulse-to-Pulse Modulation
Rudolf Steiner, Claus Riedel, Werner Rosch
GSI, Postfach 110552, D-6100 Darmstadt, Germany

Abstract
The pulse-to-pulse modulation of the SIS-ESR
control system is described. ·Fast response tooperator interaction and to changes in process
conditions is emphasized as well as the essential
part played by the tintlng system in pulse-to-pulse
modulation.

I INTRODUCTION
The benefits of pulse-to-pulse modulation in acceleration operating have been described as early as'77 [1 ]. It is an effective way to increase the overall output of valuable beamtime of one or more
accelerators. With beamsharing, rarely all usersof the beam will be unable to accept the beam at
the same time. If the PPM-handling quickly responds to changing conditions, there will be virtually no dead-time in the machine operating due toinevitable dead-times of experiments, e.g. during
new experimental setups.
In a multi-accelerator facility, PPM is almost
imperative. Asynchronously running machines,
every one of them operating as an inject.or for the
next one, normally have time left between subsequent injections that can be used for experiments.

II

CONTROL AND TIMING SYSTEMS

Much has been said and will be said at this conference about the major trends in control systems in
the last decade. Most systems recently designed
or upgraded are looking more and more similar:

Graphic workstations are the operators' I/O tools
and software development platforms. The workstations are linked to a communication backbone.
Ethernet, Token Rings, or fiber optic links a.recandidates. The choice rather depends on the
distances to be mastered than on technical advantages or disadvantages.
To the same backbone, eventually as subnetworks with bridges in big systems, the equipment control computers are connected, which aremainly VME- 1 Multibus-, or CAMAC-based.
Extensive use of graphics and CASE tools has
made an essential improve1~1ent in the .operator's
and software designers' access to control systems.
The overall trend is from very special systems
tailored to the very special task of accelerator control towards more uniform, general purpose systems and the use of standards of the marketplace.
On the process level, however, the special needsof accelerator control, mainly realtime and synchronisation, do still exist or are b.econtlng evenmore complex. Therefore the functionality of acontrol system must be biased by a timing system. The diversity of control systems of old has
it's evolutionary relic in the diversity of timing
systems, which will resist standardisation trends
for another while. The more the higher levels
in a control system become general purpose (andless realtime), the more process-specific problems
must be solved on the lower levels. This is thedomain of the timing system, the equipment controllers, and, of course, the equipment hardware.
In the trend to general purpose systems the designof the tintlng system determines the overall performance significantly. The functionality of thetiming system may range from simply providing

S10TS01
Timing and Synchronization

345

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Injection Timing System for PLS

S.S. Chang, M.S. Kim, S.J. Choi, S.C. Won, W. Namkung, and S.Y. Park
Pohang Accelerator Laboratory,

POSTECH, P.0.Box 125,
Pohang 790-600, Korea

of 180°. All of these systems are operated very closely throughthe timing system.
Injection into the SR accomplishes via a Lamberson septum
and the kicker magnets. Prior to injection, the storage ringclosed orbit is bumped close to the end of the injection septum
by four bump magnets. A pulse of electrons is then transported
through the injection septum into the SR. After injection, thebump magnets are turned off in a time corresponding to about
two orbits of the ring to prevent the stored beam from disturbunce of the kicker field. The newly injected beam then undergoes coherent betatron oscillation about the closed orbit-motionthat is rapidly damped by means of synchrotron radiation damping. This process is repeated at the cycle rate of kicker magnet
until the desired beam current is reached.

Abstract
The ultimate goal of the PLS timing system is to successfully
inject a electron bunch to a predesigned bucket in the Storage
Ring.
In the Linac, a pretrigger of 102.8 microseconds prior to the
Gun trigger may be required to charge the pulsed divces properly
and it should be precisely delayed to synchronize with beam passat each accelerating column.
To inject the electron bunch, which fully acceleated in the
Linac, into a target bucket of SR, the injection kicker magents
must be energized to provide the appropriate magnetic field. For
the sequential filling of the SR buckets, the appropriate timing
delays throughout the entire timing system are programmably
controlled by operator.

Timing Sequence
Introduction
The Pohang Light Source (PLS) consists of two individual
particle accelerators all working in concert to ultimately produce
the high brilliance X-ray to the experimenters: the Linac and theStorage Ring (SR). Both accelerators are composed of varioustransient devices like an electron gun, the booster and klystron
modulators, injection magnets, and etc. In the Linac, an electron
bunch is accelerated up to 2 GeV for full energy injection, while
the SR accelerate the particle only to replenish any energy loss
by synchrotron radiation.
The Linac rf system is composed of a booster station, 11high-power klystron modulator and 10 pulse compressors. It's
operating frequency is 2,856 MHz. In the booster station, thedriving system provides the optimum condition of the drive signal for high-power klystron and the phasing system make thephase synchronization between the electron bunch and the accelerating wave. The function of these system is to get the maximum beam energy and minimum energy spread on the basisof a stable drive sytem and correctly phased high-power wave
guide network. The typical output pulse length from the booster
modulator is 4 usec. The high-power modulator supplies pulse
voltage to the high-power Klystron. It can operate in two mode
: an acceleration mode and a standby mode. In the accelerationmode, the output power is delivered to the accelerating column
at the time synchronized to beam pass and then the beam is accelerated. In the standby mode, the output power is delayed withrespect to the beam passage and has no effet on the beam. Typical specifications of the modulator are 60 pps pulse repetition
rate, and 4.4 us flat top pulse width. Meanwhile, the klystronthat utilized the pulse compressor require a phase reversal gate.
So the PSK on the booster station is used to reverse the phase

The timing sequence is shown in Fig.1,2 to illustrate thatmany events are initiated by a pretrigger. In this sequence all
the transmission delay are neglected for simplicity. It is supposed also to be no delay for the beam from the gun to injection
point, where injection point means the bucket into which theelectron bunch is transferred. The time between consecutive
buckets passsing a fixed point on the SR is 1.9996 nsec because
the SR has 468 stable rf buckets into which a bunch of electrons
can be injected. One periode of the rf is named a "tic" so a tic

NOTE:''lM:" • I/ (500.082 Miiz)....... I/ (1.07 Miiz)

JlepctilionRa\C(10 Hz. 60 lh Mu.)Pn<riaacr.t

Injcaion Trigger

Fig.1 Timing Sequence (I)

S10TS02
Timing and Synchronization

349

349

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S10TS02

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS03

Automated Control System Structureof the USSR Academy of Sciences Kaon Facility
Yu.S.Ivanov, V.A.Konovalov,

B.P.Murin, L.L.Filipchicov

Moscow Radiotechnical Instituteof the USSR Academy of Sciences
S.K.Esin, Yu.V.Senichev
Institute for Nuclear Researchof Academy of Sciences of USSR

1.Introduction
Up to date at Nuclear

Research

Instituteof the USSR AS CMoscow-Troitsk) it isfinishedbuilding of Moscow Meson Facility
sity current

proton(beam parameters:

Linearenergycurrent - 0.5 mA, pulse

high

fxp.7,5Ge-,
i'zam BR

inten-

Accelerator
600 MeV,.--~"-'~.--~-'-~...-~~~...----' SS
SR·

C.

CLA)

SR

b.

SS

averagecurrent - 50 mA).

The

LA proposed to serve as Kaan facility (KF)

in-

:From BR
SS

SR
fxp. 7,51',ev

jector which is under working out (1].
Kaon complex, in addition to LA, includes:
busterprotonsynchrotron

(BR)

with

BR

Hev
Uili.illf.IULl!JlliWJilillllJJltiillhltltltl!.WJfilllillhhllhltL:.E~.P·:!tom Lil

outputenergy 7.5 GeV, main synchrotron (SR) with oroton energy up to

45 GeV

and

flJO

toO

$00

400

500

600

t,;ns

80()

FL~ f, TLrno '2e9i.mes of Kao" compee:c Wo~kstorer-stretcher(SS). The KF is proposed to work at 3 regimes.
At first regime SS follows SR and isas beam stretcher.

KF

time

work

cleaned by Fig.la. A half of beam

diagrampulsesis

LA and BR is used at ones for physicalexperibetween

BR and SR and works as collector (Fig.lb.).

At

third regime it is supposed to store in SS

4-6

to

and measurement systems

The second groupwith 45 GeV energy)

withfrequency

of

Hz.

KF

systems,

technical

which

are

concernedofsystems

CRTS)

control(ACS)

unitesofwithmeasurement

The soecial features of

and

RTS

controlde-1) the complex

consistsofcascaderow

with which of cascade been working in different
regimes with differentofradio-

Besides

pends on two KF properties:

carticles

There are presented below brief descriptionfunction.

diagnostics systems generally.
The third group includes ACS equipment.

exceriment
14

diagnostics

feedback.

(Fig.le). The such kind using allows to receive
terra watt power level pulses (8· 10ofsoftware there are used also hardware AAS

fromments. At second regime SS is inserted

beam pulses with next fast exit

system corrections as a result

used

time

changing

charac-teristics;
2) the accelerators are fast recycling andhigh intensity beam devices.

adjusting (AAS).

High accelerating process velocity demands
increasing of RTS measurement and final-control
devices fast-responsibility,

2. RTS Interaction
KF RTS can be divided on 3 groups.

localizing of con-trol systems near by the firstgroup

using ofsystems.

distributed

control

RTS

and
These

demands are complicated also by highbeamparts immediately in technological crocess. The

tensity: it

resonator

systems

beam loading compensation and coherent betatron

The first group
work

in

unites

real

time

RTS,
scale

which

take

and

are

controlled with the help of devices with

early

needs

of

acceleratorsin-particles oscillations suppressing.

loaded programs, which operate according to ACSS10TS03352

Timing and Synchronization
352

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS04

The Development of RF Refe1·encc Lines and a Timing System
for Japan Linear Collider

J.Urakawa, T.Kawamoto, Y.Otake, Y.Satoh,T.Mima.shi and S.Araki
National Laboratory for High Energy Physics(KEK),
Oho 1-1, Tsukuba-shi, Ibaraki-ken, 305 Japan

Abstract

Table 1 Design Parameters of the JLC

The main linac of Japan Linear Collider(JLC) will be operated at an X-ba.nd frequency of l 1.424GHz. The positioning of the
X-band accelerating structures at JLC requires precise phase synchronisation over a.bout lOkm. Temperature compensated fiber
optic cables will be used for the transmission of the ll.424GHz
RF signal. The performance of this transmission line is described.
Many timing signals will be also transmitted from the main control room, in which the master RF frequency generator will besituated, via this l.3µm single mode fiber optic link. The outlineof the timing system for JLC is given in this paper.
I. INTRODUCTION

A. General
Japan Linear Collider( JLC) is a future project and an electronpositron collider for the energy frontier physics in Te V region. In
order to realize the JLC project, we have been discussing forseveral years on possible para.meter sets of the JLC. Fig.1 shows
the layout of the JLC according to the parameter set so far obta.ined[l ,2,3].
The ma.in beam parameters of the JLC are shown in Table
1. One of the characteristics of the present design of the JLC is

to operate in a multi-bunch mode. The lina.c accelerates bunchtrains where the bunches contained in a train a.re separated byabout 42cm(l.4nsec) and the number of particles per bunch is
2 x 1010 • Fig.2 shows the bunch structure of the JI.C.

The JLC timing system is divided into fast and slow timing
systems. Fa.st timing signal transmission system must achieve thetiming accuracy within lpsec over the temperature range from 23
to 27°0 and over 12.5km from the ma.in control room. For the
precise timing signal transmission, a optical fiber cable was developed[4]. This fiber cable showed the reduced thermal transmission
delay change less than lOpsec/km in the temperature range from
-20 to 30°G(average 0.04ppmf°C), which is 100 times smaller thanthat of any other existing coaxial cables and conventional optical

Polarized
Electron Gun

1.54 GeV
Pre-Damping Ring

RF GunThermionic Gun#2 BunchCompressor

O'z = 420µm

10 GeV Pre-Accelerator#2 BunchCompressor

10 GeV Pre-Accelerator

1.-~~~~~~~~-r'"l...-J,......,...{::.il-C:::::::::::::::::J-:'.a.w98-157µm
0.25. 0.75 TeV X·band Linac(40 -120 MeV/m)

IP

11.5 km

0.8km

0.6km

0.25 - 0.75 TeV X-band Linac{40 -120 MeV/m))IE

11.5 km

0.Skm

Total Length : 25 km
PositronElectronFig. l Layout of the JLCS10TS04
356

Timing and Synchronization

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS05

A NEW VME TIMING MODULE: TGS

C.G. Beetham, G. Daems, J. Lewis, B. Puccio
European Organi7.ation for Nuclear Research (CERN)CH - 1211Geneva23, Switrerland
Abstract
The two accelerator divisions of CERN, namely PS andSL, are defining a new common control system based on PC,
VME and Workstations. This has provided an opportunity toreview both central timing systems and to come up with common solutions. The result was, amongst others, the design ofa unique timing module, called TG8.
The TG8 is a multipurpose VME module, which receives
messages distributed over a timing network. These messages
include timing information, clock plus calendar and telegrams instructing the CERN accelerators on the characteristics of the next beam to be produced.
The TGS compares incoming messages with up to 256
programmed actions. An action consists of two parts, a trigger which matches an incoming message and what to dowhen the match occurs. The latter part may optionally create
an output pulse on one of the eight output channels and/or abus interrupt, both with programmable delay and telegram
conditioning.

I. INTRODUCTION
Until the advent of the Large Electron Positron (LEP)
collider each new accelerator built at CERN had its dedicatedtiming system. Each system was tailored to the specific needsof the machine and integrated into the control system. As theworking life of a large accelerator spans several decades, it
becomes necessary after a certain period to update the control
and timing systems. Such an upgrade was applied to the SPS
timing system in 1985 [1] and subsequently it was decided toadopt the same system for LEP.
The rejuvenation of the PS control system is presently
being implemented [2]. The TGS timing module, describedin this paper, will form an integral part of the joint
PS/SPS/LEP timing system. The TG8 is based on a similar
but simpler module, the TG3, currently in use at the SPS
and LEP.

II. ACCELERATOR TIMING SYSTEMSThe typical real time response of a large accelerator control system is in the region of 10 to > lOOOms. Whilst this isadequate for many applications there always remains therequirement to activate equipment with a finer real time resolution. Such an application would be the ramping of the main
power converters around LEP. This is achieved by using aseparate timing system.

General Machine Timing (GMT) systems for large accelerators normally consist of three parts:•

a central timing generator•

a distribution network•

receiving modules

This article concentrates on the VME receiving modules,
although the other two points are also discussed.
The central timing generator is constructed on a single
IBM/PC compatible card and is referred to as the Master
Timing Generator (MTG). It is basically a large memory
which is pre-loaded with machine related timing informationfor each cycle. At specific times the MTG broadcasts thisinformation over the distribution system. The MTGs for eachmachine are synchronized to a CERN wide lms reference
clock.
For the SPS and LEP machines it was decided to use
Time Division Multiplex (TDM) techniques, conforming to
CCITT Recommendations, to form a backbone for the distribution network. This was adopted due to the long distances
involved and also to reduce the number of cables required in
the two tunnels. Because of its much smaller size the PS willretain the use of dedicated cables. The overall timing transmission standards used at CERN have been described elsewhere [3].
The receiver modules (TG8s), so named because they
have eight output channels, are connected to the timing network and receive information in the form of frames referred
to as events. The use and operation of the TGS is describedin more detail later.

Ill. EVENTS
A. Standard events
Standard events mark precise times within a machine
cycle, i.e transition, start fast extraction, end of flat top etc.
In particular, they are used to initiate actions in the TGS
action table. Such an event has a "header", identifying it witha given machine, plus a one byte code specifying which standard event it is. In addition to this, each standard event isalso tagged by a cycle type, and the occurrence number ofthat type in the super cycle, namely the Cycle Number.
B.

lkHz Clock EventsThe lkHz event is used to synchronize up to seven preceding events which may have arrived during the previous
millisecond period. This type of timing frame is thus

S10TS05
360

360

Timing and Synchronization

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS06

Modular Pulse Sequencing in a Tokamak Syste•.
A.C.Chew, S.Lee and S.H. Saw
Plasma Research Laboratory
Department of Physics
University of Malaya
59100 Kuala Lumpur
Malaysia

Abstract
Pulse technique appliedinthetiming andsequencingofthevarious part of
the MUT
tokamaksystem are discussed.
The modular
architecture
of
the
pulse
generating device .highlights theversatile application of the simple
physical concepts inprecise andcomplicated research experiment.
I.

Introduction

In experimental
studies ofpulse
plasmadevices,timingandsequencing of
the various events
are an important partoftheexperiment andrequirescarefulconsiderations.
This
is achievedin the MUT(University of
MalayaTokamak)tokamak svstem [lJbyemployingmodulararchitecture
involving various modules ofpulse
generating devices [2J.
II.

coroidal eoil

Fig. lThe MUT system.

litres s- 1 diffusion pump backed bya rotary pump.
The system provides
a base cressure of 10-~ torr.
Thetoroidal field coil consists of 99
turns of insulated copper wire of
total cross-sectional area of 0.3
cmz. coil resistance of 0.02 n andinductance of 95 µH, giving atime
constant for the toroidal field of
4.7 ms.
It is powered by a 4.5 mF,
1.3 kV capacitor bank system while
the ohmic
heating'systemarepowered
by a
5 µF,
20
kV
capacitor bank.
The block diagramin Fig. 3 shows the sequence of
operation of the various stages.

The MUT System

The MUT system consistsofthestainless steel
toroidalchamber,
the toroidal field coil svstem andthe ohmic heatingcoil
systemincorporating
the vertical
field
generating design is assembled asshown in Fig. l.
The major
radiusof the chamber is 25 cm while theminor radius is 5.4 cm.
The
torus
is
dividedinto
twohalvesseparated by insulating
flanges.
The diagram of the top view ofthetorus is shownin Fig.
2.
The
vacuum svstem uses a 300

S10TS06
364

Timing and Synchronization364

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The Timing System of the RFX Nuclear Fusion Experiment
V. Schmidt*, G. Flor, G. Manduchi, I. Piacentini+

Associazione EURATOM - CNR - ENEA, Padova Italy
2. TIMING SYSTEM HARDWARE COMPONENTS

ABSTRACTThe RFX Nuclear Fusion Experiment [l] in Padova,
Italy, employs a distributed system to produce precision trigger signals for the fast control of the experiment and for theexperiment-wide synchronization of data acquisition channels.
The hardware of the system is based on a set of CAMAC
modules. The modules have been integrated into a hardware/software system which provides the following features:
generation of pre-programmed timing events
distribution of asynchronous (not pre-programmed) timing
events,gating of timing event generation by Machine Protection
System,automatic stop of timing sequence in case of highway
damage,dual-speed timebase for transient recorders,system-wide precision of s 3 µs, time resolution~ lOµs.
The operation of the timing system is fully integrated
into the RFX data acquisition system software. The Timing
System Software consists of three layers: the lowest one corresponds directly to the CAMAC modules, the intennediate
one provides pseudo-devices which essentially correspond to
specific features of the modules (e.g. a dual frequency clock
source for transient recorders), the highest level provides system set-up support
The system is fully operational and was first used during
the commissioning of the RFX Power Supplies in spring '91.

1. SIGMAThe Timing System is part of the fully computerized system for experiment control, monitoring, and data acquisition
known as SIGMA (Sistema di Gestione, Monitoraggio ed
Acquisizione Dati) [2]. SIGMA employs two distinct technologies: PLCs and CAMACN AX systems. Nine large
PLCs, grouped into four subsystems provide slow control andcontinuous monitoring of the corresponding machine subsystems. Fast data acquisition and the generation of the precision
trigger signals and of the fast reference wavefonns is implemented by means of CAMAC equipment connected to a central VAXcluster via a fibre optic CAMAC Serial Highway
implementation. All components of the system are connectedto the same fibre optic Ethernet.

*+

under contract from Hahn-Meitner-Institut Berlin GmbH,
Berlin , Germany
now with SPin s.r.l., Milano, Italy

2.1. THE TIMING HIGHWAY

The CAMAC modules of the timing system are connectedby a single optical fibre Timing Highway which carries thetiming events in encoded fonn, imprinted on a 1 MHz carrier
clock. Each timing event is encoded in a 10-bit frame. The
fibre and connector are identical to the ones used both for thefibre optic Serial Highway and for the fibre optic Ethernet.
2.2. CAMAC MODULES

The system employs three types of CAMAC modules
which provide the following functions:
The Encoder Module generates encoded timing events; it
can be seen as the input device of the Timing system. Each
Encoder can generate a maximum of seven events, of which
six are produced by hardware inputs and one by software command. The event inputs are priority encoded. The code associated with each event is pre-loaded via the CAMAC interface.
The Decoder Module is the output device of the Timing
System. The module can be divided in two sections: the coderecognizer section, which matches encoded events traveling on
the Timing Highway to pre-loaded codes held by internal registers, and the counter-timer section. The module contains acrystal oscillator, which can be used as master clock. The
module provides a rich set of options and operating modes
The Timing Event Recorder module can log up to 512
timing events together with their relative time of registration
with reference to a start event (software or hardware defined).
Encoder and Decoder module have been developed for theTokamak de Varennes [3]. The Timing Event Recorder has
been added by RFX. All modules are commercially available [4].

3. HW SYSTEM DESCRIPTION
3.1. TIMING HIGHWAY STRUCTURE

From an operational point of view, a clear distinction has
been made between parts of the timing system which arerequired to be permanently 'on-line' and which are essential toproduce a plasma shot and other parts which could be excluded,
intentionally or unintentionally, without preventing normal
operation. Hence, the timing system has been separated in two
sections: Machine Section and Diagnostics Section (Fig. 1).
The Machine Section delivers timing signals to all the essential machine components, i.e. converter units, gas injection
control, essential data acquisition equipment. The Diagnostics

S10TS07
Timing and Synchronization

367

367

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S10TS07

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS08

An Optical Fiber Phase Lock Networkof a Radio Interferometer
Masanori Nishio, Susumu Kawashima, Chikayoshi Torii, Hiroshi Nakajima
Nobeyama Radio Observatory, National Astronomical Observatory
Nobayama, Minamisaku, Nagano, 384-13 Japan
Toshio Takabayashi, Katsuhiko Nishikawa, Norio Futagawa
Space and Laser Communication Development Division, NEC Corporation
Ikebe 4035, Midori-ku, Yakohama, 226 Japan
and
Shigeru Tanaka
Sumitomo Electric Industries Ltd. Yokohama Laboratory
Taya 1, Sakae-ku, Yakohama, 224 Japan

Abstract
A new phase-lock network using fiber-optic system wasdeveloped as a. local signal distribution system for 84 antennas of the Nobeya.ma. Radioheliogra.ph. This network is
a. open loop system a.nd consists of a. master oscillator with
an E/O converter, a 1-to-84 optical divider, phase stable
optical fiber cables and phase stable phase-locked oscillar
tors with O/E converters. Phase stability of the networkand phase noise generated at the 0 /E converter a.re discussed. This phase-lock network insures the required phasestability of 3deg/6hours. The phase noise increases the coherent loss of 0.1% at the correlator output, which is very
low. This is the first large application of fi her optic devices
to an open loop phase-lock network. Our system is very
simple and phase-stable. Therefore, it is suitable to theconnected array with large number of antennas.

1

INTRODUCTION

RF signal transmission systems using optical fibers haveadvantages of low loss, wide bandwidth and high durability to electro-magnetic interferences. These characteristics
a.re beneficial to long-distance signal transmission. Furthermore, development of a specific optical fiber extended
applications of the fiber-optic system to precise timing signal transmission and phase-lock link [1]. At the JPL, afiber-optic system was tested to distribute a reference frequency to a. Deep Space Station, which usually employedcoaxial cables [2]. In a VLBI system of the National Astronomical Observatory, Japan, the fiber-optic system isinstalled to transmit a frequency standard signal from ahydrogen master to a remote antenna. The phase stability was about 55 times better than ordinary coaxial cabletransmission systems [3]. At the National Laboratory forHigh Energy Physics, Japan, a part of coaxial cable link

between the 2.5GeV LINAC gun room and the TRISTAN
control room was replaced by a fiber-optic system [1]. Another a.pproa.ch using an active phase stabilizer was also
developed a.t the JPL, and it compensated the delay va.ria.tions using signals re:H.ected at remote units [4]. At the
CSIRO, an optical fiber network is installed to the Australia. Telescope. This telescope is a radio interferometerwith 5+1 pa.ra.boloidal antennas of 22-m diameter and aclosed loop network with active phase stabilizer is used tolock the phase of local oscillators.
In the radio interferometer, precise measurements ofphase among received signals are quite essential to synthesize high-quality images. Although the closed loop phaselock network is quite stable, its configuration is complicated. As the open loop network has a simple structure,
it is suitable for the interferometer with large number ofantennas. At the Nobeyama Radio Observatory, a new
radioheliograph is now under construction (5]. This system is a radio interferometer for solar observations, which
consists of 84 small paraboloidal antennas of 80-cm diameter. These antennas a.re aligned on a T-shaped baseline of
490m ea.st-west and 220m north-south. In this system, an
open loop phase-lock network is installed to synchronize
local oscillators. This is the first large application of -fiber
optic devices to an open loop phase-lock network. The
phase stability of the open loop network is sensitive to thephase responses of the devices in the network. In addition,
noises generated by the optical devices in the network increase phase noises oflocaJ oscillator outputs and degrade
the sensitivity of the interferometer. Therefore, we haveanalyzed the phase stability and the phase noise of thisnetwork.
In this paper, we describe the outline of the developed
optical fiber phase-lock network and discuss the phase stability and the phase noise of this network.

S10TS08
Timing and Synchronization

371

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Replacing PS Controls Front End Minicomputers
by VME Based 32-bit Processors
A. Gagnaire, N. de Metz Noblat, Ch. Serre. Cl.H. Sicard
CERN - 1211 Geneva 23 - CH

Abstract

equipment, the serial CAMAC loops are kept and their control
are done via a serial driver module in the VME crates. [4J

The PS controls have started the first phase of systemrejuvenation, targeted towards the LEP Preinjector Controls.
The main impact of this phase is in the architecturalchange, as both the front-end minicomputers and the CAMAC
embedded microprocessors are replaced by microprocessor
based VME crates called Device Stub Controllers (DSC).
This paper discusses the different steps planned for thisfirst phase, i.e:
- implementing the basic set of CERN Accelerator common
facilities for DSCs (error handling, system surveillance,
remote boot and network access);- porting the equipment access software layer;• applying the Real-time tasks to the LynxOS operating
system and J/O architecture, conforming to the real-time
constraints for control and acquisition;- defining the number and contents of the different DSC
needed, according to geographical and cpu-load constrainlS;- providing the general services ouiside the DSC crates (fileservers, data-base services);- emulating the current Console programs onto the newworkstations.

I. INTRODUCTION
The CERN accelerators are composed of two sets: the PS
Complex of ten small and fast cycling machines (PSDivision), the SL Complex of two big and slow cyclingmachines (SPS and LEP, SL Division). The rejuvenation of
the CERN Proton Synchrotron control system is done on abasis of a common CERN project, aiming at a real
convergence between all accelerator control systems. [l] [2]
The first phase of PS control system rejuvenation has
started in 1991 for the subset of LPI machines (LEP PreInjector). [3] The main impact of the architectural change isthe replacement of both front-end minicomputers anddistributed CAMAC embedded microprocessors by a set of
distributed microcomputers linked on an Ethernet segmentwith a local file server.
These microcomputers called DSC (Device StubController) are based on both standards PC and VM.E cratewith 32-bit embedded microprocessors. For the PS control
system, the VME crates are mainly used. The DSC provides a
uniform interface to the equipment and acts as a master anddata concentrator for distributed equipment, interfaced via fieldbuses. Due to the large investment in the associated interface

II. BASIC FACILITTES fOR DSC

A. Control System Architecture
The common accelerator control system architecture
consists of three layers:- control room layer with workstations and central servers,- front-end computing layer distributed around acceleratorsand based on the DSC,
- equipment control layer with ECA (Equipment Control
Assembly) control crates which form part of theequipmenL
For the PS Control System the communication between
the two first layers, as well as the communication withinthese layers, is based on a TCP/IP network. The processor of
the VME crate has an on-board Ethernet controller as astandard link to the network, and is a diskless machine forreliability [disks proved to be the weak point of the actual
LEP PCA (Process Control Assembly)] and becawie the backup procedures and management of files and data are supposed
to be easier when storage is less distributed. The different
programs of the different DSC are centralized on a single

server.

B. Choice of a Real-Time UNIX Operating System
The constraints choosing an operating system for the frontend processors were the following:- the system has to be real-time in order to warranty a
predictable response time to external events,- the same operating system must be available for both
VME based MC68030 and PC processors,• for networking, TCP/IP (with BSD socket interface
library) and NFS client are required,- system must be able to run diskless without swapping,- shared libraries and data segments are required, as well assource level debugger.
In order to minimize the formation required to develop
applications, we had to minimize the heterogeneity between
various systems. We had to re-use common facilities
developed for the LEP accelerator control (based on Xenix
system). This resulted in the choice of the LynxOS real-time

S11LLC01
Low-Level Controls

375
375

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S11LLC01

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC02

Device Controllers using an Industrial Personal Computerof the PF 2.5-GeV Electron Linac at KEK
Yuji Otake, Mitsuhiro Yokota, Kazuhisa Kakihara,
Yujiro Ogawa, Satoshi Ohsawa, Tetsuo Shidara and Kazuo Nakahara
National Laboratory for High Energy Physics
1-1, Oho, Tukuba-shi, Ibaraki-ken, 305, Japan
Abstract
Device controllers for electron guns and slits using an
industrial personal computer have been designed and installedin the Photon Factory 2.5-GeV Electron Linac at KEK . The
design concept of the controllers is to realize a reliable system
and good productivity of hardware and software by using an
industrial personal computer and a programmable sequencecontroller. The device controllers have been working reliably
for several years.

I. Introduction
Operators of the Photon Factory 2.5-GeV Electron
Linac (PF Linac) were required to reduce the beam tuning time
for starting up; therefore, detailed infonnation concerning theaccelerator was necessary in order to understand the behavior of
the linac. New device control systems, including slit
controllers of the beam energy analyzing system and electron
gun controllers for the PF Linac, have been installed for
improving the operational perfonnance, such as monitoring
the electron gun and beam parameters, since 1989.1)
If we consider the configuration of a device controller
for an accelerator, combining a personal computer and a
programmable sequence controller (sequencer) is the bestsolution. This is because they have the advantage of low-costand good productivity for a device controller. Furthennore,
they are now very popular and reliable, and have many cheap
circuit boards and extension units as a digital/analog 1/0. A
personal computer complements some of the functions of asequencer, such as the display of data and the management of
data/program file. For this reason, industrial personal
computers (NEC FC-9801 V) and sequencers (OMRONC200H) were employed for the device controllers. The FC9801 V has been improved in reliability, compared with theusual personal computer, like the PC-9801, and can run on
BASIC encouraging non-expert programers. On the other
hand, the sequencer has also been improved regarding its
immunity to bad environmental conditions.
For connecting the device controllers to the PF Linac
control system, a communication board with a CPU wasdeveloped so as to be used in the industrial personal computer.
The board separates communication tasks from the main CPU(CPU of the industrial personal computer}, and effectively
increases the system reliability.
In this paper, we describe the electron gun and slit
controller systems according to the above-mentioned idea, andgive a brief description of the PF Linac control system, sincethese device controllers act as a front-end of this control
system.

Operator'• Conaolo
Subayateni

Worlaltation
1!14ain-conaolo

atationa

MEI.COM
70/30

MBLC OM
70/30:i.DC3000-II(Oatoway)

Btbernet-TCP/IP
Dem:nCunent
MonitorSubayatem

Devicecontrollers

Fig. 1

Block Diagram of the PF Linac Control System

S11LLC02
378

Low-Level Controls
378

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC03

High accuracy ADC and DAC systems for accelerator
control applications.
E.Kuper, A.Ledenev
Institute for Nuclear Physics,
Novosibirsk, 630090, USSR
Abstract~n the work presented here the ways of
construction,
the apparatus for the precision
measurements and control systems incorporated in theaccelerating facilities of INP are considered. All theapparatus are developed and manufactured in thestandard of CAMAC.

of
precise components at a practically arbitrary
resolution, high linearity, easily achieved the galvanic
isolation of the analog part and consequently, a low
price.

-

Outputof'--__,.---' DAC

Introduction
ReferencesourceWhile carrying the experiments on the precision
measurements of the mezon·masses on the installations
with the electron - positron colliding beams one has touse the apparatus of a class 0.001 % with theRectifierresolution about 0.0001 %. An instability of the main
Voltageandconverter
stabilizer....._________.
power supply sources of magnetic systems of storagerings should not exceed 0.002%.
The powerful RF generators, the controlled sources
Fig.I. The analog section of PWM-DAC.
of power supply with an output power of a few
hundred kilowatts, pulse components of electronOne of the popular developments of INP is an 8optical channels, numerous digital devices including~hannel code-to-duty factor converter (CDFC) locatedcomputers are the sources of different kinds of noises.
. m the crate and transferring the control signal toUnder these conditions, the stronger requirements on
DAC - PWM integrated directly to the control objects.
the noise damping are posed to the measuring and
The DAC ~ignals in the form of different polarity
control equipment and to the analog data transfer
pulse, the distance between carrying the data onlines.
reference voltage for control system are transferred'
In the power supply system of the facility VEPP-4
through the coaxial cable with the transformer deone has to measure of about two thousand points andcouplin~ to ~he distance of up to 500 m. The simplified
to form the control signals for more than 500
schematic diagram of the converter is given in Fig.1.
channels. The time of energy rise is of ·a few tens of
The pulsed signals from DAC arrive at the trigger
seconds. In the mode of operation one needs the highcontrolled by the analog switches. The PWM
accuracy matching (0.1 % - 0.01 %) in the field variation
modulated signal is filtered with the RC filter of thein the magnetic components of accelerators. The
3rd order. In order to match it with the control systemtechnical parameters of the control and measuring
the error signal amplifier (ESA) is envisaged which
structures should provide the operation of the power
equalizer the DAC output signal to that from the
supply systems both in the static and in dynamic modes
current or voltage sensor. The galvanic de-couplingof operation.
on power supply is performed with the help of highfre~uency conve~t~r with the transformer of special
Digital - to - analog converters
design with the mimmum crossing capacitance. DAC
parameters are: 16 bites, error - 0.01 %, settling time Usually, the power supply sources of the storage
0.4 s, temperature factor of the output voltage ring facilities requires the digital-to-analog converters
0.0003%/K. The given configuration is being widely(DAC) of quite a low fast action at an accuracy
used in the systems of pulse power supply of theranging from 0.1 % up to 0.001 %. Therefore, most oftransport channels for charged particles, in the power
the converters used are designed on the base of the
supply sources for the "high current" correctors, i.e. inpulse width modulation PWM. The advantages of thethecontrolled objects arethose cases,
where
given type of DAC are well known: the minimum
distanced considerably and their groundings are=3 Ic

S11LLC03
382

Low-Level Controls

382

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC04

Driving Serial CAMAC Systems from VME Crates
W. Heinze
CERN 1211Geneva23

Abstract
Large control systems in the 80's were often based on
Serial CAMAC loops driven by 16 bit minicomputers. These
16 bit computers, becoming obsolete in the 90's, areadvantageously replaced by VME crates. To maintain theinvestment in Serial CAMAC hardware and software, an
inexpensive Serial Highway Driver has been developed which
operates in a VME crate as simple I/O module. With thissystem, both classical configurations, i.e. the Highway Driveron the I/O bus of the minicomputer and the Highway Driverin a so-called CAMAC mother crate, can be replaced withminimal costs and improved performance.
This paper presents a VME Serial CAMAC Driver andcompares the performance of the VME driven Serial Highway
to the ones driven by minicomputers. The comparison is basedon the experience gained with the beginning of thereplacement of Norsk Data minicomputers by VME crates in
the CERN/PS control system as described in [1].

I. INTRODUCTION
The control system of the CERN Proton Synchrotron
complex (PS) is at present based on Norsk Data 16 bit
minicomputers which control 26 Serial CAMAC loops
connecting approximately 240 CAMAC crates to drive theaccelerator equipment. The rejuvenation of the PS control
system starts with replacing the minicomputers by VME
crates, called Device Stub Controllers {DSCs). The VME
computing element is the MVME147 module, performing not
only the tasks of the minicomputers but also executing thereal-time tasks of the currently used Auxiliary Crate
Controllers (ACCs).
The interface between the accelerator equipment and
CAMAC has to be maintained for another some 10 years justbecause the investment in terms of money is so high. This

was the reason to develop an inexpensive Serial CAMAC
Highway driver as a VME module (abbreviated as SDVME).
The first series of 20 SDVMEs have been assembled at CERN
but the module is now also fabricated by a major CAMAC/
VME manufacturer (C.A.E.N., Viarregio, Italy).

II. DESIGN OF VME DRIVEN LOOPS
The actual Serial CAMAC loops will be rearranged into
smaller loops. Every loop is then controlled by one DSC. The
new loops consist of up to about 10 CAMAC crates, thenumber depends on the necessary computing power to control
the associated equipment because the CAMAC crates do nothouse computing elements (the ACCs) anymore. They are notmore than simple input/ output devices.
In the present control system, 2 types of CAMAC Serial
drivers are used which are now replaced by the SDVME: oneon the I/O bus of the minicomputer and one in a CAMAC
crate which in turn is driven by a dedicated CAMAC Branch
driver. Especially for the latter case which is used in 22 (outof the 26) loops, a considerable overhead of CAMAC
equipment and cabling is avoided thus improving reliability,
maintainability and equipment access times.
In general, the transmission speed on the Serial Highwayof 2.SMbit/s, bit serial, is maintained. Bit serial transfer
permits to continue to use U-port adapters reducing thenecessary number of twisted pairs in the Highway cable from4 to 2 (one for the command, the other for the reply part) andallowing loop reconfiguration. Figure 1 shows the standard
configuration. For special cases (instrumentation), thetransmission speed is selected to SMbyte/s, i.e. byte serial.
This is not a problem because in these cases, normally only
one CAMAC crate is controlled by a DSC, and the distance isvery short.

VHE driver crate

CAMAC Serial Highway

CAMAC

CAMAC

[I8l turn around connectors
Figure 1. Standard loop configuration

S11LLC04
386

Low-Level Controls386

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Fast Automatic System for Measurementsof Beam Parameters of the MMF Linac
P. Reinhardt-Nickulin, S. Bragin
N. Ilinsky, Yu. Senichev
Institute for Nuclear Research
Moscow, USSR

Abstract
Fast transverse beam profile and current monitoring systems have been tested at the Linear Accelerator of Moscow
Meson Factory. The signals for each system are derived
from multiwire secondary emission chamber and beam current transformer. Each beam pulse is digitized by fast
ADC's. There are two modes for systems. First one isfor detailed beam adjustment and second one is for normal 100 Hz rate of the MMF Linac. Essential featuresof the hardware, software, data acquisition, measurement
accuracy and beam results are presented.

1

Signals from multiwire chamber [2] and current transformer ( Fig. 1 ) are treated through specialized set ofmodules and standard CAMAC modules. This set forms
flexible enough complex of equipment, organizing the work
as with objects placed near computer as with remote ones.

,----------1
I CT

MWC

I
I

,

I
I M-t

I

Introduction

Systems for automatized measurement of beam parameters are components of general control systems of accelerators. Just through computerized measurement systems
feedbacks enveloping accelerator completely or partiallyare closed [l]. Application of measurement systems permits first of all to make effective tuning of beam parameters such as transverse sizes, emittance and so forth, and,secondly ( and it may be the most important) to reduce effects of radiation induced by the beam. This makes essentially easier exploitation conditions and conditions of tuning works, because for getting needful information about
the beam it is necessary to spend essentially lesser beamtime. Supposed installation in spaces between resonatorsof the first part of the MMF Linac measuring assemblies,
consisting of multiwire electrodes, phase analyzer and target for energy estimation must solve tuning problems to aconsiderable extent.
In this paper it is considered principles of construction
and main features of data treating systems, which permit
to get as simple transverse profile of each whole beam pulse
in usual exploitation regime as detailed picture of evolutionof transverse profile and intensity for single beam pulse,
and on the base of this information to estimate mutual
influence of neutralization process and Coulomb's repulsion. Besides that high registration speed of profiles andintensity gives the base for hope on getting more full information needful for tuning of accelerator resonators by the
beam.

Figure 1: Simplified block diagram of beam parametermeasurement system.

2

Speed criterion

Taking into account, that there will be approximately 650
analog signals from the wires placed in proton transfer
channel (transfer channel is placed between injector andfirst accelerating resonator) and in spaces between resonators, it is easy to see, that detailed digitizing of thesedata by means of separate ADC for every wire is not simple
and very expensive way. Therefore construction of systemshould be made by traditional way of storing and multiplexing of analog data. And criterion of information detailing one must search being attached not only to speedof ADC and computer, but mainly to physical processes

S11LLC05
Low-Level Controls

389

389

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S11LLC05

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Beam Position Monitor Multiplexer Controller Upgrade at the LAMPF
Proton Storage Ring*
W. K. Scarborough and S. Cohen

Los Alamos National Laboratory
Los Alamos, NM .llSA..87545
many off the shelf components as possible. The newcontroller needed to be as "plug compatible" with the oldcontroller as possible, so that no modifications to othercomponents of the multiplexer system were necessary.

Abstract
The beam position monitor (BPM) is one of the
primary diagnostic tools used for the tuning of the proton
storage ring (PSR) at the Clinton P. Anderson Meson
Physics Facility (LAMPF). A replacement for the existing,monolithic, wire-wrapped microprocessor-based BPM
multiplexer controller has been built. The controller has beenredesigned as a modular system retaining the samefunctionality of the original system built in 1981. Individual
printed circuit cards are used for each controller function to
insure greater maintainability and ease of keeping a spare parts. inventory. Programmable logic device technology has
substantially reduced the component count of the newcontroller. Diagnostic software was written to support thedevelopment of the upgraded controller. The new software
actually uncovered some flaws in the original CAMAC
interface.

_...camn_

I IN1RODUCTION

NW..CGSK»lll. - - - - .

Tll,llN3PUt.SE

The Beam Position Monitor (BPM) system is theprimary tool available for beam tuning at the Clinton P.
Anderson Meson Physics Facility (LAMPF) Proton Storage
Ring (PSR). The BPM multiplexer controller is an integral
part of the BPM system. The multiplexer controller is theinterface between the BPM[l) system hardware and the PSR
microVAX data acquisition and control system, see Figure I.
There are approximately seventy BPM's that are used as a
primary tuning tool by PSR operators.
The existing multiplexer controller was difficult totroubleshoot and repair. The old controller was built on 12
wire-wrap "CASH" cards mounted in a 19 inch rack mountchassis. A spare controller chassis was never built, making online troubleshooting to the component level necessary.
The analog to digital converters that were used in theoriginal design are no longer available. It should be noted thatconversion must occur with in the time constant of thecirculating proton bunch in the ring, 360 ns.
In addition, there were no software diagnostic tools to
aid in troubleshooting and testing.
Several factors affected design of the new controller.
Programmer resources were not available to write code for amore modem microprocessor so we needed to do an Intel 8085·
based design and reuse as much of the 3000 lines of original
assembly code as possible. The new controller needed to bemodular so that "card swapping" could be used as atroubleshooting and repair technique. We wanted to use as*Work supported by the US Department of Energy

l!INAllYDATA---·••••...

Figure 1. BPM System Block Diagram

We elected to do the project in a STD bus format.
STD bus is a mature, well defined, well supported industry
standard. The STD bus standard was designed for 8-bit
microprocessor control functions, and several vendors offer
8085 CPU cards. In addition, several vendors offer well-built
chassis with terminated back planes.

II. CONTROLLER FUNCTIONSWhen the BPM control software running on PSR
microVAX needs data, it sends a command/request list via
CAMAC, to the controller. The request defines whichchannels are to be read, number of samples per channel, andtiming information. The command list is loaded into a
CAMAC output FIFO(First In First Out buffer) and thensignals the multiplexer controller, via a CAMAC TIL output
module, that the FIFO is loaded and ready to be read. The
controller reads the FIFO, stores all the command/request
infonnation in RAM.
The controller takes a number of actions prior toactual data acquisition. It must first select the channel and areamultiplexer that corresponds to the BPM whose position
information has been requested. The controller writes to atiming chassis to set up trigger and timing parameters and it
writes to the analog signal processor chassis to set gain and

S11LLC06
Low-Level Controls

393
393

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S11LLC06

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The KEK PS Fa,st Beam Loss Monitor System
J.A. Holt°, J. Kishiro, D. Arakawa, H. Someya and S. Hiramatsu
National laboratory for High Energy Physics, KEK
1-1, Oho, Tsukuba, Ibaraki, 305, Japan
Abstract

The higher beam intensities now being accelerated in
the KEK proton synchrotron (PS) complex have increased
the importance of observing the beam loss during accelera­tion. The beam loss should be continuously monitored tominimize radiation damage to the accelerator components.
A fast loss monitor also is a good tool for observing where
and when the beam is lost, by which we are able to get
information on the beam dynamics. The development of afast beam loss monitor system at KEK is described in thispaper.

a 750 KeV Cockcroft-Walton, a 40 MeV linac, a 500 MeV
Booster and the 12 GeV main ring. There is a transport line
between the linac and booster and another line between the.
booster and main ring. One detector was placed near the 40
Me V transport line, eight detectors were placed around thebooster, one detector near the 500 Me V transport line andtwo detectors in the main ring. The detected signals weredigitized by fast CAMAC ADCs and acquired by a VME
computer for analysis and display. The control and display
software was written using X-windows under UNIX. This
enabled simultaneous display of multiple detector signals
and the ability to display the data on any X-terminal on the
network.

I. INTRODUCTION
The beam intensity in the KEK PS has gradually increased
and the PS continuously is operated with an intensity of
about 3x1012ppp. There are, however, some problems inmaintaining this intensity in the accelerator and in the beamtransport lines. The beam loss might come not only from a
miss steering of the beam orbit but also from the short timescale dynamical behavior of the beam bunches. One property
of a loss monitor which should be noted is the extremely
high signal to noise ratio. In the usual beam monitor
systems, the signal is proportional to all of the particles inthe bunch. Any loss causing perturbation signal due to someshort time behavior of the particles has to be extracted fromthe signal fluctuation. In a loss monitor, only the perturbed
Figure 1. Time response of the detector.
signal is seen.
We have adopted at KEK a secondary electron multi­
plier vacuum tube as a beam loss detector because of its
II. HARDWARE CONFIGURATION
good time response, compactness and ease of handling. The
time response was tested in the TRISTAN electron-positronstorage ring which has a bunch length of 300ps. The tube A. Detector
response was quite good, about 40 ns (Fig 1). This time
response is good enough to enable turn by turn beam loss The detector is a secondary electron multiplier tube R595
monitoring of an individual bunch in the proton synchrotron made by Hamamatsu. The gain of the detector is around 1a5
complex.
- 107. Since the PS loss rate is very high, the tube gain is
As an initial test, thirteen detectors were distributed more than enough. The tube is installed into an aluminumaround the accelerator complex. The PS complex consists of case for light and noise shielding. Attached to the back of•Presently at FNAL, Batavia, IL, U.S.A

S11LLC07
Low-Level Controls

395
395

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S11LLC07

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC08

NON-DESTRUCTIVE FAST DATA TAKING SYSTEM
OF BEAM PROFILE AND MOMENTUM SPREAD IN KEK-PS
T.KAWAKUBO, E.KADOKIJRA, T.ISHIDA~ Y.AJIMA AND T.ADACHINational Laboratory for High Energy Physics, 1-1, Oho, Tsukuba-shi, Ibaraki-ken, 305, Japan•Mitsubishi Electric Company, 1-7-4, Iwamoto-cho, Chiyoda-ku, Tokyo-to, 101, Japan

Abstract
A mountain view of beam profiles in a synchrotron

The VME computer system takes data from thosering can be taken without any beam destruction by col-sensors via an A/D converter, rearranges them and dis-lecting charged particles produced by the circulating

plays a "mountain view" of the transversal beam profiles

beam hitting residual gas in the ring to a sensor. Whenas well as the time dependence of the beam (center, size,a recl;mgular Micro Channel Plate with multi-anodes or

momentum spread) within one acceleration period.

lined-up electron multipliers is used as the sensor, theprofiles can be measured within one acceleration period,

2. NON-DESTRUCTIVE PROFILE MONITOR

even if the beam intensity is very low and the ring is kept

SYSTEM AND DATA-TAKING METHOD

in a high vacuum. We describe this non-destructive pro-file rnonitm (N DPlvr) i':.s well ZL5 the momentum spreadmeasurement system by a combination of two sets of
NDPM.

A.Mechanism and electric circuit
A circulating beam in a synchrotron strikes residual
molecules in the vacuum ring while producing positive
ions and electron pairs with some probability. WhenL INTRODUCTION

II is very convenient for bec'.m studies and mi~d1ine
operation to m·~asure the beam profile in a synchrotron
ring without causing any damage to the circulating beam.
The principal of the non-destructive beam profile monitor (NDPM) is to measure the position der,endence ofthe positive ion curri:nt produced by Lhc circuiating pr.:"i-ton beam in a synchrotron ring. Since the curr€Ilt signal
is very low, we usually use an element to amplify thenal, such as a. micro-channel plate (MCP) or an electron
multiplier (EM). We had installed two sets of NDPM byusing c\ large rectangular area MCP with 32 anodes 1 l,
one of which measures the horizontal beam profile in the
Booster ring and another in the Ivfain ring. For setting
NDPM at a ring position with a large beam size, using

a positive collecting voltage is supplied to an electrode(as shown in Figure 1), positive ions move from the hottom t.o the top along the collecting field. If a large-area
rectcmgular MCP with multi-anodes or lined-up EMs
are phced at the end of the field, they can measure

the number of ions which are produced in proportion to
the beam intensity along the vertic<<l collecting field. In
our case, the MCP is a tandem-type and has an effective ;;.rea of 81mmx31nun; 32 anodes (each anode hasa width of 1.5mm, a length of 29mm a.nd a pitch of
2.5mm) are placed closed to the output side of the surface of the l\WP. An EM-type NDPM has 30 lined-up

Ei\fs, in which every E1vI has an aperture with a widthof 5.2mm and a length of 30mm. Every anode of the

MCP or EM has an independent electric circuit (shownin Figure 2).

a.n assembly of many EMs as a sensor, is better thanusing a MCP, from the view point of long life against
radiation and a high saturating signal current 2 ). A combination of two NDPMs (one of which is made of EMs
and set at the place with a large dispersion function;
the another is made of MCP and set at a location witha srmtll dispersion function) is used for measurementsof the momentum spread•. We introduce this measurement result in the Main ring.

•The authors would like to acknowledge Dr.K.Narushima., Mr.
T.Ku bo and Mr.Y.Sa.toh for helping us to install NOP Ms in thevacuum cha.mber.

S11LLC08
Low-Level Controls

399

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC09

A CAMAC-Resident Microprocessor For The Monitoring Of
Polarimeter Spin States.
David Reid, Derek DuPlantis, Neil Yoder
Indiana University Cyclotron Facility
2401 Milo B. Sampson Lane, Bloomington, IN 47405
Don Dale
TRIUMF
4004 Wes brook M af4 Vancouver, B. C. Canada V6T 2A3
Abstract: A CAMAC module for the reporting of polarimeter spin states is being developed using a resident
microcontroller. The module will allow experimenters at the Indiana University Cyclotron Facility to monitor
spin states and correlate spin information with other experimental data. The use of a microprocessor allows foradaptation of the module as new requirements ensue without change to the printed circuit board layout.

I. Introduction
A custom CAMAC module has been developed toallow for the remote monitoring of polarimeter spin statesin the Indiana University Cyclotron Facility . The module
will prm-ide experimentalists at the facility with data on spinstates of the particle beam and allow them to correlate
experimental data with this information. The cyclotron
control computer sets the polarized ion source by means ofa task which also acts as a network multi-node server,
providing spin-state data to client tasks on one or more dataacquisition computers, each of which will copy current spinstate data to the module. The standard data-acquisition
programs will access the module while reading other event
data.

II. Module Functionality
To meet the experimental demands outlined above
the module has two eight bit registers for holding thepolarimeter states. One register holds the current state andthe second register holds the latched state. Most data-taking
events read the current state register. For certain CAMAC
commands the latched state is read and the current state is
moved into the latched state register.
The experimentalist's interface to the module isthrough seven output LEMO connectors on the front panelof the module. Three connections give the spin data. One
connection gives information on what type of particle(proton/deuteron) is being accelerated through thecyclotron.. A ready bit, an interrupt bit, and a valid bit arealso brought out to the front panel.
A sixteen bit timer countdown register is used in themodule. This register counts down in 0.1 second units. This
register is loaded by a CAMAC write operation and begins
counting down immediately upon being loaded. When the
countdown register makes the 1 - > 0 transition the module,
current state register, and the valid outputs are cleared.

A sixteen bit sequence number register holds
polarization cycle sequence number to permit correlation of
event streams from different data acquisition computers.
The sequence number register is specified by the dataacquisition computer and wTitten to the module.

III. Module Components
i. Microcontroller
To meet the functionality requirements for themodule it was decided to use a resident microcontroller.
The use of the microcontroller will allow the module to meetthe current specifications and give additional flexibility tomeet future
demands. By using a microcontroller themodule c'an be readily adapted to future uses without the
costly printed circuit board redesign that would result fromthe use of logic circuitry.
The microcontroller that was chosen for this projectis the Intel 80C196KC. The chip has a si>.teen bit wide
internal data bus. Because the registers for the module are
specified to be eight or sixteen bits wide the internal data
bus for the chip allows for direct, full width register
operations. [1]The module can perform complete operations
before the next CAMAC cycle due to a 16 MHz clock.[2}ii. Extemal Memory
The 1% can take advantage of external memory
devices. This features makes the use of external ROM and
RAM onboard the module possible.
The module uses three external memory devices.
Two 8K x 8 EPROMs are used to hold the code for the
microcontroller. The micro controller accesses the code for
its internal operations from the EPROMs. Two chips areused in parallel to allow for sixteen bit wide memory words
to be used.
Two 8K x 8 RAM chips are used for external
memory register space for the microcontroller. For thefunctionality of the module as now specified this additional

S11LLC09
Low-Level Controls

403

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC10High accuracy measurement of magnetic fieldin pulse magnetic elements
V.Kargaltsev, E.Kuper
Institute for Nuclear Physics,
Novosibirsk, 630090, USSR

Abstract
CAMAC module intended for measurements of
instant magnetic field using coil sensor is described. It
is four channel integrating ADC with current input inwhich signal integration time is controlled externallyand may be optimized for a given signal. Originaltechnical solution allowing to eliminate influence of theintegrator capacity and switches instability on overall
accuracy is described.
The large accelerator facilities include a great
number of magnetic elements interacting with a beam
for a short period ranging from 0.01 ms to 10 ms. For
example, this class of elements includes all themagnetic
components
of channels for particle
transportation. In addition, most of these elements areoperating rarely - once in 1 - 10000 s. For theseelements the most optimal is the use of a pulse power
supply that reduces the electric power consumption andwhich is most important, it solves the problem ofheat removal. Though, the pulse power supply posessome problems in providing the accuracy of magnetic
field and its measurements.
In practice, the measurement problem can be
reduced to the measurement problem of instantaneous
value of the magnetic field. In fact, the time of thebeam-field interaction is usually so short then thefield can be taken quasistatic and acting equally on all
the portions of a bunch of particles.
There are some elements interacting with a beam fora long time during which the field can be changed
substantially. For example, the cyclic accelerators
operate in the similar way. But the pulse shape in theseelements is determined by the properties of the feeding
generator and it is very conservative. The shape
relevance can be checked by the point by point
measurements while development of such an elementand during the operation it is sufficient to control one
or two characteristic points (instantaneous value) of apulse. Usually, the values are measured whichcorrespond to the beginning and the end of the fieldinteraction with a beam.
The inductance sensor proved to be very convenient
for the pulse measurements. It can easily allow theshielding and galvanic de-coupling from the facility
construction that facilitates substantially the problem
of producing the measuring devices.
The experience of operation of the faci1ities at

the Novosibirsk Institute for Nuclear Physics (INP) has
shown that at the requirements to the accuracy ofmagnetic field lower than 0.05% the tuning of'magnetooptic channel was determined by themeasurements of· fields with these sensors. At higher
accuracies one should take into account the deviations
between the field (flux) value measured with the helpof this probe and the properties of magnetic element
as a whole, which are caused by the magnetic
temperature variations and some other reasons.
While measuring the instantaneous value thefollowing approach seems to be natural: the field signal
is traced with the analog memory device, stored in thememory at the moment of interest and then it istransformed into the code.
c

In~
Sw1
Rref

--c:::J--o U<ef
Sw2

Fig.I. The analog section of module.

The use of the inductance probes enables one quite
simple to realize this process with the help of the analog
integrator. In fact, the signal voltage from theinductanceprobe
is proportional to the speed
variation of the passing magnetic flux:dol>

E = W-

dt
Here W is the number of turns of a probe.
If this signal is integrated by the analog integrator,
the charge stored in the capacity can be described asfollows:

tx

tx
dE

W

J di

W

JR
t

R

dt

R

q= - d t = --dt=-(~ (tx)-w (t ))
0

t 0
·
·
l'1m1ts· are given·b y th e
I n t h is case, t he integration
moments of connection (t 0) and disconnection (t ) of
the switch Swl. If the integration is started befor~ thefield pulse, the stored charge is equal to:'o

S11LLC10
406

Low-Level Controls

406

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC01

FEEDBACK -- CLOSING THE LOOP DIGITALLY
J. Zagel, B. Chase
Fermi National Accelerator Laboratory*
P.O. Box 500
Batavia, IL 60510
Abstract

closed loop configuration to evaluate fue response and stabilityof the system. For a closed loop:

Many feedback and feedforward systems are now using
microprocessors within the loop. We describe the wide rangeof possibilities and problems that arise. We also propose
some ideas for analysis and testing, including examples of
motion control in the Flying Wire systems in Main Ring and
Tevatron and Low Level RF control now being built for theFennilab Linac upgrade.

g_tl

G(s)

R(s)

G(s)

R(s) = (l+G(s)H(s))

11---"li"--P

c (s)

H(s)

I. INTRODUCTION

Figure 1. Basic Control System Terminology

The standard techniques used to design and analyze analog
feedback systems can also be applied to digital systems. It is
desirable to consider frequency response, maximum tolerable
error, and stability questions for systems controlled byprocessors. In modern digital systems a considerable amountof software not only replaces analog circuit functions but also
allows additional features to be built into the system.

II DEFINITIONS

A. Control System
A control system is generally described as a system U1atprovides an control output variable C in response to an input
reference R. This can be accomplished open loop or closed
loop. Open loop control means U1at for a given input, theplant G provides a fixed response regardless of any externalloading on the controlled device or process. Closed loop
control uses feedback signal H to compare the output to thereference input and generate an error E which is thenminimized by the loop.
A predictor of the desired output can be applied to thedrive circuit thus producing a feed forward signal. Predictions
are nonnally obtained by computations on a mathematicalmodel combined wifu measurements of the actual process.
The plant G can be viewed as the combination of fixed
drive characteristics plus an equalization, or compensation,filter applied to correct any undesirable behavior. The feedback
can be a simple transfer function, such as position to voltage,
or a complex filter to aid in measuring the controlled process.
An open loop system is described as the convolution ofr(t) with g(t) in fue time domain. It is more convenient toanalyze fuese systems in the frequency domain using Laplacetransforms. This transforms convolution integrals tomultiplication for continuous, linear systems, or C(s) = R(s) *G(s). With feedback, the transfer function is described for the*Operated by Universities Research Association Inc., undercontract with the U.S. Department of Energy.

B. PID Loops
The most common controller is fue proportional - integral- derivative loop (PID). To understand the PID loop we will
look at the pieces of a motion control system. When aposition change is required the reference input to the system ismodified. The system will generate a drive signal proportional
to the position error developed between the now changed
reference input and the previously held position.
For a step change in the reference input, the drive
electronics may allow the motor to far overshoot the desiredchange. In this case it is useful to consider the first derivative
term of the velocity, or acceleration, to maintain stability.
111is is also referred to as lead compensation.
To correct for long term or steady state errors in thedesired output a third, integral, term is included in control
loop. This term removes accumulated error over time. This isreferred to as lag compensation.
The mathematical formulation 1 for the PID filter in time
is: upm(t) = Kpe(t) + KJe(t)dt +Ka~
which transforms to:I
Upm(s) =KP+ Kr~·+ Kds= Kds2 + Kps + KisThis filter function has one pole at the origin and two
zeros that are dependent on the three gain tenns.

C. Hardware - Software Equivalents
To implement the PID equation above active elements areused. The hardware is shown in figure 2. Each term isshown as an independent active element however in practicethis circuit can be simplified.
While Laplace transforms take us into a convenientdomain to analyze analog circuit behavior, the z-transfonn
better serves the transition into sampled time domain.

S12FC01
408

Feedback Control
408

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC02

Generalized Fast Feedback System in the SLC*
L. Hendrickson, S. Allison, T. Gromme, T. Himel, K. Krauter,
F. Rouse, t R. Sass and H. Shoaee
Stanford Linear Accelerator Center, Stanford University, Stanford, CA 94309

Damping Rings
Existing Linac

I

e+ Target

e+ Return Linee+ Booster

Existing Linacs11"""91
7041A1Figure 1: Layout of the SLC with fast feedback loops shown. S = steering loop; E
control; C
special-purpose loop to maintain beam collisions; * prototype.

==

Ab.stract
A generalized fast feedback system has been developed
to stabilize beams at various locations in the SLC. The
system is designed to perform measurements and change
actuator settings to control beam states such as position,
angle and energy on a pulse to pulse basis. The software
design is based on the state space formalism of digital control theory. The system is database-driven, facilitating theaddition of new loops without requiring additional software. A communications system, KISNet, provides fastcommunications links between microprocessors for feedback loops which involve multiple micros. Feedback loops
have been installed in seventeen locations throughout the
SLC and have proven to be invaluable in stabilizing themachine.

INTRODUCTION
The SLAC Linear Collider (SLC) produces pulsed bunchesof electrons and positrons which are accelerated in a
"Work supported by Department of Energy contract DE-AC0376SF00515.
I Present address: University of California, Dept. of Physics,
Davis, CA 95616.

= energy control; I = intensity

LIN AC and steered around arcs before colliding at a single interaction point. The maximum beam rate for themachine is 120 Hertz. The SLC control system is based
upon a central DEC VAX 8800 and a series of Intel 80386
microprocessors (micros). The micros are distributed geographically, with each micro controlling the devices which
accelerate, steer and measure the beam in a region of
the machine. The VAX communicates with the micros
through a specialized network system, SLCNET, but withthe exception of this fast feedback system the micros do
not ordinarily communicate with each other.
The feedback system is used for controlling the energy,
trajectory and intensity of the beams. The system takes
measurements, calculates state functions and implements
corrections at a fast rate. It is designed to operate at thebeam rate but due to CPU limitations it operates at alower rate, typically 20 Hertz. Figure 1 shows the SLC
machine with currently implemented and planned feedback loops. Prototype feedback systemi;; were initially implemented in three locations for steering, controlling thebeam energy [1] and maintaining collisions [2]. These systems quickly became indispensable to the machine operation and an improved, database-driven system was developed to allow easy addition of new loops throughout themachine.

S12FC02414

Feedback Control

414

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC03

SMART MACHINE PROTECTION SYSTEM*
S. Clark, D. Nelson, A. Grillo, N. Spencer, D. Hutchinson, J. Olsen
D. Millsom, G. White, T. Gromme, S. Allison, K. Underwood, M. Zelazny, and H. Kang
Stanford Linear Accelerator Center, Stanford University, Stanford, CA 94309, USA
Abstract
A Machine Protection System implemented on the
SLC automatically controls the beam repetition rates in
the accelerator so that radiation or temperature faults
slow the repetition rate to bring the fault within tolerance without shutting down the machine. This process
allows the accelerator to aid in the fault diagnostic process, and the protection system automatically restores thebeams back to normal rates when the fault is diagnosedand corrected.
The user interface includes facilities to monitor the
performance of the system, and track rate limits, faults,
and recoveries. There is an edit facility to define the devices to be included in the protection system, along with
their set points, limits, and trip points. This set point andlimit data is downloaded into the CAMAC modules, andthe configuration data is compiled into a logical decision
tree for the 68030 processor.
INTRODUCTION
The Stanford Linear Collider includes a number ofsafety systems that shut down the Collider when unsafe
conditions arise. When the Collider shuts down, it becomes difficult to diagnose the cause of the problem. Often it becomes necessary to terminate the startup multiple
times before the problem(s) are corrected and safe continuous operation can resume.
Substantially more effective operation would result
from a safety system that would report the cause of thefault from the origin of the equipment trip, allowing safe,
lower repetition-rate operation to continue, so that the machine can be used to diagnose itself. Automatic return tohigher-rate operation after repairs speeds recovery and allows automatic handling of system glitches.

PROPOSED ENGINEERING SOLUTION
A new Machine Protection System (MPS) is being installed in the SLC that will improve machine protection
and utilization. The new system will continue to detectunsafe conditions on a pulse- to-pulse basis; however, it
will now rate-limit the machine to continue operation at
safe levels for diagnostic purposes. This new system utilizes stand-alone array processors to scan the set of fault
detectors (radiation, temperature, flows, etc.), making rate
limit decisions based on the type and severity of any detected faults, using machine configuration and parameter
limit tables developed by machine and radiation physicists.
Facilities have been included to support logging of all
machine state changes; the protection system forwards a
message to the control room explaining which input signal
faulted, and the nature of the fault. These processes allow operators to determine quickly and directly what the
problem is/was and what remedial action is required, witha data trail available for later analysis or post-event review.
Beam rate control will be hard wired into the Master Pattern Generator (MPG) and the Injector interlocks
used to control the accelerator, so that the machine canbe shut down if the expected rates are not properly executed. Failures of sensors or communications failures insensor processors are treated as if the associated device or
included devices where in a worst case failure mode, andappropriate action is taken.
HARDWARE IMPLEMENTATIONThe new system will be implemented as a loosely
coupled element of the SLC control system, with common facilities on the CAMAC side, new elements built
into VME systems, and integrated SLC user interface andapplications facilities. As shown in Fig. 1, the system will
Ethernet

m 1553

ElectronDamping Ring (NOR)
Injector Linac /9 + Target

Beam Direction -Figure 1.
MPS system architecture,

'\..

/

PosttronDamping Ring (SOR)
ControlRoom

11-111

7'045.t.I

Ethemel*Work supported by Department of Energy contract DE-AC03-76SF00515.

S12FC03
420

Feedback Control

420

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC04

FEEDBACK SYSTEMS FOR LOCAL CONTROL OF RACE TRACKMICROTRON RF ACCELERATING SECTIONS

Chepumov A.S., Gribov I.V., Morozov S.Yu., Shumakov A.V.,Zinoviev S.V.
Institute of Nuclear Physics, Moscow State University
119899, Moscow ,USSR.
Abstract.
In order to obtain an electron beam with an excellent
energy resolution and stable characteristics, a tightcontrol of the amplitude and phase of the field in all rf
accelerating sections is required. The high rf power level,
dissipated in the accelerating section (AS), together withtemperature dependence of the AS resonance frequency
caused the creation of the original control system ofresonance frequency. Amplitude, phase and resonancefrequency local feedback control system have been
designed. All systems are computer conrtrolled analogue
single loops. The cont~l loops guarantee stable,
repeatable amplitudes (1 o- relative error), phases (+/0.5°) of the rf fields in AS, resonance frequency of AS (+/2 kHz ) and have optimal bandwidth. A model of
feedback loops has been developed that agrees well withmeasurements.

local feedback systems. It is possible to select theoperating points of the respective phase detectors withthe aid of phase shifters PS2 and PS3. Adjusting phaseshifters are made as microstrip devices in the form of ameander line on the ferrite layer. They are current
controlled, but it is possible to set phase shifters once byspecial bipolar current pulse train due to the hysteresis

R
F

I. INTRODUCTION.
The control systems of rf power supply system of theaccelerating sections of the continuous wave (CW) racetrack microtron (RTM) are described in this paper. Thesesystems operate in different parts of the frequency domain
and are connected with each other by control parameters.
The described systems ensure constant rf parameters of
the AS, such as rf power, resonance frequency and phasedifference. These systems form the bottom level oftheRTM hierarchical computer control system (CCS) [l ].
All analog systems are completely controlled by the top
level of the CCS trough optocoupled devices. It is possible
to change operating modes and reference signals for
feedback control systems by an order from the top level of
theCCS.

II. RF SYSTEM.
An outline of the rf power supply of the AS, which is apart of the general rf power supply system of R TM, isillustrated in Fig.1. In an operating mode, a reference rf
signal of 2450 MHz (RS) passes over a microstrip rf
channel to the klystron input port. The output power of
the CW klystron is about 25 kW. The RS is stabil!zed infrequency up to 1 KHz and in power up to +/- 10- • The
klystron is connected to the AS by a waveguide throughthe circulator, vacuum window and vacuum port. The
incident and reflected waves are checked by means of
the double directional coupler (DC) and diode detectors
D1 and D2 . A signal from the rf probe, located in the AS
rf power input cell, passes through a 4-channel power
splitter to the sensors of amplitude, phase difference, andAS resonance frequency: the detector D3, the phasedetectors PD1 and PD2, respectively. The voltage controlled microstrip pin-attenuator A1 and current controlled phase shifter PS1 are used as the controllers in the

L

0
0

p
To amplitude
feedback loop

To phase feedback loop
Fig. l Outline of rf power supply of accelerating
sectionproperty of ferrite. Phase shifters are controlled by theorder from the CCS with electron module. The module
consists of a relay multiplexer, voltage to current
converter and single channel DAC. All necessary rf
parameters, such as incident, reflected waves and internal
rf field, phase shifts, are measured by the CCS throughoptocoupled ADC. These signals are amplified andnormalized by circuits of analogue feedback control
systems.

Mode of power feeding.
The rf feedback loop is closed by the rf switch (SW) in
the mode of power feeding into the AS. Constant phaseshift and gain of rf feedback loop guarantees amplification

S12FC04424

Feedback Control424

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Feedback
J.Y. Huang, Jinwon Lee, M.K. Park, J.H. Kim and S.C. Won
Pohang Accelerator Laboratory,
POSTECH, P.O.Box 125,
Pohang 790-600, Korea

Abstract

A real-time orbit correction system is proposed for thestabilization of beam orbit and photon beam positions
in Pohang Light Source. PLS beam position monitorsystem is designed to be VMEbus compatible to fit
the real-time digital orbit feedback system. A VMEbus
based subsystem control computer, Mil-1553B communication network and 12 BPM/PS machine interface units
constitute digital part of the feedback system. With thesuper-stable PLS correction
power supply, powerline frequency noise is almcst filtered out and the dominantof beam obtit fluctuations are expected to appear
below 15H z.
DSP board in SCC for the computation and using an appropriate compensation circuit for thephase delay by the vacuum chamber, PLS real-time orbit
correction system is realizable without changing the basic
structure of PLS computer control system1 .
I. Introduction
In an electron
various kind of beam orbit
disturbing sources exist, e.g., power line drift and rippleinpower supply, magnet and girder deformation
temperature
low frequency vibrations frommechanical vibrations of compressors, etc. When thesesources are coupled with strong focusing magnets, beam
orbit stability is severely deteriorated. Measurement on
the spectra of beam position fluctuation shows that thedominant beam position fluctuation appear in the range
0 ,..., lOOH z[l]. In the third generation synchrotron radiation source, stability of the beam orbit is very sensitive
to the noise sources. Many beamline users also requirevery stable photon beam source, i.e., stable within a small
fraction of the beam size. Considering the photon beam
sizes from Insertion Devices(ID), beam orbit should be controlled within a few µm.
Pohang Light Source(PLS) is designed as the lowemittance synchrotron radiation source[2]. The magnet lattice is 280m long, 12-period Triple Band Achromat(TBA) structure. Results of beam dynamics simulations show that dynamic aperture of the circulating beam
is much reduced by the closed orbit distortion[3]. Without
1 1 Work supported by MOST and POSCO

correction of the orbit distortion, even a single turn orbit
may not be closed, i.e., the beam may have no dynamic
aperture. In the PLS, effect of all position errors should
enter within 150µmrms. For these reasons, a real-time orbit correction system and local beam steering system foreach ID bea.i.-nlines are forseen for the Pohang Light Source.
PLS computer control system has a four-layer hierarchical structure with distributed control computers and comscalemunication networks; a host computer for thecomputation and central database, console computers forsubsystem conthe user interface to the control
trol computers(SCC) and machine interface units(MIU)[4].
Console computers and SCC are connected by Ethernet.
SCC and MIU are connected by Mil-1553B data communication network.
PLS Beam Position Monitor(BPM) is designed as VXIbus modules to fit to the digital closed orbit correction
system. All the g BPM detector electronics and 6 H/V
correction magnet power supply(PS) control modules in a
lattice period are designed to be VMEbus-compatible andare housed in a single VXIbus crate. Utilizing those VMEbus based BPM system and high performance PLS computer control system, a fully digital orbit feedback
is under development. A dedicated SCC and 12 BPM/PS
MIU's constitutes the real-time closed orbit correction sys·tem.
There a.re some practical limitations in realizing the realtime orbit feedback system. Time delays for digital data
communication and computation, and phase delay
eddy
current effect of the thick aluminum vacuum chamber limit
the feedback frequency range below 15H z. One of thebiggest noise sources from power line ripples is almost filtered out in the design of PLS correction magnet power
supply. Therefore, major orbit noises are expected to appear below 15Hz in the PLS storage ring.

II. Beam Position Monitoring System
The most important role of the PLS beam diagnostics
will be the accurate and fast measurement of beam position for the stabilization of the beam orbit to meet thestringent low emittance lattice design and experimental
user requirements. For this purpose, the state of the art
beam position monitoring system, featuring measurement

S12FC05
Feedback Control

427
427

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S12FC05

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

A Position Feedback Control System for the Test Facility of JLC
N.Ishihara
National Laboratory for High Energy Physics(KEK)
S.Nakabayashi, K.Yasuda, K.Ishihara, T.Kubota
Kawasaki Heavy Industries,Ltd

Abstract
In order to develop an alignment system for the Japan
Linear Collider(JLC), we have constructed a test facility to
study the position control system with multiple degrees of
freedom for massive load. Noticeable points of the test facility
are as follows.
(!)Feedback fine alignment system which consists ofpiezoelectric actuators and laser interferometers.
(2)High-speed controller using Vl\.1E modules.
(3)Level positioner driven by stepping motors.
The controller can easily be connected with othercomputers by using RS-232C or Ethernet, so that their statessuch as positions can be monitored by another computer
system. This facility achieves the alignment of multi-degrees
of freedom with the accuracy of the order of submicron.

I. INTRODUCTION
It is commonly recognized that a submicron alignment
system will be required for the final focusing magnets of the
future e+e- collider. As found in recent study, JLC beams at
the interaction point will be as small as 1.4 nm in vertical and
230 nm in horizontal to have enough luminosity [l]. On theother hand, ground motion of the order of 100 nm is expectedeven at deep underground and the vibration due to the coolingwater pulsation is also expected. Therefore we must keep themagnets stable against the vibration and we are considering torealize the magnet position stnbility by means of a feedback
control, called the active alignment [2].
We have constructed a test facility for a 1.5 t magnet The
facility achieves the fine active alignment of five degrees of
freedom with piezoelectric actuators. It also has the level
positioners of six degrees of freedom as the coarse movers. In
this report we will describe the test facility and its control
system.

Fig. I Schematic illustration of the test facility.

IL TEST FACILITY
The test facility is schematically illustrated in Fig. I and its
photograph is shown in Fig.2. The magnet support table isdesigned to have enough stiffness (the least natural frequency
is above 100 Hz) so that it keeps its own shape unchanged
under the usual vibration. The magnet support table issupported by eight piezoelectric actuators (four for vertical andfour for horizontal) and the whole active alignment unit is
supported by four level positioning units driven by stepping
motors.

Fig.2 Photograph of the test facility.

UL CONTROL STRATEGY AND SYSTEM
Each level positioning unit has a function of three-axis
positioning. Each axis has an absolute linear gauge of 1 µm
resolution. With a cooperative move of the four level-

S12FC06
Feedback Control

431
431

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S12FC06

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC07

RF Control System of the HillAC Synchrotron
11.Kanazawa, K.Sato, A. I tano, K. Noda, E. Takada, 11.Sudou, Y.Hirao,
T.Ya1aagishi*, II.Shigeta*, N.Tsuzuki*, C.Yamazaki*, E.Toyoda*, T.Yagi*, Y.Morii*
National Institute of Radiological Sciences, Acc. Res. Division, 4-9-1 Anagawa, Chiba 260* Toshiba corporation, 1-1-6 Uchisaiwai-cho, Chiyoda-ku, Tokyo 100
synthesizer (Stanford Telecommunication, STEL-1375a) has
been adopted for the HIMAC RF control system (See Fig.I). Beam monitors of position (.6.R) and phase (.6. ¢ ),which can be used with wide beam intensity range, havebeen developed also. This .6. ¢ monitor must have fast
response to use for .6. ¢ feedback I oop which daap thesynchrotron oscillation. We have checked the .6. ¢ feedback loop with the developed simulator circuit in a factory. In the test 11ith the simulator, we found that the.6. ¢ feedback loop could damp the simulated synchrotron
oscillation of frequency up to 6kHz. This result is goodenough, because the maximum frequency is 4kHz in the
HIMAC synchrotron. As a next step of the test, we have
tried to accelerate the beam by use of the developed RF
control system.

Abstract
An RF control system of the HIMAC synchrotron has
been constructed. In this control system we have adopted
a digital feed back systen with a digital synthesizer(DS). Coabining a high power system, performance of thecontrol systea have been tested in a factory (Toshiba)with a sisuiator circuit of the synchrotron oscillation.
Following this test, we had beam acceleration test withthis control system at TARN-ii in INS (institute for
Nuclear Study, University of Tokyo). This paper
describes the RF control system and its tested results.
Introduction
HIMAC Is a heavy Ion accelerator facility dedicatedto the aedlcai use, especially for the clinical treatment of tumors. The ion species reguired for the clinical treataent range from 4He to 40Ar. The required beamenergy is from IOOMeV/u to 800 MeV/u. This maximum
energy is determined so that the silicon ions canpenetrate into a hunan body with a depth of about 30cm.
A 1axi1ua beam intensity is determined to finish one irradiation within a short ti1e, which is 1ollppp forhelium beam. There Is also a requirement of low intensity beam of I07ppp from counter experiment. The HIMAC
synchrotron has been designed to satisfy these requirements. In table 1 maJor parameters of this synchrotron
are listed. The characteristic requireaents for the RF
acceleration system of this synchrotron are followings.
1) iide RF range (from !MHz to BMHz).
2) iide beam intensity range between 107ppp and
1ollppp In the synchrotron.
To control wide acceleration frequency stably with low
Fii noise, a digital control system with a digital

Table 1
Parameters of the HIMAC synchrotron
Beaa species
Injection energy
Momentum spread of
the injected beam
B (injection/maximum)
Field ramp
Repetition rate
Maximum beam energy
Beam intensity range
Circumference
Transition r
Harmonic nuaber
Frequency range
Filling factor
Peak voltage
Synchrotron frequency

He2+ to ArlB+
6 MeV/u< ± 0. 3%.1/1.5 T
2 T/sec
0.5 - 1.5 Hz
BOOMeV/u
107 PPP -1011 PPP
129. 6 Iii
3.67
4
1 - 8 MHz0.8
<11 kV (at !MHz)I - 4 kHz

ComputerTimingGenerator

B-clock
Generator

50kHz
Capture, Ace.start/stop

beam

AR f

Digital Low
Level Electronics

DigitalSynthesizer

Amp.
Mod.

I
I
I

~a~t
I
I

I
I

Fig.I

Block diagram of the RF system

S12FC07434

Feedback Control
434

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC08

Development of a VME Multi-processor System
for Plasma Control at the JT-60 Upgrade
M. Takahashi, K. Kurihara, Y. Kawamata, H. Akasaka and T. Kimura
Naka Fusion Research Establishment
Japan Atomic Energy Research Institute801-1 Mukohyama, Naka-machi, Naka-gun, Ibaralci-ken 311-01 Japan

Abstract
Design and initial operation results are reported of a VME
multi-processor system [l] for plasma control at a large fusio~
device named "the JT-60 Upgrade" utilizing three 32-bit
MC88100 based RISC computers and VME components.
Development of the system was stimulated by faster and moreaccurate computation requirements for the plasma position andcurrent control. The RISC computers operate at 25 :MHzalong with two cashe memories named MC88200. We newly
developed VME bus modules of up/down counter, analog-todigital converter and clock pulse generator for measuring
magnetic field and coil current and for synchronizing theprocessing in the three RISCs and direct digital controllers(DDCs) of magnet power supplies. We also evaluated that the
speed of the data transfer between the VME bus system and the
DDCs through CAMAC highways satisfies the above
requirements. In the initial operation of the JT-60 upgrade, it
has been proved that the VME multi-processor system wellcontrols the plasma position and current with a sampling
period of 250 µsec and a delay of 500 µsec.

calculations, hence, are necessary to obtain the plasma
parameters of positions and clearances more precisely, toproduce stable plasmas and to protect the tokamak
components. As shown in Table 1, the control system must,
then, have such a fast data input/output capacity that it canutilize several tens of status data and several control
commands. The control system must also possess such large
amount of data transfer capability that it can ship up result
data of a few megabytes to its supervisory computer named"discharge control computer" within a limited short time fordata analysis at a shot-interval of 10 to 15 minutes.
This paper reports how we designed the control systemutilizing VME components in order to satisfy the above
requirements for the JT-60U plasma control. S~tion 2 ofthis paper describes the configuration of the VME plasma
control system. The characteristics of the VME system
including its plasma control performance are described in
section 3. The final section is a summary.

Table 1 JT-60U Plasma Control Data

1. IN1RODUCTION

No. of Data
Channels

Item
In the JT-60 Upgrade (JT-60U) [2] where is perfonned thestudy of magnetically confined plasma near the thermal breakeven condition, the plasma current is increased up to 6 I\1A inthe lower X-point divertor configuration. The vacuum vessel
and the poloidal field coils, then, have been replaced for these
improvements.
From the viewpoint of plasma equilibrium control, thevertical positional stability is one of the most important
issues for the tokamak with elongated plasma. The stabilizing
index ns due to the horizontal magnetic field coil is designed
to be 1.6 for the plasma with the poloidal beta ~p=0.6. The
vacuum vessel, however, dose not have much effect on thestabilization, because the vessel is made of corrugated thinwalls whose time constant of the field penetration is very
short (-c=8 m~). Hence, it is necessary to raise the responseof the feedback control system. The control cycle of thesystem must be less than 0.5 msec and the delay of the system
must be less than about 1 msec except for the conversion timein the magnet power supplies.
Moreover, since the stored energy of plasma andelectromagnetic energy of coils will increase, undesirable
events such as plasma disruption may do fatal damage to thecomponents of the vacuum vessel and the coils. More

Input Data
Magnetic Sensor Signals
Coil Voltages and Currents
Control References
Calculation Data
State Parameters of Position
Output Data
Control Commands
Total

Data Amount(kByte)

70
11
5

2,000
330
150

5

300

5

300

96

2,280

2. CONFIGURATION OF THE VME
MULTI-PROCESSOR SYSTEMAs shown in Fig. 1, the JT-60 plasma control system
contains two feedback loops. The major loop is for plasma
heating and gas fueling control and the minor loop is forplasma position and current control which is done by using
five sets of poloidal field coils. Control cycle of each loop
was decided corresponding to time scale of change in its
control objectives:

S12FC08438

Feedback Control
438

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC09

Very Fast Feedback Control of Coil-Current in JT-60 Tokamak
T. Aoyagi,T.Terakado, M.Takahashi, H.Nobusaka, J.Yagyu and Y.Matsuzaki
Japan Atomic Energy Research Institute, Naka Fusion Research Establishment,
Naka-machi, Ibaraki-ken, 311-01, Japan
Abstract
A direct digital control (DDC) system is adopted forcontrolling thyristor converters of power supplies in the JT-60
tokamak built in 1984. Microcomputers of the DDC were 5
MHz i8086 microprocessor and programs were written byassembler language and the processing time was under lms.
!hey were, however, too old in hardware and too complicatedm software. New DDC system has been made in the JT-60
Upgrade (JT-60U) to control the power supplies more quickly
under 0.25 and 0.5 ms of the processing time and also to write
the programs used by high-level language. The new system
consists of a host computer and five microcomputers withmicroproc~ssor on VMEbus system. The host computer
AS3260 performs on-line processing such as setting the DDC
under the discharge conditions and so on. Functions of the
microcomputers with a 32-bit, 20 MHz microprocessor MC
68030, whose OS are VxWorks and programs are written by C
language, are real-time processing such as taking in
instructions from a ZENK.EI computer and in feedback controlof currents and voltages of coils every 0.25 and 0.5 ms. The
system is now operating very smoothly.

I. INTRODUCTION
Control of a current, positions and configurations ofplasmas in a tokarn.ak is done by poloidal magnetic fields,
and power supplies of the poloidal field coils have to becontrolled very fast to suppress intrinsic instabilities ofplasmas. A schematic diagram of the feedback control system
is shown in Fig.1. Magnetic probes measure magnetic fluxesof plasma and a ZENKEI real-time control computerl
performs as follows: calculating the positions of plasmas andthe derivations of the reference positions, multiplying PID
gains to the derivations and outputing the command of thecoil-currents. Direct digital control (DDC) of JT-60 poloidal
field power supply (PFPS)2 carries out that taking incommands of the ZENK.EI (Ip ref in Fig.I) and giving out thedelay angle cosine (Ee) to phase controllers (PHC) of
thyristors. Thyristor banks have two sets of the converters
which deliver the plus and minus direction currents (1 1 and 12),r~pectively, and during low-current under 20% of the rating
c01l-current two converters supply circulating currents (le) to
operate the thyristors smoothly.

II. DDC SYSTEM

A. Functions
The DDC performs two functions in details such as online processing during no-discharge and real-time processing
during discharge. Functions of on-line processing are as
follows: (I) setting the DDC system under conditions of thedischarge instructed by the ZENKE!, which are in detail
instructions and checks on the discharge mode of CAMAC
modules and of PHC and are diagnosis of them before theThyristor

PoloidalField Coils

Banks

DDC
Direct Digital
Control

Ee PHC

PulsesPhase

Controller

I ref ......
F

VFref , ......

ZENKE I

n

VD

le

t

Magnetic
ProbesOCCT

VF ,Vy, .....

Real- Time
ControlComputerFigure I. Schematic diagram o~ feedback control system of plasma position

S12FC09442

Feedback Control

442

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

Workstations as Consoles for the CERN-PS Complex,
setting-up the environment.
P. P..ntonsanti, M. Arruat, J.M. Bouche, L. Cons, Y. Dcloose, F. Di Maio.
CERN PS - 1211Geneva23 - CH

Abstract
Within the framework of the rejuvenation project of the
CERN control systems, commercial workstations have toreplace existing horne-dcsi&'Ilcd operator consoles. RISC-based
1
workstations with UI'ilX® , X-window™ and OSF(.rviotifn.
have been introduced for the control of the PS complex. The
first versions of general functionalities like synoptic display,program selection and control panels have been implemented
and the first large scale application has been realized. This
paper describes the different comptinents of the workstation
environment for the implementation of the applications. The
focus is on the set of tools which have been used, develoi:;ed or
integrated, and on how we plan to ma..l:.e them evolve.

I. lNTRODUCITON

parts of the machine, panuneter tables and control panels. Thish<:!s been achieved through collaboration between the controls
group and tfic operation i;rroup.
The third task is to integrate into the environment
additional user-oriented tools for the production of specificapplications and for simplification of generic tools. These
tools are mostly from the commercial market and therefore itis certainly the fastest changing part.

II. BASIC ENVIRONMENTA Hardware iefrastructure

The cusrent control system of the PS complex is basc<l on
16 bit computers which will be replaced because ofobsolescence of the hardware and system software. ,fl.
rejuvenation project is in progress for upgrading the different
parts of the control system: hardware interfaces, processcomputers, communications and operator consoles [1] [2].
UNJX has been selected for both the con~ole byer nsid theprocess layer.
During this first 3-yearperiod (1989-1991), a workstation
infrastructure has bc;;.en set up and I.he bnsic
blocks ofthe programming environment have been provided. The firstlarge scale application, the hadron injection process into thePS, has been realized for the 1991 PS complex start-up andextended during this time. This p:1pcr describes theinfrastructure and the programming environment. The
application programs and the user interface are both describedin separate papers [3] [4]. In the context of such an evolution,
the first task is to compose a base environment whose majorparts arc: hardware, system software, data-base management
system, equipment-interface and user-interface. Fromexperience, we were very concerned about getting as many
functionalities as possible from this layer in a "safe" way: wewante<l to minimize system development and be confident in
the future of the environment
The second task is to provide generic applications to
support functions like console management, e1Tor handling andall direct interface with the equipmenl: synoptics of

For operation and for development, DEC™'s RISCUltrix™ workstations are used (3bout 50 in 91/92). \Ve use
common configurations with only network interface (Le. nodirect VIvffi, CAMAC or GPIB) and local disks for virtual
memory and temporary files only.
The central facilities consist of servers providing thefollowing services: workstation system files, user files, database and !imc-sh<Jring servers. Cenlrnl time shnring servers arc
used mainly for resource hungry software (hardware or
administration) which are Lrnnsparently available on office
workstations by means of the X-window netvvork facilities.
Each local sub-network includes a regional server
supporting local workstations, DSCls and data. These servers:ire high-end workstations with SCSi disks.
One impDrtant ch<:racttristic of OUI current archite.cture isthat in order to cope with man-power resources for
exploitation, we opted for a very homogeneous environment.
operation critical system is, for the time being, from asingle vendor and covered by a single maintenance contract(hardware and software). This hac: been very efficient.
However, for the s:i.ke of real vendor-independence, software
portability m1d commercial relations, mixing vendors would be
profitable, especially for tasks which are not exploitationcritical.
Another characte-ristic of this architecture is that our newest
servers are enhanced workstation configurations instead of"mid-range" systems ;vith high perfonmmce bus, fast dualported disks, etc. This is due to the increasingly fasterobsolescence of the hardware and the fact that Ulti.ix does not

Gi UNIX is a registered trademark of lIJ.'!IX System
Laboratories.
rn X Windows is a trademark of Massachusetts Institute ofTechnology.
rn Motif is a trademark of the Open Software Foundation.

n~ DEC and Ultrix are trademar}'s of Digital Equipment
Corporation
1DSC are V!vffi-based process computers with Real-TimeUNIX.

S13MMI01
446

Man-Machine Interface and Workstations

446

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI02

General Man-Machine Interface used in Accelerators Controls:
Some Applications in CERN-PS Control Systems Rejuvenation
M.Boutheon, F.Di Maio, A.Pace
PS Division
CERN CH 1211 Geneva 23 Switzerland

Abstract
A large community is now using Workstations as
Accelerators Computer Controls Interface, through theconcepts of windows - menus - synoptics - icons. Somestandards were established for the CERN-PS control systems
rejuvenation. The Booster-to-PS transfer and injection process
is now entirely operated with these tools. This application
constitutes a global environment providing the users with thecontrols, analysis, visualization of a part of an accelerator.
Individual commands, measurements, and specialized
programs including complex treatments are available in a
homogeneous frame. Some months of experience in current
operation have shown that this model can be extended to thewhole project.
I INTRODUCTION

When the decision was taken to rejuvenate the computer
control system operating the CERN-PS accelerators complex[l], it was felt that users should define their needs (2]. Moreprecisely, the end users, i.e. the operation teams had to give
their views on interaction principles and tools.
The framework of this study was of course delimited by
the now worldwide accepted notion of G. U.I.1 , integrating
the concepts of windows, pull-down menus, pop-up menus,
icons and objects selection, all these being driven by apowerful multitasking system [3]. Taking into account thedimension of the process - the PS complex includes 10
accelerators - a prototype had to be constructed in order toevaluate the new human interface proposed.
The hadron beam transfer line from the 1 GcV Booster
synchrotron and the related CPS injection process wereselected as guinea pigs. The principles and applications aredescribed below.

notion of virtual machine: a parallel adjustment of concurrent
beam types in the same accelerator is possible.
From the above the concept of an .Mnlicatjon emerged:
the whole lot of application programs needed to operate alogical part of an accelerator in an autonomous manner. We
are talking here of the "CPS 1 GeV Injection Application"
given as an example.
An Application includes:- the complete access m the control/acquisition of theparameters set composing the sub process- the controls of the dedicated measurement devices andassociated presentation programs
the temporary specialization of some generalmeasurement devices (dedicated initialization of parameters)
access to particular application programs developed forthe specific sub process.
The term Application will be used in what follows todesignate the working environment defined above.

I!oglnl In

L

II PROCESS STRUCTURING
In a very large process to be controlled from a centralized
point, the first task consists in defining a structure allowing
each member of an operating team to work in a quasi
independent and secure way. These principles were alreadysuccessfully introduced in the present control system [4] andare kept here. Moreover, the PS accelerators complex pulse·
to-pulse modulation (PPM) working mode [51 imposes the

Proca~

saleclipn

figure I: a CPS supercycle showing the succession of beam types andselection strucUJte scheme. !!lustrated: The I GeV Inj«tion Application
addresses to the CPS parameters valid for !he beam $cnt to the SPS a,ccelerator.

1 .Q;raphical l!ser Interface

S13MMI02
452

Man-Machine Interface and Workstations
452

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI03

The Replacement of Touch-Terminal Consoles of the CERN
Antiproton Accumulator Complex (AAC) by Office PC's
As Well As X-Windows Based Workstations
V. Chohan, I. Deloose, and G. Shering
CERN, PS Division, CH-1211Geneva23

Abstract
With aging hardware and expensive maintenance andreplacement possibilities, it was decided to upgrade the AAC
touch terminal consoles with modern hardware. With significant amount of operational application software developedwith touch terminals over 10 years, the philosophy adopted
was to attempt a total emulation of these console functions oftouch actions, graphics display as well as simple keyboard terminal entry onto the front-end computer controlling the AAC.
The PC based emulation by mouse and multiple windows
under MS-DOS and later, under the Windows 3 environment
was realized relatively quickly; the next stage was therefore to
do the same on the Unix platform using software based on Xwindows. The communications channel was established using
the TCP/IP socket library. This paper reviews this work up to
the operational implementation for routine control room usage
for both these solutions.
INTRODUCTION
The CERN Antiproton Accumulator Complex (AAC) is
composed of two circular, concentric ring accelerators and an
antiproton production area (see Fig. 1). The inner ring, theAntiproton Accumulator (AA) was commissioned in 1980
while the outer, Collector ring (AC) was brought into operation in 1987 to permit an order of magnitude increase in the
antiproton flux. The AA was conceived initially as an experiment and was built and commissioned in record time while the
CERN PS Complex of accelerators was undergoing majorchanges from rudimentary to modern computer controls. For
reasons of time and financial expediency, it was considerednecessary to have cheap operator interaction means available

for the AA commissioning, with simple to use interpreter(Nodal) based facilities. The Touch Terminals [1, 2], developed and used for the CERN-SPS control room were ideallysuited for this role [3]. The controls system provided thenecessary facilities to connect the Touch Terminals to theequipment. The AA controls system and its extension andupgrade in 1986 has been amply described elsewhere [4, 5].
THE PRESENT TOUCH TERMINALSThe Touch Terminal (TT) is a specially configured
mini-CAMAC crate with a microprocessor and special modules to drive a touch button screen, a graphics and character
display screen and is connected to the front-end computer
which controls the equipment via CAMAC Serial highways.
Communication between the computer and the TT is by meansof the standard current loop serial interface. The microprocessor controller in the TT is programmed to be transparent to
the front-end computer terminal driver. However, it also detects or inserts certain "escape sequences" enabling the simple
touch button functions like LEGEND, BUTTON etc. andgraphic monitor functions like VECT, TEXT and so forth.
Hence, the TT simply appears as a standard terminal to thecontrols computer but provides powerful interaction facilities
with equipment. For the antiproton improvement programmeat CERN and in preparation for the construction/commissioning of the AC ring in 1986-87, the TT's were
upgraded to a Motorola 68000 based microprocessor, permitting colour alphanumeric and graphic facilities as well as
higher terminal speeds. This, together with a faster front-end
computer, has permitted up to five operational TT's for the
AAC since 1986.

26 GeV/c p f~ ;s on tar':jtlt
J.5 GcV/c p !raTl PS tc::lt ~1'et>iPS~~

Fig. 1. General layout (magnetic elements only) of the Antiproton Accumulator Complex (AAC):
outer ring - Antiproton Collector (AC), inner ring - Antiproton Accumulator (AA).

S13MMI03
456

Man-Machine Interface and Workstations
456

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI04

The Elettra Man-Machine Interface
Franco Potepan, Giuseppe Surace, Marco Mignacco
Sincrotrone Trieste
Padriciano 99, 34012 Trieste, Italy
Abstract
ELETIRA is a third generation Synchrotron Light Source
under construction in Trieste (Italy), with beam energies
between 1.5 and 2 GeV. Two networks connect three layers ofcomputers in a fully distributed architecture. An ergonomic
and unified approach in the realization of the human interface
for the ELETIRA storage ring has led to the adoption of
artificial reality criteria for the definition of the systemsynoptic representation and user interaction. Users cannavigate inside a graphic database of the whole system andinteractively edit specific virtual control panels to operate on
the controlled equipment. UNIX workstations with extended
graphic capabilities as operator consoles are used in theimplementation of the PSI (Programmable Synoptic
Interface), that was developed on top of Xll and PHIGS
standards.

I. INTRODUCTION
We may think of an ideal man-machine interface (M.MI) asa tool which allows users to interactively specify theirpreferred means of interaction with the devices controlled,using graphic programming techniques to compose predefined
objects that support the exchange of numeric, string or graphic
information. A definition of new specific objects is also
possible using an editor with similar properties.
Commercial interfaces ado not generally combine these
two requirements without the introduction of a considerable
amount of new concepts and notions. Today we can profit by
the wide diffusion of some advanced graphic user interfaces(GUis). based on a well defined set of composable objects, orwidgets, that have certainly increased the knowledge ofinterface principles and interaction paradigms among users. A
similar awareness at the lower level, where graphic primitives
and basic interaction techniques should be structured together
to form an object, is at present unthinkable. As a matter offact, a global definition of the semantic and syntax of graphic
human-computer interaction still suffers from a lack ofstandardization of the relative graphic and dialogue lexicon,
which is a young field of active research. Interactive widgets
composers are indeed filling up the market, while a similar
approach for the definition of widgets is practically abandoned.
II. DESIGN GOALS
In our project of a MMI for the Elettra storage ring the aimof obtaining a well balanced integration between new powerfulfeatures available on modern hardware and software platforms,
and a comprehensive exploitrnent of innovative methodologies
concerning human-machine interfaces, has led to a continuous

revision of the design and implementation phases, together
with a considerable effort in testing prototypes with real users.
The usual top-down design approach which uniquely
guarantees consistency in terms of colour coding, menus anddialogues layout, warning messages and overall behaviour of
the user interface is left at the end, when all possible userinteractions are already defined.
Two main lines have been followed in the design of 'P(Programmable Synoptic Interface), in order to keep theamount of new concepts required for its operation to aminimum:- to hide all the details concerning the specific structure of
our control system from the users. A complete transparency ofoperative system, programming language, graphic andcommunication libraries is therefore essential.
- to take full advantage of all the notions users are alreadyfamiliar with: the local operations of the devices, theplanimetrical layout of the machine, the commonly used
desktop metaphor as a computer interface.
III. CONCEPTUAL ORGANIZATION
A possible solution to these demands was to adopt typicalartificial reality criteria for the design of our interface. A
planimetric representation of the whole system, where all theitems controlled are shown with their real shape and position,
was recognized as the users' most familiar environment. The
equipment displayed inside the environment is associated tovirtual control panels which allow users to operate the graphic
representation of a large set of devices like switches, knobs,
sliders, digital and analogue indicators, whose behaviour isequivalent to that of the same instrumental devices. A set ofwell defined interaction paradigms regulates the navigation
inside the environment, the modification of the scale andvisibility of the layers into which the graphic information is
structured, the selection of devices and the activation of therelative control panels.
Let us now distinguish between the principal elements thatcompose our artificial world:-an environment, i.e. a synoptic representation of thewhole system;- a set of objects, Le. the devices controlled;- a collection of virtual control panels, i.e. the logicalgrouping of controls associated to one or more devices;- a set of interaction paradigms between the user, theenvironment and the objects.
The environment consists of a complete graphic databaseof the whole system, no longer restricted to fixed size views of
selected parts of the plant. If we define the graphic database at
system level, freeing the user from the synoptic drafting

S13MMI04
460

Man-Machine Interface and Workstations
460

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI05

Exploiting the X-Window Environment to Expand the Number, Reach, and Usefulness of
Fermilabl Accelerator Control Consoles

Kevin CAHILL, James S:MEDINGHOFF
Fermilab, P.O. Box 500, Batavia, IL 60510, USA
II. EXPANDING TIIE NUMBERS

Abstract
The Fermilab accelerator operator workstation of choice is
now the Digital VAXstation running VMS and X-Window
software. This new platform provides an easy to learn
programming environment while support routines are
expanding in number and power.
The X-Window
environment is exploited to provide remote consoles to users
across long haul networks and to support multiple consoles ona single workstation. The integration of imaging systems,
local datalogging, commercial and Physics community's
software, and development facilities on the operator
workstation adds functionality to the system. The locallyengineered knob/pointer/keyboard interface solves the multiple
keyboard and mouse problems of a multi-screen console. This
paper will address these issues of Fermilab's accelerator
operator workstations.

I. CONSOLE HARDWARE
The accelerator console is built around a VAXstation color
workstation running VMS and X-Window software. The
VAXstation 3200, V AXstation 3520, V AXstation 3100/30,
3100/38, 3100n6 and MicroVAX II are in use as workstation
processors. The displays have either 1280 by 1024 or 1024
by 768 resolution with 8 bilS per pixel.
Network communication to other accelerator processors is
via accelerator-<:ontrol network (ACNE'!) software using either
a locally designed token-ring card or an Ethernet to token-ringbridge. Communication for system management, accelerator
clock, and other purposes is via DECNET and TCP/IP over
Ethernet.
A single-screen console provides full functionality, butsome control room users require multiple displays. Xterminals using TCP/IP and Ethernet provide these additional
screens. The NCD-17c is the preferred X-terminal for thiscontrol system.

The number of consoles connected to the Fermilab
accelerators is rapidly growing. Where 20 consoles served
Fermilab for 10 years and budgets were prepared for 50 new
consoles, the demands for VAXstation consoles are exceedingthat estimate. 33 V AXstation consoles are active with 24
additional VAXstations scheduled to be purchased by Spring,
1992.
The increased numbers are due to a variety of factors.
Many requests for accelerator consoles were denied over theyears due to high cost and difficulty of installation. The newconsole with symbolic debugging support is a productive rapid
cycle development machine. Users want convenient access toaccelerator information, often in their office.
However, greater numbers of consoles present larger
demands on central services and front end data acquisition nodes
requiring consequent upgrades in those areas and theintroduction of application program time-outs and othermeasures to balance high accessibility with overallthroughput.
As new models of VAXstations are announced and released,
we tend to purchase machines with better performance andvalue. It is clear that a console supporting a development
cycle has an excess of cpu cycles and network bandwith.
Utilizing that excess power is possible by supporting multiple
consoles on a single VAXstation.

A. X-server consoles
The software architecture of a console is relatively simple.
A large shared memory and shared library, several manager
tasks and user applications make up a console. Splitting theshared memory region into a global area and multiple console
specific area provides the ability to run additional
alphanumeric, graphic, and utility managers, and sets of user
applications. An X-server console is obtained at the cost of an
X-terminal for the window displays. Twenty X-server
consoles are in regular use primarily in the offices ofprogrammers and accelerator operations specialists.

1 Operated by Universities Research Association for the
Department of Energy

S13MMI05
464

Man-Machine Interface and Workstations

464

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI06

A Virtual Control Panel Configuration Tool for the X-Window System
Jeffrey 0. Hill, Leo R. Dalesio and Debona M. Kerstiens
Los Lamos National laboratory, Los Alamos, NM 87545
dation on which we could build future extensions and enhancements, while spending less of our time on software maintenance.

Abstract
Computer Graphics Workstations are becoming increasingly popular for use as virtual process control and read backpanels. The workstation's CRT, keyboard, and pointing device
are used in concert to produce a display that is in essence a control panel, even if actual switches and gauges are not present.
The code behind these displays is most often specific to one
display and not reusable for any other display. Recently, programs have been written allowing many of these virtual
control panel displays to be configured without writing
additional code. This approach allows the initial programming
effort to be reapplied to many different display instances withminimal effort. These programs often incorporate many of thefeatures of a graphics editor, allowing a pictorial model of theprocess under control to be incorporated into the control panel.
We have just finished writing a second generation softwaresystem of this type for use with the X-window system and theExperimental Physics and Industrial Control System (EPICS).
This paper describes the primary features of our software, theframework of our design, and our observations after initialinstallation.

FEATURES
The second generation operator interface or OPI consists ofan editor which is used to create and configure virtual control
panels and a display manager which activates them. A display

file containing the virtual control panel description is the only
form of communication between the two programs.
Once activated, displays can be used to monitor and control
Input-output
controller

BACKGROUND
The EPICSl control system consists of an input-output
controller subsystem that communicates via a software bus
with many general purpose or application specific control system components. The input-output system provides the time
critical and hardware specific portions of the control system.
The software bus or "channel access" provides standardized
communication between control system components over a
local area network. EPICS has the following general purpose
components: an alarm manager, an archive subsystem, atiming subsystem, and the operator interface which this paper
describes.
A first generation operator interface, developed for the telescope control system, has been deployed at the Argonne
National Laborator:{ and elsewhere by the Los Alamos
National Laboratory . This operator interface was next ported
for use on the EPICS control system and used on the Ground
Test Accelerator and related test stands at LANL. This first
generation operator interface proved the effectiveness of thevirtual control panel technique for reducing the applications
programming effort2.
This paper describes the design and implementation of asecond generation operator interface. We wanted to replace theobsolete graphics platform on which the first generation was
built with the open X Window System standard. Other goals
were faster display startup and update rates, and more effective
configuration tools3. We also wanted to build a proper foun*Work supported and funded under the Department of Defense,
US Army Strategic Defense Command, under the auspices of
the Department of Energy.

operator
interfacedisplay
managerx

worlc5tadon.screen,keyboard,"""""'•

process variables. The display manager accomplishes this by
responding to external events and updating the screen. External
events include keyboard input, mouse input, or process variable state changes.
Operator interface displays are configured with a graphics
editor capable of manipulating the normal complement ofgraphics object primitives such as rectangles, lines, ovals,
arcs, and text. In addition to these primitives, the editor canalso configure a full complement of process variable control
and read back components such as indicators, meters, buttons,
and menus. Once created, one or more graphics objects can beselected for cutting, copying, pasting, moving, or scaling.
These techniques can be used to move groups of objects
between several operator interface displays under edit on thesame workstation. The editor also supports features for productive alignment and even distribution of object groups. The
editor saves a finite list of all previous operations so that they
may be individually undone at the operator's discretion.
A graphics form for modifying attributes is provided foreach type of object which can be created by the editor. The
forms have entries for every operator modifiable attribute even
if some attribute modifications, such coordinate translations,can be carried out more efficiently with the mouse. Thesegraphics forms or property sheets provide a simple and consistent method for entering the more complex configuration required by process control and read back components such asplots or indicators. For example, a bar inwcator might require
entry of a process variable name, labeling option, direction ofincrease, and a color modifier (the color could be static or basedon an alarm condition).

S13MMI06
468

Man-Machine Interface and Workstations

468

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI07

X-Window for Process Control
in aMixed Hardware Environment
Matthias Clausen, Kay Rehlich
Deutsches Eiektronen Synchrotron
D-2000 Hamburg 52

Abstract
X-Window is a common standard for display purposes on
the current workstations. The possibility to create more than

one window on a single screen enables the operators to gain
more information about the process. Multiple windows fromdifferent control systems using mixed hardware is one of the
problems this paper will describe. The experience shows that
X-Window is a standard per definition, but not in any case. But
it is an excellent tool to separate data-acquisition and display
from each other over long distances using different tw;;s of
hardware and software for communications and display. Our
exv;;rience with X-Window displays for the cryogenic control
system and the vacuum control system at HER.ti. on DEC andSUN hardware will be described.

L Cr1ogenic Controls
A. Components
The cryogenic control system for the 1-::.ERA collider -which
has a circumference of 6.3 km- is based on a commercial, distributed control system called D/3. The backbJne of the system
is a redundant communication link using HDLC proccr:;ol anda tokenalgorithm(Fig. 1). Display and control functionality a separated from each other in 1he individual display(DCM) and process control computers (PCrvf). The cryogenic
processes, as there are: compressors, coldboxes, helium distri·bution in the HERA tunnel to the 422 superconducting dlpoleand 224 quadrupole magnets, low temperature measurement,
superconducting cavily control, supervisory control for the
ZEUS solenoid, controls for the magnet test hall etc. are controlled by means of the PCMs. More than 3000 analog and
3100 diaital sh:mals are scanned,archlved and calculated in control Ioo~s and~ logic devices. The scantime for the individual
points is defined to be between 0.25 (sec] for fast control loops
and 3 [sec] for temperature read-out of the HER..\ magnets. All
poims are checked for over and underrange, and high and low
limits. Alarms are send to various printers throughout the system according to the alarm destination index (ADI). The printers can be host based or connected to terminal servers.

B. AccessAll process points can be accessed from any PCM and DCM
in the whole system. This way no 'special' consoles exist in thesystem for process control: There are some consoles that haveadditional/other functionalities like annunciator panels witl1
function keys and X-Window displays with or without the fullaccess w the process. This (X-)extension to the existing system
is very useful since the architecture of the D/3 system does
only foresee consoles directly connected to one of the DCMs.
X-Displays of the cryogenic control system are now running invarious places at DESY: In the main control room where the
Di3 !in.le is not jet installed, and where ever it is useful for the

Figure 1. 111e Cryogenic Control System

S13MMI07
Man-Machine Interface and Workstations

471

471

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

An Open Software System Based on X Windows
for Process Control and Equipment Monitoring
A. Aimar, E. Carlier, V. Mertens
European Organization for Nuclear Research (CERN) - SL Division,
CH - 1211 Geneva 23, Switzerland
Abstract

C. Tool Kit Approach

The construction and application of a configurable open
software system for process control and equipment
monitoring can speed up and simplify the development andmaintenance of equipment specific software as compared toindividual solutions. The present paper reports the status ofsuch an approach for the distributed control systems of SPS
and LEP beam transfer components, based on X Windows
and the OSFJM:otif tool kit and applying data modeling andsoftware engineering methods.

This experience has encouraged us to try a different
approach by replacing our equipment specific programs by ageneral software system or tool kit which receives its
individual functionality through a fonnal description of theequipment and the desired function in tables. If this idea ispursued rigorously almost full separation between code anddata can be obtained, leaving only pieces of specific code
behind which are uneconomic to parametrize.
As possible advantages we see, besides others, a more
uniform appearance of the equipment, a more transparent
specification phase with improved communication between
hardware and software specialists, leaving less room formisunderstandings, and a shorter reaction time fordevelopments and modifications.
Before starting the development we made S()me
investigations in the commercial sector. At that time wecame to the conclusion that a separate development could
well be justified in view of the potential problems
encountered when embedding and maintaining a commercial
process control system in a given and evolving environment,
disregarding any price argument. With time passing by, we
might however come to a different finding.
To make our task more feasible we did not attempt towrite a full package from scratch but rather tried to re-use amaximum of existing packages, tools, and mechanisms,
combining them into the desired product.
One of the key goals was to arrive at a portable, thus
platfonn independent, and evolvable software system whichshould be easy to adapt to changing environments orincreasing needs. This becomes particularly attractive in
combination with the X Windows system and the OSF/Motif
tool kit since they allow to perform input or visualize
complex results on a large variety of media without muchadaptation work.
In the following we will first give an overview of the tool
kit concept and describe its key ingredients, then the chosen
implementation. Afterwards, we will present results obtainedin a prototype application, followed by a status report and an
outlook.

L INTRODUCTION AND MOTIVATION
A. Equipment
Equipment for SPS and LEP beam transfer at CERN
comprises systems like the SPS injections, extractions,dumps, and collimators, and the LEP injections andseparators. In total some 80 distinct systems spread over both
accelerators and the fixed-target areas have to be controlled.
At present, new control systems for the LEP beam dump andthe LEP Pretzel separators are being prepared.
Although the functionality and the composition varies
considerably between the different systems, all can essentially be characterized as 'slow controls': Reaction times as
seen from the main control room are of the order of seconds;
any fast responses, e.g. for beam dumping, are supported by
special hardware. The amount of data exchanged between themain control room and the devices is small.

B. Equipment Software
However, comprehensive equipment specific software has
to be provided to achieve the desired level of abstraction
towards the main control room, to allow monitoring of theequipment performance, and to dispose of efficient tools for
local and remote fault-finding to help keeping down-times
low, in particular in view of the volume and the distances
involved.
For this sake a lot of code has been written up to now,
especially with the large-scale use of distributed processing.
Due to the limited manpower there is a strong risk ofbottlenecks in the treatment of requests for modifications or
extensions which might arise from an evolving environment
or an increased sophistication of use.

II. TOOL KIT CONCEPTThe layout of the tool kit and the way the user interacts
with it is sketched in figure 1.

S13MMI08
Man-Machine Interface and Workstations

475

475

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S13MMI08

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI09

Porting Linac Application Programs to a Windowing Environment
J.M. Nonglaton, U. RaichCERN 1211 Geneva 23 - CH

Abstract
We report our experience in porting Linac application
programs written for Camac controlled hardware .consoles to an
X· Windows/Motif based workstation environment.
Application programs acquire their parameter values from afront end computer (FEC), controlling the acceleration
process, via a local area network. The timing for dataacquisition and control is determined by the particle source
timing.
Two server programs on the FEC for repetitive acquisitionand command-response mode will be described.
The application programs on the workstations access acommon parameter access server who establishes the necessaryconnection to the parameters on the FEC. It displays theparameter's current values and allows control through Motifinteractive synoptics editor and its corresponding driverprogram allow easy generation of synoptics displays andinteraction through command

I. THE EXISTING SYSTEM.
The control system for our Proton Linac has been u...,,,.J',••vu
and implemented in the mid seventies. The system isona single PDP-11
running the RSX-I operating
system. Because of the memory sizes available at that time all
programs
system software and a major part of thehas been written in Macro-11.
The softw&-econsists of 3
parts:
is interfaced- The equipment
software: all
through serial Camac. This software nart contains a"central request
all reQUests for Camac
access andout Camac command in synchronism
with thesource timing.
- Softwaretheconsoles the consoles areinterfaced- The application nn-;n-r<mc><>
For historical reasons
Linac control system is the only
accelerator control system in our division that uses PDP-11
computers. All other machines are controlled with Norsk Dataequipment. The consequence of this is the impossibility toaccess the Linac control system from the
purposeoperator consoles in the main control room
since thecomputer networks of the two types of systems areincompatible. The firstfor this project was therefore toaccess to Linac parameters through the new workstation
operator consoles.

THE NEW SYSTEM
The old PS control system is in a process of rejuvenation[1] according to the new common architecture for CERN
accelerator [3]. In this global plan a special plan was definedfor our Proton Linac. This was especially needed by theimpossibility to maintain any more the equipment of the

Linac consoles. It was also an opportunity to gain experiencein windowing environment and in porting old style application
into this environment. To achieve this halfway solution, we
decided to connect the PDPl 1 front end computer to Ethernet
network and to use Decnet communication package between
these front end and the Ultrix workstation. This network
software was the only one supported by the manufacturer DEC
on the RSXll-M operating system of the PDPll. We
therefore needed to write Decnet server for PDPl 1 to allow
remote access from the workstation to the equipment.

III. NEW SOFIWARE WRITI'EN FOR THE PDP-11
Because the Proton Linac is almost permanently runningduring the whole year, only a gradual switchover to the new
system seems possible. We therefore decided to rewrite themajor application programs under X-Windows/Motif for theworkstations and leave the change of the parameter accessprocesses to the DSC for a later date. In order to be able tooperate the Linac from a workstation we identified thefollowing software as absolutely indispensable:- access to any single parameter for acquisition and control;- synoptics;
logs;- several application programs, especially beam diagnostics.
Leaving the old consoles in the Linac control room inplace and the old programs accessible, it was possible tomstall the new application software without interference in theoperation of the accelerator. To makeof the PDP-11 system available to the external world, two"server programs" on the PDP-11 had to be developed. The
first one (VXS) operates in command-response
waiting
for a command sent to it over the network. This command istranslated into calls to the hardware
software andsubmitted. The response is put back into a network packet andsent back to the
The command-response server
accepts commands to acquire equipment data and status, tocontrol equipment and to get database information like...... u . . .~ values, convertion factors and the like.
The second server (SNS) gets a collection of equipment
parameter names and performs continuous acquisition on theseparameters. The acquisition values are periodically sent back to
the requesting client program. The timing for the acquisitionisby the proton source timing which pulses at a rate of1
The only network software available under RSXl 1·Mis anwhich does not allow
incomplete implementation of
to open more than l logical link to another task. Real server
processes are therefore impossible. The only way to allow
several tasks access to Linac parameters is to duplicate the"servers".
In addition to the "servers" described above (SNS,VXS) ,which are the most important ones, a GPIB server, a CAMAC

S13MMI09
Man-Machine Interface and Workstations

479

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI10

A New Workstation Based Man/Machine Interface System
for the JT-60 Upgrade
I.Yonekawa, M.Shimono, T.Totsuka and K.Yamagishi.
Japan Atomic Energy Research InstituteNaka-machi, Naka-gun, Ibaraki-ken 311-01, Japan

Abstract
Development of a new man/machine interface system wasstimulated by the requirements of making the JT-60 operator
interface more "friendly" on the basis of the past five-year
operational experience. Eleven Sun/3 workstations and theirsupervisory mini-computer HIDIC V90/45 are connected
through the standard network; Ethernet. The network is also
connected to the existing "ZENKEI" mini-computer systemthrough the shared memory on the HIDIC V90/45 minicomputer. Improved software, such as automatic setting of thedischarge conditions, consistency check among the relatedparameters and easy operation for discharge result data display,offered the "user-friendly" environments. This new man/machineinterface system leads to the efficient operation of the JT-60.

Network~- (IOMbps)

cu:
P'tlu11 control
Ctm1put?r

I. INTRODUCTION
The former JT-60 supervisory control system named"ZENKE!" consists of seven mini-computers and a CAMAC
system for controlling tokama.lc machine operating conditions,discharge sequences and plasma equilibrium controI.[l 1Althoughbeen adequate the performance of "ZENKE!" has heavily worked,
its limitations such as memory
calculation speed, word
length reached its limitation due to the option of the lower Xpoint operation and pellet injection syscem.
The new "ZENKE!" has to provide the long pulse operation (up to 15 sec ), high speed plasma position fe.edback control (250µ.sec) and more user-friendly man/machine interface. [2],[3]To satisfy the above requirements, we modified the plasma
feedback control system of the two mini-computer system tothat of a VME system. The man/machine interface system waschanged from that of simple terminals to workstations. These
workstations provide UNIX operating system with features of amulti-window system, network file system and many
application tools for data handling and graphic interfaces. The
improvements of the man/machine interface syscem have been
made for the setting the discharge condition parameters,
operation of the discharge and displaying of the discharge result
data wavefonns on the basis of the "friendly".

Fig.I Man/machine Syslem configurallon in ZENKE!

II. SYSTEM CONFIGURATION

A. System Overview
The ZENKEI was composed of five mini-computers fordischarge control and monitoring of plant operations. The
CAMAC modules are used for datn acquisition and control.
Two mini-computers for high speed plasma position andshape control. The 14 CRT displays with keyboard and pushbutton switches had been prepared as the operator interface. Thissystem had contained the following major functions;- set discharge condition parameters,- execute a discharge sequence,- monitor the subsystem's operating status, and- display the discharge result data.
The modification of many discharge condition parameters
within a short period of time placed a big burden to theoperator. Furthermore, the operator had to move back and forthfrom a certain console with a certain function to another withanother. In addition, only a small memory had remained as aresult of many modifications.
In order to improve the man/machine interface, computer
hardware had to be replaced. The new man/machine interface

S13MMI10
Man-Machine Interface and Workstations

483

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI11

A Flexible Graphic Display System
for Accelerator Control
Cheol On PAK
Photon Factory, National Laboratory for High Energy Physics (KEK)
Oho,Tsukuba,lbaraki305,Japan

Abstract
A flexible graphic display system for controlling the KEK
Photon Factory storage ring has been developed.
A VME computer locally controls the graphic display
system and communicates with the host control computer
through a RS-232C link:. Graphic pictures are prepared in thelocal system by an interactive operation using either a tablet
or a keyboard. The host control computer is free from any load
due to graphics processing. In an on-line operation, pictures
are displayed and modified by simple command strings fromthe host computer.
A "picture stack" method has been developed for thisgraphics system. The latest demanded picture always has toppriority to be presented on each display monitor. Previous
pictures are saved in a stack and can reappear when the current
picture has been freed.

sends a request to display a necessary graphic picture to
FGSCT by DSM (Data Stream Manager, inter-task
communication utility based on network [2]). FGSCT
manages those requests from various application tasks. Whenit accepts a display request, it establishes a connection path
between the application task and a proper display monitor.
Hereafter, the application task is able to make modifications
on a displayed picture. The connection path is valid until theapplication task frees this picture.
An intelligent graphic display station (DP-1000 from
Digital) receives commands from FGSCT and draws pictures.
One DP-1000 can handle three independent display monitors.
The link between S-3500 and DP-1000 is RS-232C.

s-

1.
Since colorful graphic displays can provide us with much
useful information, even at a glance, they have become one of
the indispensable tools needed for modem control systems.
However, it often requires many man-hours to prepare agraphic display system, since graphics software is usuallycomplicated and difficult to use. Furthermore, such graphics
processing puts a heavy load upon control computers.
NETWORKWe have developed a flexible graphics display system(FGS) for controlling the Photon Factory storage ring. FGS cornmimic:onon;"-----71<.,;----'\ tDi"-;;:;.~
has the following features:- Host control computers are free from graphics processing
load.
- Graphics are easily
without programming.
- Co-ordinate-free location method is possible.
Fig. 1. Schematic of the FGS architecture.
• Any picture can be presented on any display monitor.
APPL.: Application Task
·Several pictures are kept in a stack manner for each monitor.
FGSCT: FGS Control Task
DSM: Data Stream Manager (Inter-task communication• Co-operative work with FIS (flexible touch screen system
based on token ring network)[l]) is possible.

2. SYS'IEM
A schematic of the FGS architecture is shown in fig. 1.
The control system uses four minicomputers (FACOM S3500 from Fujitsu) linked to each other by a token ring-type
network [2]. The FGS control task (FGSCT) resides in one of
the control computers. :Many application tasks for control are
distributed over four control computers. The application task

3. FuNCTION OF FGS
A basic concept of FGS is that intelligent graphic display
stations can present pictures by commands from control
computers. Since the display stations perform all of thegraphic processes, the control computers have only to send
short command strings. Graphic pictures are prepared
beforehand by the display station in a stand-alone manner.

S13MMI11
Man-Machine Interface and Workstations

487

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI12

Human-Machine Interface Software Package
D.K.Liu C.Z.Zhang
Institute of High Energy Physics
P.O.Box 918 Be!jing

IL SYSTEM STRUCTURE

Abstract
The Man-Machine Interface software Package(MMISP) is
designed to configure the console soft.ware of PLS 60Mev
LINAC control system [l]. The control system of PLS
60Mev LINAC ia a. distributed control system which includes the main computer (Intel 310) four local station,and two .sets of industrial level console computer. The
MM ISP provides the opera.tor with the display page editor 1
various 1/0 configuration such as digital aigna.la In/Ou~,
analog aigna.l In/Out 1 waveform TV graphic display, andinteractive with opera.tor through graphic picture display,voice explanation, and touch panel. Thia pa.per describes
its fun~tion and application.

The MMISP shown as Fig.1 includes seven subroutines
which are the Page Editor, the Speech library Editor, theDigital Monitor(DM) Configuration. the Analog Monit~r(AM) Configuration and the Execution Program.

A.Page Editor
The page editor ia used to edit the display picture and tocreate the drawing library. Its main function is follows:"' Drawing the line, circle, block line by cursor orup/down, left/right key
16 color could be selected· • The Picture can be moved, copied and loaded !n harddisk as subpicture page

*

I

I

SPUCH

B.l/O
Configuration
I

LIB t:Olroil

11. The DM configuration is used to create the display mesMCUTIOM
PROO RAMs~ge of digital signals for the .user's page 1 and the message

wtll be saved in the page setting file. It has 5 kinda of dig-

WAVtlOWHICCONFIGURATION

Flg.1 The S1nu:1ur11 Diagram of MMISP

I. INTRODUCTION
Recently, the control level has grown up so fast by VLSI
technology development. There are many kind of Workstion developed for interactive tool between operator andcomputer. or course it has more powerful function but isalso is expensive a~d can't connect a small system easily.
We introduce a interactive software which is highly cost.
effective, compact, and emphasizing easy operation basedon the PC.

ital display mode, which are the painting giyen area, thecharacter string display, the drawing element display, thetum to the given page and the speaking something.
· 2. The AM configuration is applied to generate the display message of analog aignals for the user's page, and themessage will also be saved in the page setting file. It has
six kinds of analog display modes, which are the digital
display that the digit number can be selected from 1 to7, the rectangle or other shape image display, the pointermeter display, a.nd the turn to given page or the speaking
something if the analog signal is overvalue.
· 3. The Wave & Graph Configuration is applied to create the display message of signal waveform, such as pulse
voltage wave, or TV image for the user's page, and themessage, such a.6 the coordinate and display color etc., will
be saved in the page setting.file.
: 4. The Touch Panel Configuration is used to define thefunction of touch area, and to aa.ve these definitions in thep;age setting file. It ha.a ten functions which are the re~cpvering original color of given area, the changing color ofgiven area., the input and display for a character string ordata, the making a. character string or data available or

S13MMI12
490

Man-Machine Interface and Workstations490

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Correlation Plot Facility in the SLC Control System*
L. Hendrickson, N. Phinney, L. Sanchez-Chopitea, and S. Clark
Stanford Linear Accelerator Center, Stanford University, Stanford, CA 94309, USA
Abstract
The Correlation Plot facility is a powerful interactive
tool for data acquisition a.nd a.na.lysis throughout the SLC.
This generalized interface allows the user to perform a
range of operations or ma.chine physics experiments without the need for a.ny specialized a.na.lysis software.
The user ma.y step one or more independent parameters, such as magnet or feedback setpoints, while measuror calculating up to 160 other parameters. Measured
va.ria.bles include all analog signals available to the control system, as well as calculated parameters such as beamsize, luminosity, or emittance. Various fitting algorithms
and display options are provided.
A software-callable interface has been provided sothat a host of applications can call this package foranalysis and display. Such applications regularly phase
klystrons, measure emittance and dispersion, minimize
beam size, and maintain beam collisions at the interact ion point.
INTRODUCTION

in the development of the SLC, a generalized
tool wa.s written to acquire online data, and perform analand display functions across a wide range of information for many users. Rather than develop similar piecesof code for each combination of data, the Correlation Plotfacility was designed generically to handle all of the datatypes available, and be extensible to other types that mightevolve.
Due to the initial success of this implementation, asoftware-callable interface was added, so that other packages could make use of these fitting, plotting, and display
facilities. This approach avoided redundant developments
and provides a more consistent user interface for otherparts of the control system.
ORGANIZATION

The main elements of the Correlation Plot facility are:o A genera.I control package which can step through setpoints of magnets, klystrons, feedback loops, timing parameters, and other device points of interest.
o A genera.I data acquisition facility that can acquire datafrom a variety of sources, including high level parameters
derived from analysis ofklystron fast time plots and wirescans.
o A range of curve fitting algorithms, including average,
linear, polynomial, sinusoidal, Gaussian, and specialized
beam deflection curves.
*Work supported by Depa.rtment of Energy contract
DE-AC03-76SF00515.

o A general plotting package to display the acquired ancl
fitted data. The sampled <la.ta may be plotted against
the step variable, any of the sampled quantities, or the
step number.
o A generic optimization feature allowing users to createa correlation plot to vary a step variable; obtain sampled data for each point, fit a parabola to the data, andimplement the value of the step variable that results inthe fitted minimum.
INTERFACES

Touch Panel
The Correlation Plot facility is an integral part of
the SLC Control Program SCP (4]. The primary user interface utilizes a touch panel or cursor keys, although amouse and trackball have been added as part of a newer
X-window SCP. The main
provides buttons for specifying the step and sample variables, selecting the rangeof the step variable, and setting other acquisition parameters. A generalized input parser interprets the input incontext-sensitive manner, where the meaning of each token depends on the valid tokens already accumulated. At
any point, a list of the valid responses may be requested
as a guide to the user.
Ftom the touch panel or keyboard, the user may initiate data acquisition, terminate acquisition, or temporarily pause during an acquisition sequence. After data is
acquired, display panels allow selection of fit and plot, options. The user may request displayed or printed plots, aswell as tabular formats. It is possible to specifically include or exclude selected data points, and have the facility
recalculate the fit parameters.
An auxiliary output
allows extended use of thesystem. Thus users may save data to disk files in various
formats for offiine analysis. Alternatively, users can reload
previously stored command strings, or variables and clata
files, for further online analysis and display.

Callable Routines
All of the actions that are accessible via the operator interface are also available to software control. This
makes it very easy to develop a layered application, using
well-established building blocks. Callable functions support setting up variables and data acquisition options, an cl •automatically acquiring desired data. Applications may
obtain acquired data, perform a fit and retrieve the fit parameters, or provide for a variety of displays and plots.
Some applications acquire data through specialized protocols, and then use the Correlation Plots for fitting ancl
display functions.

S13MMI13
Man-Machine Interface and Workstations

493

493

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S13MMI13

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI14ICONIC REPRESENTATION OF PARTICLE BEAMSUSING PERSONAL COMPUTERS

S.Dasgupta, D.Sarkar, C.Mallik
Variable Energy Cyclotron Centre, l/AF, Bidhan Nagar, Calcutta-64
of x momenta, as a function of x, but it
does not immediately produce any idea
about their correlations with the y-axis.
Conversely, the same inadequacy applies
for the y vs ~ ellipse. Therefore as far
as qualitative understanding of the beam·
is concerned, as a first impression, viewsof the ellipses .;_re not complete enough.
The mental process of a person doing the
optimizations has to be only analytical,
which is not a very comfortable situation.
Consequently, it was thought that a more
expressive diagram, which will convey a
qualitative
idea
about
all
the
4
dimensions of the beam-ellipsoid, should
contribute as a more friendly feedback to
the user ofatransport-optimization
procedure.
With the vastly expanding use ofcomputers with image graphics capabilities
by transport-line designers aud graphic
workstations as operators' consoles inaccelerator control, the3-Dgraphic
generation
capabilities
·Of
these
computers,
can be tapped in such asituation. The particle beam, i f could bemade visible together with all its angle,

Abstract

The
idea
of
representing
thecharacter of a charged particle beam byismeans of its emmittance ellipses,
essentially a mathematical one. For quick
understanding of the beam character in amore user-friendly way, unit beam cellswith particles having a uniform nature,
have been pictured by suitably shaped 3-D
solids. The X and Y direction momenta at
particular cell areas of the particle beamcombine together to give a proportionate
orientation to the solid in the pseudo 3-Dworld of the graphic screen, creating aphysical picture of the particle beam.
This
ls expected
to facilitate
thecomprehension of total characteristics ofa beam in cases of onllne control oftransport lines and their designs, wheninterfacedwithvariousray-tracing
programs. The implementation is done in an
IBM-PC environment.
INTRODUCTION

The practice of representing particle
beam in terms of the phase-space figures
at an axial location of the beam, iswell-established. The phase-space diagrams
can be either a plot between x/y andpx /py , where p x and p y denote momenta in x
and y directions respectively.Consequently
these 2-dimensional figures, are used toconvey informations about an entity which
exists in reality, in a 4-dimensional
phase-space consisting of x, p , y and pxyas the dimensions. Beam-line designers aswell as operators optimizing transport ofparticles through beam-line elements, very.
often refertothese
2 dimensional
projections idealised to ellipses,tostudy and optimise the transport of aparticle-beam. Any of these ellipses, eg.
x vs e ( = px/p, where p is thelongitudinal momentum), though conveys theinformation
about
distributionofaparticle-population with specific ranges

Figure1.

Two beamlets
momentawithdifferent

S13MMI14
496

Man-Machine Interface and Workstations
496

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP01

OBJECT-ORIENTED PROGRAMMING TECHNIQUESFOR THE AGS BOOSTER*
Joseph F. Skelly
AGS Department, Brookhaven National Laboratory
Upton, New York 11973

Abstract
The applications software developed for the control systemof the AGS Booster Project was written in the object-oriented
language, C + +. At the start of the Booster Project, theprogramming staff of the AGS Controls Section comprisedsome dozen programmer/analysts, all highly fluent in C but
no~ices in C + +. During the course of this project, nearly theentire staff converted to using C + + for a large fraction of
their assignments. Over 100 C+ + software modules are now
available both for Booster and general AGS use, of which alarge fraction are broadly applicable tools. The transition
from C to C + + from a managerial perspective is discussed
and an overview is provided of the ways in which object
classes have been applied in Booster software development.

Introduction
At the outset of the Booster Project,[1] management
decided to promote the use of object-oriented techniquesamong the programming staff. Our hope was to achieve
improved programming efficiency and greater maintainabilityof code through increased modularity. The C + + language
was chosen because of its accessibility to a staff fluent in C,
and beca_use it was well supported on the computing systemalready m place. Whereas prior efforts at in-house selfeducation in C+ + had yielded only very limited success, ourstaff now is very comfortable using C + +, and we consider
that our goals in promoting c+ + have been satisfactorily
achieved. During the past two years, our programmers haveaccumulated nearly 200 staff-months of experience with
C + +, and produced some 160 source-code modules totaling
more than 100,000 lines; of these, more than 80 are tool
modules which define more than 300 object classes. The
Booster was commissioned in June of this year; during thisperiod our software was exercised vigorously, and software
performance and user reaction were favorable. The reasonsfor this success will be discussed below.

. Environment
The AGS Distributed Control system (AGSDCS)
comprises a network of approximately 50 Hewlett-Packard/*Work perfonned under the auspices of the U.S. Department ofEnergy.

Apollo workstation nodes on a Domain token-ring network
which spans the AGS accelerator complex. Ten workstations
provide the operator interface at five consoles in the AGS
Main Control Room. About 15 workstations are used forprogrammer or physicist development nodes, and theremainder are used as control system consoles by engineeringand technician work groups among the accelerator staff, or as
data-collection servers in the accelerator complex. The
workstations run a Unix-like operating system and provide ahigh-resolution display, for which an internal Graphics User
Interface (GUI) standard for the programs has been
established.
The AGSDCS is interfaced to some 5800 accelerator
devices via more than 100 so-called "device-controllers" in
The device-controller layer ismore than 50 locations.
currently implemented with Intel Single-Board Computers(SBCs) in Multibus packaging.
Device-controllers areconnected to so-called "stations" via the GPIB (IEEE-48 8) bus;
stations are implemented either in Multibus SBCs (the older
AGS version) or in Apollo workstations (the new Booster
version). Access by high-level programs to the network ofaccelerator devices is supported by a library of toolkit routines
which permit a device to be referenced by just its name. The
library routines resolve the device address in the network by
reference to descriptor tables constructed from a relational
database which describes the entire control system.

Transition to C + +A number of factors are discussed here which contributed
to the successful transition of the staff to C + +. Experience
with this process suggests that each factor is important, andthat the absence of any one of them would have had a very
negative impact on its success.

Assignment Profile
Staff members were given independent software assignments
for the Booster Project, and permitted to develop them
individually. The opportunity to nurture a new project fromits inception without undue burden of prior developmentencouraged the staff to apply new techniques. In addition, it
was recognized early that many of the assignments required
common tools, and management fostered cooperative efforts

S14OOP01
500

Object Oriented Programming & Techniques

500

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Simplified Approach to Control System Specification and Design
Using Domain Modelling and Mapping.
G.A. Ludgate
TRW.MF, 4004 Wesbrook Mall, Vancouver,

The internal structure of the system-to-be-built, termed the
Object Communication Diagram, is comprised of both the staticand dynamic system-objects in the solution. Figure 2 shows anexample internal structure for Fig. l. Static objects are representation of conceptual entities in the solution (e.g. schedules,
lists etc.) while each dynamic object represents the dynamic
behavior of its associated Terminator Object, as seen throughtheir mutual interface (the infonnation flows between the
dynamic
the Terminator Object).

Abstract
Recent developments in the field of accelerator-domain andcomputer-domain mort..elling have led to a better understandingof the "art" of control system specification and design. It now
appears
to "compile" a control system specification to
produce the architectural design. The infonnatioo required bythe "compiler" is discussed and one hardware optimization algopresen:ted. The desired characteristics of !he hardware and
SQftware components of a distributed control system architecture
are discussed and the shortcomings of some commercial
produclS.
I. INfRODUCTION
on the gathermore emphasis has been
ing and validating of requirements for automated control systems
beforeare built [1, 2, 3, 4, 5]. Our earlier work reported on
theof the KAON Factory Central Control System(KF-CCS),
two emerging techniques in the application ofob)ect·-Ori<entl::d principles to requirements svecmcation
domain driven[2) and dynamic object modelling [3].
A re-examination of the problems encounteredthese two
contemporary techniques has led to a better understanding ofboth the use of domains in creating anda system
specification and of the design-processes used to transform thespe:cii1icatioo into executable code.
ooi;sible to "co.'llpile" a control sysrem from its"compilers" themi<:ro-oroieessor machine code) must be fxactly
described before the "compiler" can be created. With contemto
muuetnng approaches we oow haveconstruct such a complete description of the active elements thatform control
and to detennine an
strategy
for COiiflj;:JliW.ll!Jll

II. PROBLEMS WITH EARLIER APPROACHES
Dynamic object modelling [3] advocates, from the outset, thedetermination of the context of a system-to-be-built and its
presentation in the form of a Context(Fig. 1). A
Context
follows from an analysis of a problem, thespecification of a solution and the desire to implement thesolution as an automated system. This approach leads to an early
identification of external devices (Tenninator Objects) that are
to be interfaced to and controlled by the system. Only information flows between the system and the Terminator Objects areshown on a Context Diagram.The single bubble represents thesystem-to-be-built; boxes represent Terminator Objects.

V6T 2A3, Canada

Master
SystemSettings
ValuesConlllxt Diagrnm of the KF-CCS. The single bubble represents the system-to-be-built; boxes represent Terminalor Objects.
Fig. 1 A

During the KAONFactory Study the premature focussing on
KF-CCS systems-analysis [3] led to some difficulties with users
and reviewers appreciating the role of the (predominantly
software
KF-CCS in the much larger context of controlh'>..am production, and the affect of interacling KAON
tions between its Terminator Objects. AS uper-Context Diagram
was therefore created to show the "bigger picture" (Fig. 3). In
the KAON
interactions between Terminator Objects
will be due, for example, to the Master Timing System that will
determine (predominantly in hardware) the exact timing of all
beam related events e.g. beam transfers between any of the 5rings.

Domain driven modelling [2J, on the other hand, does not

require this premature move into systems-analysis. In the early

S14OOP02
Object Oriented Programming & Techniques

505
505

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S14OOP02

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP03

The Direct Manipulation Shell: Creating Extensible Display Page Editors
Michael E. Allen, Michael Christiansen
SSC Laboratory *2550 Beckleymeade Ave.
Dallas, Texas 75237

Abstract
Accelerator controls systems provide parameter display
pages which allow the operator to monitor and manipulate selected control points in the system. Display pages
are generally implemented as either hand-crafted, purposebuilt programs; or by using a specialized display page layout tool. These two methods of display page development
exhibit the classic trade-off between functionality vs. easeof implementation. In the Direct Manipulation Shell weapproach the process of developing a display page in a
manifestly object-oriented manner. This is done by providing a general framework for interactively instantiating
and manipulating display objects.

I. INTRODUCTION
We are developing a tool, known as the Direct Manipulation Shell
which wil! allow the construction of software applications in much the same way as modern hardthe user selects andware devices are constructed. That
combines together software components in an
plug-and-play fashion when
their applications
software. OMS provides an environment in which software
components are provided a.nd directly manipulated (hence
Direct Manipulation Shell)
the user.
A programming environment developed through DMS
contains software components which address the needs ofa single problem domain, e.g., accelerator parameter pagedevelopment. This can be contrasted to a traditional programming environment containing compilers, linkers, edidomain andetc., which support no specificprovide no domain specific support for applieations development. Using DMS, the user performing the applicationsofprogramming spends most of his time browsing
domain specific components rather than developing algorithms and data structures. It is assumed that this applications programmer is knowledgeable in the domain supported by the specific environment, not necessarily in thedomain of the computer sciences.
Theof OMS is to provide users with a software development environment in which they construct solutionsin problem domains about which they are concerned andknowledgeable. These domain experts are provided componeds that are presented and manipulated through terms
and concepts found in this problem domain. Using the facilities provided by DMS, programming experts develop
a set of interrelated software components which can be•Operated by the Univernities Research Association, Inc., for the U.S.
Department of Energy under Contract No. DE-AC02-89ER40486.

used to construct solutions to problems in this domain.
This process of constructing a programming environment
through DMS is similar to the process of constructing anexpert system [2] using an expert systems development
shell. When developing an expert system, a team of programmers and domain experts combine efforts to develop
a set of rules which address problems in a specific problem
domain. With DMS, a. team of programming and problem domain experts construct a set of software components
which can be accessed and manipulated through DMS. In
either case the user is provided with an environment which
can be applied to problem solving with little understandingof the underlying computing environment.
Of course, theses goals are not unique to DMS. Basically,
OMS provides an interactive, interpreted, object-oriented,
programming environment. Usually, such environments
have the following major shortcomings:
1. performance.

2. availability of third party, off-the-shelf "components".
3. performance.
For an accelerator control application (1) and (3) (and toa lesser extent (2)) can be killers. The DMS environmentis designed t.o specifically address these limitations. Thisis achieved in the current version of the DMS tool via theuse of a modified Common Lisp
interpreter,[lj.
has incorporate within it an object-oriented language constructs which allow classes to be defined and instances of XLisp object to be created. Our modifications
to XLisp enable the user to interactively create and manipulate instances of XLisp objects which in turn create
and manipulate instances of C++ objects. This is much
more than just afunction interface, because the objects thus created are now managed by the DMS environment. This means, for example, that much of the memory
management is taken care of automatically (garbage collection). Additionally, DMS knows about C++ data structures, so that unmodified C++ code can be linked directly
into the DMS environment. Additionally, because of theobject oriented extensions on the Lisp side, one can write
straight forward Lisp code without continually bothering
about how data is represented.
Within DMS one can move freely between the Lisp andC++ environments, taking advantage of the best features ofboth. In particular, one may take advantage of the speed
and availability of C++ class libraries within an interactive
Lisp programming environment. '\Ve have, for example,

S14OOP03
Object Oriented Programming & Techniques

511

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP04

Object Oriented Programming Techniques Applied to Device ACCRBS
and Control
A.Gatz, W.D.Klotz, J.Meyer
ESRF, BP 220
F-38043 Grenoble Cedex
FRANCE

1

Introduction

Device access and device control is one of the most important tasks of any control system. This is because control
implies obtaining information about the physical world byreading senS-Ors and modifying the behaviour of the physical world by sending commands to actuators. At theEuropean Synchrotron Radiation Facility (ESRF,
ref. (1]) effort has gone into designing and implementing amodel for device access and control using as much as possible the latest ideas and methods of Software Engineering.
One of the main contributions in recent years to Software
Engineering has been in the field of Object Oriented
Programming(OOP). Although the philosophy is not
new the refinement and application of this methodology
on a wide scale is. At the ESRF a model for device accessand control has been developed which is based on OOP
methods. This model, called the device server model,
is the topic of this paper. The device server model is written entirely in C and is therefore portable. It depends onno other software and can be ported to any machine where
there is a C compiler. Because the model is based on OOP
it presents a user-oriented view of the world as opposed toa software- or hardware-oriented view of the world.
This paper will describe the device server model. It will
describe the problem of device access and the advantagesof using OOP techniques to solve it. It will present themodel. The methodology used to implement OOP in thedevice server model called Objects In C (OIC) will be
described. An example of a typical device server at the
ESRF will be presented. The experience gained from thedevice server model will be discussed. The paper will conclude with a discussion on how the device server model
could be standardised to treat a wider range of problems.

2

The Device Access Problem

The problem which the device server model is designed tosolve is a problem which every control system is faced with.
The problem could be described as - how to provide accessand control for all the physical devices which represent themachine ?

Unfortunately there is no widely accepted industrial

standard for interfacing devices to computers. Althoughsome attempts have been made at defining an industrial
standard none of them have succeeded (see (2]). Thismeans that there are about as many ways to interface adevice to a computer as there are device suppliers.
The device access problem would be simple if a single
standard were adopted for interfacing. In reality however
this turns out to be too expensive because it involves extra
development costs for the suppliers.

3

The Device Server ModelAt the ESRF a unified model (called the device server
model) has been developed to solve the problem of device
access and control. It is unified for two reasons o it presents a single interface for upper level applications to all kinds of devices, ando it defines the framework within which to implement
device access and control for all devices.
The model can be divided into a number of basic elements - the device, the server, the Objects In C methodology, the root class, the device class, resource database,commands, local access, network access, and the application programmers interface.

3.1

The Model

The basic idea of the device server model is to treat eachdevice as an object which is created and stored in a process called a server.
Each device is a separate entity which has its own data
and behaviour. Each device has a unique name which identifies it in network name space. Devices are configured via
resources which are stored in a database. Devices areorganised according to classes, each device belonging toa class. Classes are implemented in C using a techniquecalled Objects In C. All classes are derived from one rootclass. The class contains a generic description of the device i.e. what actions can be performed on the device andhow it responds to them. The actions are made available

S14OOP04
514

Object Oriented Programming & Techniques

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP05

An Object-Oriented Implementation of the TRIUJ\tiF 92 :Mllz Booster
Cavity Control System
N.A. Wilkinson and G.A. Ludgate
TRIUMF, 4004 Wesbrook Mall, Vancouver B.C., Canada, V6T 2A3
Abstract
A 92 MHz auxiliary accelerating cavity has been
designed for installation inside the 1RIUMF cyclotron,
operating up to a maximum peak voltage of 200 kV. The
cavity doubles the energy gain per turn for acceleratinghydrogen ions in the energy region of 400-500 MeV, andreduces by 50% the stripping loss of the ion beam. The
control system for the booster comprises a PC-based processor
in a VME crate, for local control, and a 68030 processor withan ethemet connection as the interface to the 1RIUMF Central
Control System. The requirements for the booster control
system were established by an object-oriented requirements
analysis. Afterward, an object-oriented architectural design
step was used to produce the processor allocation of thedesign, which was then implemented using C, for the VME
processor, and a commercial database and screen generator
product, for the VAX user interface.
I. INTRODUCTION
The RF Booster consists of an RF cavity, an RF
amplifier, a transmission line connecting the amplifier to thecavity, a local control system and ancillary equipment The
RF cavity is made up of two symmetrical halves which aremounted on the lid and floor of the cyclotron vacuum tank andseparated by 64 mm to provide a region free of allcomponents. The accelerating voltage exerted by the RF
cavity increases from 0 kV at a beam energy of 330 MeV toa maximum of 150 kV at a beam energy of 520 MeV. The
RF cavity geometry is designed so that., when the booster isoperating, each ion in the beam receives two impulses during
its passage through the cavity. This energy gain enhances thetum separation of the beam, reduces the number of turns madeduring acceleration and reduces the beam loss due toelectromagnetic stripping.
During the design and development of the booster,equipment specialists implemented a local control system basedon an IBM-PC in VMEbus. Although this system met therequirements for local control of the booster by equipment
specialists located in the RF area, its design did not consider
the requirement for remote control by the cyclotron operators.
II. OBJECT-ORIENTED ANALYSIS
To identify the requirements for remote control of thebooster, an object-oriented requirements analysis was carriedout using the domain-driven specification techniques describedin [l]. For this analysis, the notation of the Yourdon
methodology with Ward-Mellor extensions[2] was used torepr~nt objects, their behaviour and their interactions.
Objects and their methods were represented by data flow

diagrams (DFDs), object behaviour was represented by statetransition diagrams (S1Ds) or control transforms, andinformation flows between objects were represented by control
and data flows. A relevant aspect of the object-oriented
methodology employed for the requirements analysis was theidentification of objects which would interact with the RF
Booster remote control system via infonnation flows only.
Such objects are known as terminator objects of the system.
As the only CASE tool available on-site was DECdesign,a CASE tool from Digital Equipment Corporation, this tool
was used to capture the models of the booster remote control
system.
The strict Yourdon-Ward-Mellor methodology
implemented by this tool did not easily accommodate theobject-oriented paradigm chosen for the requirements analysis.
As a consequence of this inflexibility, the desired goal of apurely object-oriented requirements document was
contaminated by tool-specific considerations.
The DECdesign verification utility, however, proved
invaluable in ensuring that control and data flows between
objects were consistent and in ensuring that the data dictionary
was maintained up to date.
Ill. THE RF BOOSTER REMOTE CONTROLSYSTEM
During the domain analysis it was recognised that
personnel operating the booster would play two roles in theirinteraction with the booster: that of a beam control operator,
whose only concern would be the affect of the booster on thebeam, and the role of equipment management operator, whose
concern was the management of the booster equipment.
These operator roles enabled the identification of the twodomains spanned by the RF booster remote control system:
the domain of beam control and the domain of equipment
management In the fonner domain, the requirements of theremote control of the RF booster by an RF Booster BeamControl System (RFB BCS) were examined and, in the latterdomain, the requirements for remote management of thebooster equipment by an RF Booster Equipment Management
System (RFB EMS) were examined.

A. The RFB Beam Control System
Given the preceding assumptions, the purpose of the RFB
BCS was described as follows:• to enable operators in the Cyclotron Control Room toremotely control the phase and amplitude of the booster, and• to provide operators in the Cyclotron Control Room with ameaningful display of the booster operating parameters
necessary for remote control and monitoring of the booster.

S14OOP05
520

Object Oriented Programming & Techniques
520

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP06

The State Manager: A Tool to Control Large Data-Acquisition Systems
Ange Defendini, Robert Jones, Jean-Pol Matheys, Pierre Vande Vyvre, Alessandro Vascotto
CERN, Geneva, Switzerland

Abstract
The State Manager system (SM) is a set of tools,
developed at CERN, for the control of large data-acquisition
systems. A dedicated object-based language is used to describe
the various components of the data-acquisition system. Eachcomponent is declared in terms of finite state machines andsequences of parametrized actions to be performed for
operations such as the start and end of a run. The description,
written by the user, is translated into Ada to produce a runcontrol program capable of controlling processes in a
distributed environment A Motif-based graphical interface tothe control program displays the current state of all thecomponents and can be used to control the overall dataacquisition system. The SM has been used by several
experiments both at CERN and other organizations. We
present here the architecture of the SM, some design choices,and the experience acquired from its use.

These messages constitute the interface between the SM andthe associated processes. The same interface is used by an
overall control program to send commands to the SM itself asshown in Figure L
SM program
Control
Program

SM objects

Tape
program

Trigger
programI. INTRODUCTION
Today's large data-acquisition systems are composed of anincreasingly large set of programs which prove difficult tocontrol. Furthermore, the different programs are notindependent but co-operate and need to be synchronized: forexample, they must be started and stopped in a given order.
Finally, a system composed of many different programs isdifficult to operate if one has to interact with each of these
programs.
The SM [1,2] is a neat and flexible solution to thisproblem. It is a tool for building distributed run-control
systems by means of a dedicated object-based language.
The system to be controlled is decomposed into a set ofobjects. Objects correspond to a part of the system: a programor a subsystem. Each object must then be described as a statemachine, its main attribute being its current state. The state
can take any value in a list of values declared by the user in
his SM program. An object can interact with other objects bysending commands to them. The command triggers theexecution of an action, which is terminated when the object
reaches a new state.
Each activity of the data-acquisition system to becontrolled should be handled by a single process. These
processes are called associated processes because they areassociated with an SM object. The SM communicates withthem via messages handled by the OSP package [3]. The SM
sends the commands triggering the execution of actions, andthe associated processes reply when they assume a new state.

Associatedprograms

Figure L The SM program and the external world.
The communication package deals with distributed
environments and thus allows commands to be sent toprocesses running on remote machines.
The objects are divided into two categories:- The associated objects are associated with a program
dealing with a device or an activity.
- The objects of the second category correspond to abstract
entities that fonn part of the description of the system. They
are internal to the SM.
The SM program written by the user is translated by the
SM translator into Ada [4). This Ada code is then compiled
and linked to produce an executable image. The execution ofthis image will activate the run control and establish thecommunication with the associated processes.

II. THESMLANGUAGE

A. Object declarations
The SM language contains declarations and instructions.
The declarations are used to define the name of an object, its
states, and actions. An example of a state machine for an
object 'RUN' is given in Figure 2.
The corresponding SM declarations are:S14OOP06
524

Object Oriented Programming & Techniques
524

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S15CSE01

CASE in CERN's Accelerator Sector
A. Albrecht (SL), A. Cabas-Alonso (AT), F. Chevrier (ECP), A. Daneels (AT), Ch. Delamare (CN),
G. Ferran (CN), S. Foffano (MT), P. Heymans (AT). J.P. Matheys (ECP), D. Manglunki (PS),Y. Marti (SL), D. Missiaen (AT), G. Moorhead (CN), 0. Novakov (AT), T. Pettersson (PS),J. Poole (SL), M. Pozzato (SL), J.P. Quesnel (AT), S. Santiago (CN), J. Schinzel (AT),N. Segura-Chinchilla (AT), C-H. Sicard (PS)
Presented by A. Dan eels (AT)
CERN, European Organization for Nuclear Research, 1211 Geneva 23, Switzerland
Abstract
As in the software industry where computer aided software
engineering (CASE) methodologies and tools are commonly
used, CERN endeavours to introduce this technology to
improve the efficiency of designing, producing andmaintaining software. A large project is currently underdevelopment in the administrative area whereas a dedicatedgroup has been set up to evaluate state of the art techniques forsoftware development relating to physics experiments. A
similar activity, though on a smaller scale, has been initiatedin the accelerator sector also in view of the large amount ofsoftware that will be required by the LEP200 and the LHC
projects. This paper briefly describes this technology and gives
an account of current experience with the use of CASE
methods and tools for technical projects in the accelerator
sector at CERN.

not including numerous developments that have not beenaccounted for. The annual maintenance effort is estimated to bearound 15% of the development effort and exceeds the
production capacity of the groups in charge. Here, maintenanceis defined as software repair and update resulting from achanged functional specification of the software product. For
each new development the volume of the software increases
because more sophistication is required. By the time the LHC
is approved, the demand for application software may well be
two to three times higher beeause of increased functionality,
increased information volume, more severe execution time
constraints due to the superconducting nature of the machine,
and higher reliability [3]. Even if the groups in charge manage
to develop such large packages with the help of professional,
voluntary and temporary staff, they will only be able tomaintain it if software of sufficiently good quality is produced
so as to dramatically reduce its maintenance cost.

1. lNIRODUCTION

2. WHAT IS CASE ?

Software engineering is the application of techniques whichlead to the implementation of better quality software. It
implies a planned process of producing well-structured,
reliable, good quality, maintainable software systems whichcorresponds to the users' needs, within reasonable time frames[l].
This definition suggests that software engineering includes
a good deal more than just producing computer programs andthat good software development includes documentation,
databases, operational procedures, etc. Furthermore, it focusses
the planned aspect of the process: as any other engineering
discipline, software production should be properly managedwith scope definition, specification analysis, cost estimation,
production plans, role distribution, etc.
According to industry statistics, 75% of custom softwaredevelopment projects are rejected because they came either toolate to be useful or did not correspond to the users' needs.
However the complexity of application software grows
continuously and today's average business package takes
32,000 man-days, i.e. 160 man-years to develop [2]. This is
not dissimilar to the effort spent at CERN on application
software for accelerators. Indeed, in the eighties at least
500 man-years were invested on controls and databaseapplications for the PS accelerator complex, SPS and LEP,

CASE stands for Computer Assisted Software Engineering.
For each new software project the engineer is recurrently
performing a number of similar activities: collecting
information from his client, organizing that information, crosschecking with the client, etc. The process is systematic,
iterative and proceeds in increasing degree of detail. A numberof methods and procedures could be derived which, because of
their recurrence, would be more efficiently executed if assisted
by computer programs. Software tools were thus developed toassist the software engineer in collecting, organizing, storing,
retrieving and cross checking that information throughout thedevelopment process of his project. The information is
introduced through graphical and alphanumerical user interfaces
and recorded in a repository, possibly a database management
system, so that it is available throughout the production life
cycle for complementing, checking and various administrative
operations.
CASE is introduced in order to encourage better quality
designs, to increase productivity and to render software projects
more manageable. Better quality software leads to reduced
maintenance: industrial companies e.g. BBC, now ABB, claim
to be able to reduce the maintenance to 2% of the development
cost by using such tools [4].

S15CSE01
528

CASE and Software Engineering528

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Automation From Pictures: Producing Real Time Code froma State Transition Diagram*
Andrew J. Kozubal
Mail Stop H820
Los Alamos National Laboratory
Los Alamos, New Mexico 87545
the CASE environment and translate it into SNL syntax.
Below, we describe the salient features of the SNL, andexplain how the translator is used to produce a complete
SNL module from the STD.

Abstract
The state transition diagram (STD) model has been
helpful in the design of real time software, especially withthe emergence of graphical computer aided software
engineering (CASE) tools. Nevertheless, the translation of
the STD to real time code has in the past been primarily amanual task. At Los Alamos we have automated thisprocess. The designer constructs the STD using a CASE tool
(Cadre Tuamwork) using a special notation for events andactions. A translator converts the STD into an intermediate
state notation language (SNL), and this SNL is compiled
directly into C code (a state program). Execution of the state
program is driven by external events, allowing multiple state
programs to effectively share the resources of the hostprocessor. Since the design and the code are tightly
integrated through the CASE tool, the design and code
never diverge, and we avoid design obsolescence.
Furthermore, the CASE tool automates the production offormal technical documents from the graphic description
encapsulated by the CASE tool.

I.

II.

We designed the SNL to be consistent with the STD
methodology and applicable to the existing run timeenvironment that we use at the Los Alamos National
Laboratory.[6-8] Following the Mealy convention for STDs,
we specify both the events and the actions on the transition
between states, and allow only the state name to appear in
the state as in Figure I.

I{ tum_light_off }State Name

~ Event Statement

INTRODUCTION

Structured analysis and design methods often make useof the state transition diagram (STD) to model real timesystems.fl] A CASE tool, such as Cadre Teamwork/RT{2],can partially automate the STD methodology, but the
programmer is left with the task of converting the STD into
run time code. The programmer takes into accountnumerous factors, such as task priority, task synchronization,and pending for multiple events, to produce efficient code,and often the resulting code bears little resemblance to the
STD. Using a two-step procedure, we have achieved
significant automation of this process.
The translation of the STD into code is based on work
done previously to develop a language that is based on the
STD paradigm. The state notation language (SNL) [3] wasdeveloped to simplify programming of time-constrained
sequential operations that are driven by events. Duringextensive experience with the SNL on the Ground Test
Accelerator and the Advanced FEL at Los Alamos,[ 4,5] the
SNL evolved into a powerful tool for implementing realtime, automatic control. Subsequently, we developed a tool
to capture relevant coding information about the STD within

STATE NOTATION LANGUAGEv < 2.0{ turn light_off }v > 2.5{ turn.Jight_on } " 'On

ActionFigure 1. Example of a State Transition Diagram.
In the above example there is only a simple relational
expression, which involves one event, the change in the valueof variable "v". The SNL is designed to handle more
complex event expressions, as well as multiple events.
Events may be associated with database channels and timedelays. Actions may include calculations, outputs todatabase channels, and calls to procedures.
Rather than invent yet another new language, we based
the SNL on a comprehensive subset of C, along with somerelatively minor additions to handle events, actions, andstates. We simplified the coding by allowing the programmer
to associate run time database channels with a C variable.
Figure 2 shows the complete program that implements the
STD in Figure I in SNL syntax.

*Work supported and funded under the Department of Defense,
US Army Strategic Defense Command, under the auspices of the
Department of Energy.

S15CSE02
CASE and Software Engineering

535

535

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S15CSE02

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS01

SSC Lattice Database and Graphical Interface
C. G. Trahern and J. Zhou
Superconducting Super Collider Laboratory
2550 Beckleymeade Ave., Dallas, Texas 75237•

Abstract
The SSC lattice database and the graphical tools used
to access it are discussed.
I. INTRODUCTION

When completed the Superconducting Super Collider
will be the world's largest accelerator complex. In orderto build this system on schedule, the use of database technologies will be essential. In this paper we discuss oneof the database efforts underway at the SSC, the lattice
database. The original work on this database system began at the SSC Central Design Group and is described inreference [1].
The SSC lattice database provides a centralized source
for the design of each major component of the accelerator complex. This includes the two collider rings (top andbottom), the High Energy Booster (HEB), Medium Energy Booster (MEB), Low Energy Booster (LEB) and the
LINAC as well as transfer and test beam lines.
These designs have been created using a menagerie ofprograms such as SYNCH, DIMAD, MAD, TRANSPORT,MAGIC, TRACE3D and TEAPOT. However, once a design has been completed, it is entered into a uniform
database schema in the database system.
In section II we further discuss the reasons for creating
the lattice database and its implementation via the commercial database system SYBASE[2].
Each lattice in the lattice database is composed of a setof tables whose data structure can describe any of the SSC
accelerator lattices. This data structure will be discussed
in section III.
In order to allow the user community access to the
databases, a programmatic interface known as dbsf (fordatabase to several formats) has been written. This interface is the subject of section IV. dbsf creates ascii input
files appropriate to the above mentioned accelerator design programs. In addition it has a binary dataset output
using the SDS (Self Describing Standard) data discipline
provided with the ISTK (Integrated Scientific Tool Kit )[3]software tools.
In section V we discuss the graphical interfaces to thelattice database. The primary interface, known as OZ, isa simulation environment as well as a database browser.
OZ has been created using techniques of object oriented
modelling and coded in C++ using the ISTK software"Operated by the Universities Research Association, Inc., for the U.S.
Department of Energy under Contract No. DE-AC35-89ER40486.

Figure 1: Control and Display Windows of OZ
tools. OZ is SSC specific in that it presents a geometricalview of the collider complex from which one may select thelattice of interest. This geometrical data is also the sourceof the data used to site the complex geographically. OZ
is an interactive simulation environment in which the user
can change various parameters such as a steering magnet's
field strength and then see whether a beam of given emittance will survive its propagation within a fixed spatial
aperture.
In addition to the geometrical view of the complex, one
also needs a more abstract view of a lattice structure, andthis is provided by a program known as LATVIEW. Because the beam line hierarchy implicit in an accelerator
design can be highly nonintuitive, LATVIEW gives an interactive graphical view of this hierarchy.
IL PHILOSOPHY
We have implemented the lattice database using a relational database management system (RDBMS). The particular software system currently used is SYBASE operating within a UNIX workstation computing environment.
By putting the lattice information within a RDBMS tied
to a network, essentially universal access to the data canbe supported. In addition by maintaining a uniform description of the lattice information, various groups such asmechanical and civil engineering, survey and alignment aswell as diagnostics and simulation can be coupled to thesame data in an efficient manner thus reducing the probability that different groups will use incompatible design
information.
In addition, because accelerator design is usually donewith a variety of design codes such as the ones mentioned
earlier, a lattice database of some kind is the only way to

S16MS01
538

Modelling and Simulation
538

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS02

Framework for Control System Development*
Carl Cork and Hiroshi Nishimura
Lawrence Berkeley Laboratory, 1 Cyclotron Road, Berkeley, CA 94720

Abstract
Control systems being developed for the present generationof accelerators will need to adapt to changing machine andoperating state conditions. Such systems must also be capableof evolving over the life of the accelerator operation. In thispaper we present a framework for the development of adaptive
control systems.

I. INTRODUCTION
Several of the new generation of control systems hardware
being developed today have the capability of fast, sophisticatedcontrol at all levels in the control hierarchy[1][2]. These systems are typically hierarchical and highly distributed withextremely high J/O throughput.
We have initiated the design of a framework for control system development which can accommodate the new architectures. This paper will present requirements, design decisions,and specifications that we have devised for this framework.

REQUIREMENTS
A. Adaptive'The control system must be adaptive. It must be capable ofgrowth, evolution. and learning (supervised and self-taught).
'The software for these systems is complex and generally incontinuous development. The control system must be capableof growth during both commissioning and operational phases.
Many new control system algorithms such as model-based
control, expert systems, neural networks, and fuzzy logic are
emerging which look very promising in the accelerator control
environment.[3][4][5][6]. A mechanism is required which iscapable of evolution to accommodate these new control theories. The system must also be capable of arbitrarily complex
combinations of these algorithms.
Most of these new control system algorithms are capable ofeither supervised or self-taught learning, This should prove to
be extremely useful as an aide to finding 'golden orbits' in storage rings or as a means of reducing the complexity of data presented to the operator. The control system must facilitate thismechanism.

B. HierarchicalThe control system must support a hierarchical control
structure. It must be capable not only of supporting the 'standard' supervisor-cell-local type of hierarchical control[7], butalso each layer must be divisible into local subhierarchies. This• nlis worlc wu supported by the US DOE under Contract No.

latter requirement facilitates the incm:poration of cascaded andadaptive control algorithms.

C. Distributed
The control system must support the underlying distributed
hardware.
Many computer systems provide basic networking support.
The control system must also incoiporate mechanisms for theregistration of computing services, the automated association ofclient and server, and the unifonn representation of data transmitted between heterogeneous systems.
The control system must be designed to accommodate theknown features of distributed control - such as error detection
and recovery, virtual time synchronization. nondeterministic
networks, concurrency, resource protection. and bandwidthlimited messaging.

D. Operational Continuity
The control system must support operational continuity. It
must provide for dynamic, and transparent switching between
compatible modules without interrupting operation.
'D:ansparent switching is required to permit the exchange ofcontrol modules in the event where the system operation
exceeds the bounds of the previous controller. This should bepossible without bringing the system down and without leaving
the machine uncontrolled. Sufficient machine state information
should be transferrable to provide for 'bumpless' switching.

E. Dynamic Association'The control system must support the dynamic association of
applications. Links between the control system and the application should be redirectable during normal operations. This isessential to provide for independent development of associatedmodules and also to provide support for the adaptive and operational continuity requirements listed above.
Dynamic association permits both application and control
modules to be constructed without prior availability of the associated modules. Moreover, for client-server associations, thelink process should not require specific knowledge of the server
module (capability-based binding). It should be sufficient tospecify the type of module and its interface, leaving the association mechanism to a third intermediate process.

F. Universal Graphical API'The control system must support a universal graphical application programming interface (API). Regardless of the operating system, windowing system, or window manager, thegraphical application programming interface should be identi-

DE-AC03-76SF00098

S16MS02542

Modelling and Simulation
542

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS03

The LEP Model Interface for MAD
F. Christoph Iselin
CERN, SL Div.
CH-1211 Geneva 23
Switzerland

Abstract
During machine studies and trouble-shooting in the LEP
machine various optical parameters must be computed,
which can be found quickly using the MAD program. However, the LEP operators are not all well acquainted with
MAD. In order to ease their task, a simple interface called
the LEP model has been written to run on the Apolloworkstations of the LEP control system. It prepares jobs
for MAD, sends them to a DN 10000 node for execution,and optionally plots the results.
The desired machine positions and optical para.meters
vary between LEP runs. The LEP model contains a powerful selection algorithm which permits easy reference toany combination of positions and optical parameters in
the machine. Elements can be chosen by name, by sequence number, or by element class. The choice of optical
functions includes closed orbit, Twiss parameters, betatron phases, chromatic functions, element excitations, andmany more. Recently matching features have been added.
Communication with the control system and with MAD
uses self-describing tables, i. e. tables whose columns a.relabelled with their name and a format code. Experience
with this LEP model interface is reported.

1

Introduction

the database a structural description of LEP is available
which is formatted in MAD input language.
For equipment control the access to the Oracle databaseis too slow. A set of files, known as the "reference data set",is thus extracted and stored in a. file server. Most of thesefiles are self-describing tables, known as TFS tables (Table
File System (5]). Each table has an arbitrary number ofdescriptors, and each column is labelled with its name andformat code.
The status of equipment, e. g. the magnet excitations,or the RF cavity settings, can be acquired via. specialized
programs and is usually stored in TFS format. TFS tables
can also be sent to LEP to modify the settings of equipment.

1.2

The MAD program [2, 3] has been used extensively for thedesign of LEP. It is based on a "standard language" [4),used to describe the machine structure, and to request various computations on this structure. The language is designed to make communication with a human user easy.
For communication with other programs MAD also understands TFS format.
In the framework of the LEP Model Program MAD
serves the following purposes:• Compute the closed orbit,

This section describes those aspects of the LEP control
system and of MAD which are relevant to the LEP model
program. The second section outlines features of the LEP
model program. The third section discusses implementation, and the last two sections present future plans andexperiences with the program.

1.1

MAD seen from LEP Model

LEP as seen from LEP Model

The LEP control system [1] is based on a network of
Apollo workstations connected in a token ring network.
The workstations are running under UNIX. They talk to
the LEP machine over various links and microprocessors.
For time-intensive tasks the network contains an Apollo
DN 10000 computer, whose speed is a.bout a factor 1/2 ofthe IBM 3090.
The descriptions of the LEP machine and of its possible
optical configurations reside in an Oracle database. From

• Compute optical functions over parts of the machine,• Match optical functions to specific conditions,11

Calculate global pa1ameters of LEP,

11

Change machine parameters to study their effect.

2

The LEP Model Program

2.1

Tasks

Based on the above, the LEP Model Program must
• Use the reference data set to build menus of available
optical configurations and to present them to the user
for choice. In this way the piogram needs no changes
if new configurations are installed. The proposed default is taken from a file known as the LEP Run-Table.

S16MS03546

Modelling and Simulation

546

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS04

Optimization of Accelerator Control
N. D. Vasiljev, I. V. Mozin, V. A. Shelekhov
D. V. Efremov Scientific Research Institute of Electrophysical Apparatus
St. Petersburg 189631 USSRI.

INTRODUCTION- correction currents of beam orbit.
Process of intensity change is characterized by spontaneous
Expensive exploitation of charged particle accelerators is drift (10 - 12% shift), which can be compensated by varying ofinevitably concerned with requirements of effectively obtaining the above mentioned variables. Dispersion of an interference isof the best characteristics of accelerated beams for physical selected in accordance with a noise level, reduced by averaging
experiments.
of beam intensity measurements at the accelerator to 3%.
Criteria of preliminary selection of optimization methods
One of these characteristics is intensity. Increase of
intensity is hindered by a number of effects, concerned with the were algorithm discreteness, caused by cyclic processes in theinfluence of the volume charge field on a particle motion accelerator, as well as convergence in conditions of substantial
dynamics in accelerator's chamber. However, ultimate noises, high speed, minimality of spread in magnitudes of an
intensity, determined by a volume charge, is almost not output value during tuning, compactness of control program.
An important peculiarity, determining selection of aachieved for the most of the operating accelerators. This fact iscaused by losses of particles during injection, at the initial method, is a problem of creation of adequate mathematicalstage of acceleration and during extraction. These losses are description, that forces us to consider an object as a "black
caused by deviations the optimal from real characteristics of the box". In this case it is necessary to use search step methods.
It should be noted, that for the use of these methods aaccelerating and magnetic system. This is due to a number ofcircumstances, including technological tolerances on structural necessary condition of object parametrization is satisfied. The
elements of systems, influence of measuring and auxilliary condition consists in definiteness of controlled variables,
equipment and beam consumers' installations, placed in the whose varying enables reaching of extremum.
closed proximity to magnets, and instability in operation of
As competitive methods have been selected method oftechnological systems of accelerator.
sequential simplex planning, including automatic selection of aControl task consists in compensation of deviations of step, and methods of random search in modifications:characteristics of magnetic and electric fields by optimal selec- with estimation of gradienttion of control actions. As for technical means, automatiza- with self-learning
tion of modem accelerators allows to solve optimal control- with punishment of randomness
problems in real time. Therefore, the report is devoted to
Values of methods parameters, ensuring a stable converoptimal control methods and experimental results.
gence and the highest speed in conditions of interferences atmodels (I) have been determined at the first stage of the studII. METHODS AND PRINCIPLES OF
ies. In this case a higher speed of the method of sequential
simplex planning and higher reliability of extremum search
CONTROL ORGANIZATION
may be noted. One should consider a higher sensitivity in estiTasks of the accelerating complex systems control are mation of direction near the extremal zone and complete set ofstated as tasks of extremal control. The following stages may an operating program as the advantages. It is obvious, that it
be determined in solving of these tasks:
is extremely important to know efficiency characteristics of apriority selected optimization methods, obtained in conditions,- study of accelerator as an object of automatic optimization;- selection of methods of optimization and tracking of near to existing at the object. Comparative studies with theextremum;use of models were carried out in the following conditions:- comparative study of methods, using models, which have
Task of maximization of a single-extremum scalar
the main peculiarities of the control object;
function- synthesis of extremal control algorithm and procedure ofestimations of automatic adjustment efficiency at operating
I(X) = E~ {Q(X,~)}
accelerator.
Solution of a task can be shown as an example of extremal in situation of noise is considered. Here, X = (xi, ····· Xn) is acontrol of accelerated beam intensity for a prown synchrotron vector of controlled variables, which are subject to determinaat the Institute of Theoretical and Experimental Physics tion. Functional Q(X,~)
I(X) + ~ is considered to be(Moscow).
measured during optimization. Here ~ is a random value, disIntensity of a beam, injected into the ring, is a function of tributed normally with the expectation, equal to zero, and
11 independent variables, normalized with respect to injector
dispersion cr2.
current:
Extremum of the function I(X) is determined in the speci- electrostatic injector voltage;fied region- injection field intensity;- radio frequency adjustment in the fonn of delay of the masterminmaxclock start;
Xi < Xi < Xi
i 1, 2 ····· n==

S16MS04550

Modelling and Simulation
550

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

MODELLING AND O?'.I'IMIZATION OF BEAMS DYNAJvlICS IN LINAC
N.Eriamenko, D.Ovsyannikov, V.Kabanov, A.Zhabko
St.Petersburg State, St.Petersburg, 198904, USSR
Moscow Radioteclmical Institute, ?fioscow, 113519, USSR
Abstract

accelerating, bunching and focusing
for charged particles beams.
The longitudional dynamics of the beamin accelerators with drift tubes may be descx·ibed by well known equations

Problems of accelr,ration and focusing inlinear acceleratirs are consideree •.• c;aneralmathematical problem of charged. ;:iarticle beam
control is formulated, r.Yethods and ulgori th'J'Js
of solving these problems are developed. Problems of mathematical simulation of beam dynamics are discusGed in detail. So1ne be1.vn quality functionals rlependinv on all inrticle
tracks are propoased. Mathematical methods
are used forparameters of forming
systems. Designed codes allow to simulate
optimize beam dynamics.

This

(3)

where D is enercy and :f is particle rihnse,E [o,is longitudional coordinate,
L is the length of the structure. In the equation (J) piece-wise constant function c{ (J)is defined by formulas5

ct (5)
ci2 ----- -r--"1I
I~ealiza-report is devoted to thec{Ition ofaporonch to problem of dynamical system trajectories contl'ol in acceleandst:ructures.
Let us consider thesys~em0oftial equatios

I

I

I

I

I

I

I

I

J.J. A fa-.. fl,_ sd (S) =to,I < [} ,_.,j!,J.
-et l, ~ E[j.!i_ •f J;

I,= l,"'?

N~}Jo= 0; PN L.

and proportional to intensity of

X=f(t,X,u),where t is time, X is Rn vectir<1)phase co-ordinates, u is R~ control vector andisvector function.
e assume thatsyst
(1)
has the solution
X =- X (t. ,X 0 ) with initialconditions X(to,to,Xo) X0 for X0 EM 0 , whertc:
Mo is the set of inj tial values, Let us denote Mt,LI the shift of set Mo throuf'h tra,jectories of system (1). Let us sunpose thatthe function .P ( t) ~ 0
is the system ( 1)integral invariant and functionscp(t,X,f) ar.d
G(X,f) are given and non-negativ.
The main problem is to find the control
u = u (t), tE [t ,T], that gives infimum tothe functional

field.,Let us suppose that energy
phase Y' of particle·s at the end ofaccelera-

tir areparticles

given or equal to averageenergy and phase correspondingly. The minimization of functional

I=~[a(rL -if+&(~L-~) ]d~LcHL
2(4)

Mt,c1.
that characterizes the beam at the end of accelerator, provides optimal parameters.
Let us consider the radial motion now.
Let variables ~ and 2€. are reduced radial
coordinate and velocity of a charged particle
correspondingly. 'rhen equations ( J) are cop led with systemT

I=~ icp(t)t,f(t,Xt))dXtdt+ JG(Xrf(T,XT))dXT. (2)to Mt u'J'hi's general

(5)

MT,LI

apnroach is used for the
charged particles bc;am control in LINAC [1,2].
Let us consider ~ormulations of cotrol
problems relatedwith formatingof required

where pi'3ce-wise function

U (j)of solenoid longitudional

magnetic field. To

is intensity

S16MS05
Modelling and Simulation

555
555

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S16MS05

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA01

Development of a Diagnostic System for Klystron Modulators
Using a Neural Network
M.Mutoh, T.Oonuma and Y.Shibasaki
Laboratory of Nuclear science, Tohoku University
1-2-1 Mikamine, Taihaku-ku, Sendai-shi, 982, Japan
I.Abe and K.N akahara
KEK, National Laboratory for High Energy Physics
1-1 Oho, Tukuba-shi, Ibaraki-ken, 305, Japan

Abstract
The diagnostic system for klystron modulators using a neuralnetwork has been developed. Large changes in the voltage andcurrent of the main circuit in a klystron modulator wereobserved just several ten milli-seconds before the modulator
experienced trouble. These changes formed a peculiar patternthat depended on the parts with problems. Diagnosis was
possible by means of pattern recognition. The recognition testof patterns using a neural network has shown good results. Thissystem, which is built in a linac control system, is presently
being operated so as to collect new trouble patterns and to carryout tests for practical use.

L INTRODUCTION
In the electron linac, high-power klystrons are used as anamplifier that provides rf power to accelerate electron beams.
Five modulators driving five klystrons are installed at Tohoku
University's 300 MeV electron linac.
Since a klystron modulator, which generates pulsed power
output of high voltage and a large current, is operated under
severe conditions, it has problems most frequently among thedevices in a linac. The Tohoku linac is at fist adjusted by theaccelerator group and is then operated under regular conditions
by experimentalists who use the linac for their experiments.
However, they are not always specialists in the accelerator
field. When the various devices comprising a Iinac haveproblems, it is necessary to install support systems for linac
operation in order to suitably dispose of these problems and tocontinue linac operation. Therefore an expert system for the
diagnosis of beam operation [l] and the diagnostic system for a
klystron modulator have been developed.
In designing this system, it was noticed that large changes inthe voltage and current of the main circuit in a klystron
modulator existed just several ten milli-seconds before themodulator had a problem. These changes formed a peculiar
pattern that depended on the parts with problems. Someinteresting patterns were observed in preliminary tests [2].
Diagnosis was possible by means of pattern recognition. A
neural network having an excellent ability for patternrecognition was used for comparisons between learned andactual patterns. It was useful to apply the neural network to thissystem in order to improve the accuracy of the diagnosis, tosimplify diagnostic programs and to reduce the development
period. In order to increase the accuracy of this system, moretrouble patterns should be learned; as of now, very few patterns

PFN

PULSE
'IRANSFORMERIVRTIIYRATRON
Fig.1. The klystron modulator circuit.

S17AIA01
558

Al Applications
558

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA02

Diagnostic Expert System in the PF LINAC

Isamu Abe, *Masaharu Kitamura and Kazuo Nakahara
Photon Factory, National Laboratory for High Energy Physics (KEK)
1-1, Oho, Tsukuba-shi, Ibaraki-ken 305, Japan*Department of Nuclear Engineering, Tohoku university
Aramaki-Aza-Aoba, Sendai, Miyagi 980
Abstract
A prototype diagnostic expert system (ES) was developed
for the Photon Factory 2.5-GeV electron I positron LINAC
The ES has been on-lined with theinjector system.
conventional linac computer network for receiving real data.
This project was undertaken in an attempt to reduce the linac
operator's mental workload, diagnosis duties, and to explore
Artificial Intelligence (AI) technologies.
The outlook for ES and its problems, and what has beenachieved are outlined in this presentation.

theories for problem solving, an expert system seems to beappropriate. When there are several candidate procedures, or
algorithms, involved in problem solving. Also, ES should be
useful and more efficient than conventional programming.
Since most ES are flexible, if we change the physicalstructure of the accelerator, the K/B can be gradually extended
by adding new knowledge while being refined. Programming
costs will be minimized by using ES. This is the essential
advantage of an expert system.

Ill. Definitions of AI
I. Introduction
Diagnostic problems are relatively well understood both
empirically and theoretically. A variety of shells / tools areavailable on the market to facilitate the implementation ofdiagnostic systems. We have developed several diagnostic ES
for the LINAC and some are now under operation. Having
gained experience through previous projects, we built a new
hybrid ES this time. The application described here is an ES
for the injector system of the Photon Factory (PF) LINAC[l4], which is being operated a total of 5000 hours per year,
making injections to the PF storage ring and the 1RISTAN
e+/e- collider. Accelerators (LINAC) are complex devices,
We have beenusing many thousands of components.
looking for appropriate expert system shells and tools withwhich we can easily and rapidly establish an expert system.
For several years, a small ES based on a personal computer
was used for exploring applications of AI techniques. A
prototype diagnostic system has been built in order todetermine whether or not the various problems can generally
be solved using an ES frame-work; a knowledge base (K/B) for
the accelerator domain and task analysis were also investigatedin this project.

Some people think that "AI by itself can solve all of the
problems." We must be very careful concerning this idea AI
is not magic, and its capability is still limited in solving
practical problems . On the other hand, there are other people
who believe that AI can do nothing worth while at all. We,
thus, need to define AI before any discussion.
We have seen many definitions. People's dreams are big, andthey could have answered that "Artificial Intelligence is thescience of constructing a thinking machine."
Marvin Minsky gave a new definition: "Artificial
Intelligence is the science of making machines do things thatwould require intelligence if done by men".
Today, the abbreviation "AI" is used with the meaning of"Advanced Information processing technology". From thisperspective, AI will certainly become more and more
important in the Accelerator domain.
We discuss here only knowledge-based systems which are asubset of AI technology. In most cases, ES is a rule-based
production system which dispenses with specialized
knowledge of a well-defined domain.
It is said that ES belongs to the most importantdevelopments of a new type of software generation.

II. Why we need ES for the accelerator

IV. History of AI

When any fault or trouble occurs in the LINAC, theoperator is required to recover the system, even at midnight,
even though, he may not be an expert regarding many of the
fields required to diagnose the specific trouble.
Diagnosing faults in a complex process is a task that
requires experience and considerable knowledge in many fields.
Thus, any assistance given to the linac operator regarding
diagnosis and operation is extremely desirable.
When human experts are scarce, and when problems must
be solved for which there are no established solutions or exact

It should be mentioned that AI is still very young.
Fundamental AI researches are necessary for continuously
defining and realizing Al's future.
The term "Artificial Intelligence" was invented at theDartmouth Conference in 1956, where John McCathy(Stanford) and Marvin Minsky (from :MIT) were participants.
After that, a new field of research was born.
The feasibility of the first expert system. was demonstrated in
the 1970's under the leadership of Edward Feigenbaum. There
have been many successful ES in the past. If we classify the

S17AIA02
562

Al Applications
562

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA03

GLAD: A GENERIC LATTICE DEBUGGER•
Martin J. Lee
Stanford Linear Accelerator Center, Stanford University, CA 94309
Abstract
Today, numerous simulation and analysis codes exist for the design, commission, and operation of accelerator beam lines. There is a need to develop a common
user interface and database link to run these codes interactively. This paper will describe a proposed system, GLAD
(Generic LAttice Debugger), to fulfill this need. Specifically, GLAD can be used to find errors in beam lines duringcommissioning, control beam parameters during operation,and design beam line optics and error correction systems
for the next generation of linear accelerators and storagermgs.

THE TAO OF MODEL-BASED CONTROLThe Tao of Model-Based Control is a generic way ofcontrolling beam parameters using modeling and simulation codes interactively during commissioning and operation of a beam line.
Beam Line Design and Beam Control Codes
Every accelerator or storage ring system consists ofa charged particle beam propagating through a beam line
composed of bending, focussing, and accelerating elements.
In the design stage, the effects due to errors in the beamline are simulated using modeling codes. For example,
modeling codes are used to design an orbit correction system consisting of dipole correctors and beam position monitors (BPMs). During commissioning and operation, thesesame modeling codes can be used to find the errors in the
beam line elements and to control beam parameters interactively.

INTRODUCTION

I have been asked to present a paper on Model-Basedmethods and Artificial Intelligent (AI) methods for accelerator control. Being a teacher of T'ai Chi, a system ofChinese exercises based on the Yin and Yan principle, I
am familiar with the Taoist saying:
Tao is Yin and Yan

High-level and Low-level Software

It is natural for me to think of Model-Based methods
and AI methods as one system of methods-the GLAD
system. While thinking about the GLAD system, I madea list of the Yin and Yan pairs associated with accelerator
control:Yin
Beam line
DesignHigh-level
Commission
Play backBeamElement
Look
Off-line
Inverse-ModelingInterpretation
Automatic
Solution
Rule-based
Prediction
FutureWaste Prevention

Yan
Beam
Control
Low-level
Operation
Real time
Parameter
Strength
AdjustOn-lineModeling
Analysis
ManualProblem
Trial-and-error
Validation
Present
Risk Reduction

The software of a Model-Based control program can bedivided into high-level and low-level software. High-levelsoftware is the modeling and simulation code for the designand control of an accelerator beam line. Low-level softwareis the application code for setting the strengths of the beamline elements and measuring the beam parameters.
Commissioning and Operation Goals

The purpose of this paper is two-fold: (1) to describe
the Model-Based control philosophy in terms of these Yin
and Yan pairs, and (2) to propose the GLAD method asa practical way to upgrade any existing accelerator control system to become an intelligent Model-Based control
system.

High-level software can be subdivided into two types:
one for commissioning and the other for operation. The
goals of commissioning and operation are not the same.
The goal of commissioning is to find the causes of measured
beam errors, while the goal of operation is to correct theerror effects on the beam.
Here is one example. Often beam orbit errors arecaused by magnet misalignments and BPM reading errors.
During commissioning, it is necessary to first use orbit simulation codes to find errors in the beam line elements (thesources). After these errors are found in the beam line
elements, they can be incorporated directly into the "asbuilt" model. During operation, the same orbit simulation
codes can be used to identify the best correctors and calculate the strengths needed to correct the errors. Since thesuccess of the operation will depend on the accuracy of the
as-built model, the primary objective of commissioning is
to find an accurate model of the as-built beam line. [l]Play-back and Real-time Applications
In general, the procedures to find the "as-built" model
involve the following two-step procedure:* Work supported by Department of Energy contract DE-

1. Measure specific beam parameters, and

2. Analyze the measured data.

AC03-76SF00515.

S17AIA03
566

Al Applications

566

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA04

Development of Operator Thinking Model and Its Application
to Nuclear Reactor Plant Operation System ·Tetsushi Miki, A1cira Endou and Yoshiaki Himeno
Power Reactor and Nuclear Fuel Development Corporation
Oarai Engineering Center 4002 Narita, Oarai-machi, lbaraki-ken, 311-13, Japan
1ator for "JOYO", the first experimental fast breeder reactor inJapan. In next, the operator thinking model was developed
based on the experimental results. [4]Still more, a nuclear reactor plant emergency operation
system has been developed based on the above modet Thissystem is an expert system which substitutes the operator's action to prevent a trip and maintain the safety of a plant in case of
emergency.

ABS'IRACTAt first, this paper presents the developing method of an
operator thinking model and the outline of the developedmodel In next, it describes the nuclear reactor plant operation
system which has been developed based on this model Finally,it has been confirmed that the method described in this papex isvery effective in order to construct expert systems which replace the reactor operator's role with AI (artificial intelligence)systems.

Il. DEVELOPMENT OF OPERATOR THINKING
MODEL

I. INTRODUCTION
A nuclear reactor plant has the following special features. How to control and operate it are the important subjectsof research and development(1) Because it contains a lot of radioactive substances, it would
hmm public in cme of the accidents. Therefor, its high safety isrequired.
(2) Because it gives society a great deal of economic loss incase of the stop of its operation, its high reliability is required.
(3) Because it is composed of many components which havedifferent characteristics, its dynamic behavior is very complex.
In order to control and operate a nuclear reactor plantwith such features adequately, the reactor operator's role isimportant and his burden is heavy specially in the case of theplant anomalous states. According to past serious accidents ofa nuclear plant, it proved that mis-judgement or mis-operationis one of influential factors which would harm the safety andreliability of a nuclear reactor plant Considering information
processing characteristics of man and machine, the task allocation between both is decided as follows.
(1) Man is allotted to irregular tasks which require generaljudgement and decision making.
(2) .Machine is done to regular tasks which require high speed
processing.
In a current nuclear reactor plant, man takes the initiative of control and operation, and machine supports him.
Therefor, various operator support systems are under development and some of them are applied to in-service real reactor
plants.[l]-in order to improve further the reliability of a nuclear
reactor plant, it is necessary to reduce occurrence probability ofhuman error by replacing the reactor operator's role with the AI
system. Such a plant called an autonomous one is under research and development [2][3] In order to reallie this plant, itis necessary to define a framewcirlc of the knowledge base andinference mechanisms of the AI system. One effective method
would be to develop the operator thinking model and to utilize
it. Based on this motivation, operator's thinking process anddecision making process in the case of the plant anomalousstates were studied using the full scope operator training simu-

At fist, the developing method of an operator thinking
model is presented. In next, findings obtained by experimentand the developed thinking model are described in brief.
A. Method for Developing Operator Thinking Model
A.I Experiment Condition(1) Object plant: Experimental fast breeder reactor "JOYO"(2) Simulator to be used : The "JOYO" full scope operator

training simulator(3) Experiment caseIn order to attain our experiment purpose, malfunctions
which satisfy the following conditions were selected.
I) They are able to be simulated by the "JOYO" training simulator.
2) They are so complex as an expert operator must think andjudge.
3) They are not so complex as an expert operator cannot diagnose at all, for example, too multiple contingent malfunctions.
A.2 Simulator Experiment
The outline of typical experiment case is shown as follows.
(1) Object persons: One operator and one supervisor(2) Selected malfunction• Sodium leakage from the main primary B loop
• Failure that sodium leakage sensors do not operate• Failure that sensors which detect the difference of rotation
speed between A and B primary circulation pumps do not operate
A.3 Outline of Tasks for Development
Tasks for developing an operator thinking model arecomposed of the excusion of experiment and carried out after it
Experimental arrangement around the training simulator
is shown in Figure 1.
(1) Collection of data

S17AIA04
570

Al Applications
570

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA01

Operational Decoupling in the SSC Collider
George Bourianoff
Accelerator Design and Operations Division
Superconducting Super Collider Laboratory"'
2550 Beckleymeade Avenue
Dallas, TX 75237

I. INTRODUCTION

that the errors are not allowed to accumulate and reach the levelat which irreversible nonlinear mixing occurs. Local
decoupling requires a measure of the local effect of the errors
rather than the global effect of the errors. The quantity that
goes directly into the decoupling calculations is simply theratio of the out-of-plane tune amplitude to the in-plane tune
amplitude. This quantity is directly measurable and has in fact
been measured on the HERA proton ring and the Fermilab
main ring.
Section 3 contains simulation results of the SSC collidcr
with all known errors included and a full simulation of thecorrection process. It was found that 46 pairs of independently
controlled skew quads are adequate to obtain a reasonably
decoupled machine with a reasonable dynamic aperture. It was
likewise determined that 16 pairs of skew quads are notsufficient to decouple the machine at injection optics. The
minimum acceptable number and optimum placement of skew
quads is a matter of continuing study.

This paper will summarize a recent study of the effects andcorrection of linear coupling in the Superconducting Super
Collider (SSC) lattice. There are several aspects of the SSC
lattice that make direct extrapolation of techniques used on
existing machines unreliable. The most obvious aspect of the
SSC which departs from previous experience is the small
dynamic aperture which lies well within the beampipe. A
second aspect is the existence of long arcs with low
superperiodicity which allow various sources of skew
quadrupole to accumulate to large, and, perhaps, nonlinear
values. A third aspect is the relatively large value ofsystematic skew quadrupole error in the main dipoles. This
results from asymmetric placement of the cold mass in thecryostat
Coupling must be considered harmful if it leads toirreversible emittance blow-up, a decrease in the dynamic
aperture, or inoperability of the machine. These negative
effects are generally related to coupling terms that accumulate
A. Decoupling Formularion
to large and, hence, nonlinear values prior to correction. The
The analytic fonnulation of the local decoupling algorithm
harmful effects can also be caused by the linearly coupledorbits interacting with high-order multipole fields that exist in is contained in Reference 2, Talman 's discussion of single
particle motion. A few of the key results will be repeated here
the other magnets.
The errors that lead to linear coupling are well known. for the sake of completeness.
The propagation of the four-dimensional phase-space vector
They are systematic and random skew quadrupole error fields inthe other magnetic elements, angular alignment errors in the X from point so to s1 is written in terms of the fourquadrupoles and feeddown from the sextupole fields associated dimensional transfer matrix M shown below:
with chromaticity correction, and persistent current fields in
X1 = M10 Xo .
(1)
the dipoles. A study of the relative importance of the various
coupling terms for a simplified SSC lattice is contained in
The localized transfer matrix Ml o may be written in tenns
Reference 1 (SSC-N-93 by Richard Talman).
of the once-around transfer matrixes Mi and Mo at locations s1
The traditional way of correcting linear coupling is to use and SQ, respectively. The relationship is given as
two families of skew quads and adjust them so that the
separation between the two betatron tunes is minimized. This
Mi= Mio Mo Mio(2)'
is a global scheme which is sensitive to only the betatrontunes which clearly are global quantities. Another traditional where the bar indicates the symplectic inverse of the localized
method is to focus on the sum and difference resonances and transfer matrix. The approach is to block diagonalize the onceuse two families to skew quads to correct them. Sometimes around transfer matrixes at a sequence of points so, SJ. .. ., Sn.
both methods are used, which requires four families of skew The procedure necessary to block diagonalize each individual
quads.
transfer matrix starts by breaking up the 4 x 4 matrix into four
The method being proposed for the SSC is intrinsically2
x 2 matrices denoted by A, B, C, and D. One then fonns
different and amounts to decoupling one local section at alinearcombinations of the B and C submatrices responsible fortime. The mathematics required to do this are described in thenext section. The primary motivation for local decoupling is coupling:*Operated by the Universities Research Association, Inc., for
the U.S. Department of Energy under Contract No.
DE-AC35-89ER40486.

M=[ACDB] ·(3)

S18BPA01
576

Beam Physics Applications
576

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA02

Frequency Domain Analyses of Schottky Signals Using a Vl\1E Based
Data Server and a Workstation ClientA. Chapman-Hatchett, V. Chohan, I. Deloose, F. Pedersen
CERN, PS Division, CH-1211 Geneva 23

Abstract
Schottky signals are extensively used for observation, setting-up and operation of CERN's Antiproton
rings, namely the AC, the AA and LEAR. Measurementof these signals is, at present, carried out by a series ofcommercial instruments. These instruments have to be
individually controlled and read by each application program. The operational use of the system is limited by thecapabilities of the individual instruments. The first objective for the new system was to provide, as far as possible,
a true "server". The "client" application program simply
requests the data it requires. It is then supplied withmeasured and processed data. This provides the operator
with a fast response by having ready processed data
always available. Our second goal was to make the system
operationally simple, with multiple windows andpresentation on a single screen. This paper discusses some
aspects of this implementation and applications for the
antiproton production, collection, and storage rings.
INTRODUCTION
The system is to be used on the CERN Antiproton
Collector(AC) and Antiproton Accumulator (AA) rings.
The Antiprotons are first created by directing a 26 GeV
proton beam onto a production target. The antiprotons arethen captured, injected and stochastically cooled in the AC
ring.
After cooling they are transferred to the AA ringwhere they are stored, and continuously cooled until
needed by the physics programme. This is a multistep
process involving rf bunch rotation and debunching,stochastic cooling in all three planes, rf recapture in the
AC and bucket-to-bucket transfer to the AA, pre-coolingin the AA, rf capture in the AA and transfer to the stacktail region and stack-tail cooling as well as core coolingfor long-term storage in the AA. To have any yield at theend of this process, all the systems have to be set up to run
with very high efficiency. In addition, due to the limited
available cooling power, beam blow-up must be avoided atevery step. Similarly, non-destructive beam diagnostic
measurements have to be made, i.e. without disturbing andblowing up the beams. The technique chosen was spectrum
analysis of the Schottky signals produced by the beams [l,2]. By using appropriately positioned pickups and producing spectra of the revolution frequency sidebands, thebeam profile in the horizontal, vertical, and longitudinalplanes can be deduced. If the sensitivity of the system isknown, the integral of the spectrum gives the beam
intensity. At present, four types of spectrum analyzers,

from two different manufacturers are used. Differences
between these instruments leads to very complex measurement programming. To complement or replace these
instruments, a very high speed, fast Fourier transformengine is needed. The VASP16 VME module from
Computer General was chosen. This has a Texas
Instruments 320C25 digital signal processor, and four
Zoran vector processors on the board. The board iscapable of performing a 1024 point FFf in 700 µs. The
VME chassis is controlled by a Motorola MVME147
board running the 089 operating system. The Motorola
68030 CPU transfers data from the ADC's (analogue todigital converters) to the VASP16 and services requests
for data from the users. The ADC's are triggered to takedata by the accelerator timing system.
OBJECTIVES
Replacing these instruments with a VME system,
there are four main objectives.
a)
To make the results available on request. At present
each instrument has to be set up and then the measurement
can be made. With the VME chassis data taking andprocessing can take place continuously, and the resultspresented on demand.
b)
The spectrum analyzers have some real time constraints, they normally expect to acquire data, then process
it, then display it. The VME system can acquire data attimes fixed by the machine cycle, and fit in the processing
between data acquisition.
c)
The third objective is to separate the process of dataacquisition from the task of presentation. This would
allow any operator to access data without interfering withanother operator's measurements.
d)This system has to be integrated into the control
system. By using the VME system we can produce a standard interface to the control system, with all the specificlow-level software hidden from the rest of the system.

SYSTEM OVERVIEW
Figure 1 shows a generalized overview of thesystem.
The resonant pickups consist of two parallel plates
inside the vacuum chamber, one pair for the horizontal
measurement, and a pair for the vertical measurement.
The signals are brought out with vacuum feedthroughs
and fed into a coaxial line resonator. The sum and difference signals are made using a hybrid and the resulting
signals are amplified by low-noise amplifiers. The specificcharacteristics and needs for the respective rings areshown below.

S18BPA02
Beam Physics Applications

579

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA03

New Controls for the CERN-PS Hadron fujection Process using Operating Tools
and High-Level Accelerator Modelling Programmes
M. Arruat, M. Boutheon, L. Cons, Y. Deloose, F. Di Maio, D. Gueugnon,
R. Hoh, M. Martini, K. Priestnall, J.P. Riunaud
PS Division
CERN 1211 Geneva 23 Switzerland

Abstract
A new control system using man-machine interface tools
with workstations as consoles has been successfully put into
operation for the injection of hadrons in the CERN Proton
Synchrotron (PS). This paper mainly focuses on specialized
modelling programmes involving complex treatments for an
optimum operation of the injection process. These
programmes include the control of the injection timings, themeasurement of the beam emittance with an estimation of
how well the incoming beam is matched, and the correctionof oscillations at injection. The infrastructure and theprogramming environment underlaying the new control
system are described elsewhere3.
The outstanding feature of the internal structure of allthese modelling programmes is that they carry out three kindsof data interaction: the input, that is the measurements (e.g.
beam time positions, profiles and trajectories), the physicalparameters (e.g. required times for synchronization, beamemittance, beam space position and angle at injection), andthe output, mainly the hardware values (e.g. preset countersettings, currents to apply to injection steering magnets).
I STRUCTURE OF HIGH-LEVEL MODELLINGPROGRAM1'.1.ES
A control system provides the users with centralised
access to hardware control values. These values can beobtained in various ways. They can be controlledindividually, for example tuning a power supply current via aknob, or globally, setting all currents of a complete beam linefrom a selected file. In those two cases, the final hardware
values are left to the user's appreciation. Their choice is madeeither following the effect on the beam, as in the first case, orat the time of the file selection, as in the second. Evaluationof these control values does not require implementation of theprocess involved in the control system.
However, in many cases the process involved is known
and several control values can be worked out from therequired machine and/or beam parameters. A dedicatedprogramme can then be used to evaluate these control values
from the user's requirements. Considering the previous
example of a beam line, if the relationship between the
power supply currents and the energy is known, setting acomplete beam line for various energies does not require as

many files as energies, but only one file and a dedicatedprogramme working out the currents from the requiredenergy.
This trivial example can be extended to more generalcases. In the example of beam steering, the trajectory of thebeam in a transfer line can be taken as input, physicalparameters such as angle and position of the beam at arelevant position in the line can then be worked out from thistrajectory, and finally current variations in deflecting
elements can be computed to steer correctly the beam in theline. More generally,
controls values (output) can becomputed from physical parameters (parameters relevant to
the process involved) which, in turn, can be computed frommeasurements on the beam (input). Modelling Programmes
perform such operations and take care of computations
between inputs, physical parameters and outputs.
In most cases, provided they are not too large, variationsof beam characteristics (A.X, inputs) lead to variations ofphysical parameters (AP) which can be expressed in a matrix
formalism. The same applies to the variations of hardware
control values (AY, outputs) which can be expressed fromvariations of the physical parameters:[AP ] = [ M 1] "' [ AX]
(1)

[AY]

=[Mz] * [AP](2)

Modelling Programmes can compute hardware values
from physical parameters or from beam measurements, using
matrixor both M 1 andIf matrix
is not singular,
one can also work out physical parameters by reading control
values. This can of course be of great help for machine
tuning. In the following section we present how these
considerations have been applied to the timing process ofhadron injection into the PS 1.
II INJECTION nMING CONTROLSIn the injection process, timing pulses have to be delivered
to various equipments in order to trigger them correctly withrespect to the incoming beam. Preset counters areinterconnected in such a way that they can provide thenecessary pulses, with the proper time resolution, at
appropriate instants with respect to external time references.
One can then define the required times as physical parameters
and the output as the control values to be loaded in the various
counters. Looking at the timing lay-out, the required times

S18BPA03
Beam Physics Applications

583

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA04

Mark
Sincrotrone Trieste
Padriciano 99, I-34012 TRIESTE
e-mail: plesko@elettra-ts.infn.it
Abstract
CARSO is a program package which contains several new
software tools to be used during fust turn steering of a storage
ring, or during the steering through a beam transfer line.
CARSO includes routines which check the effects of magnetic
components on the beam, check the measurements of thebeam position monitors and simultaneously steer the beamthrough the ring to perform one full lum. The programs are
written in ANSI extended standard FORTRAN 77 andcomprise 6000 lines of source code, 87 subroutines and aoout
1000 different variables. The concepts used within CARSO are

L ll'<'TRODUCTION
The conventional
to first tum
is first to
adjust manually some steering elements so that the beamreaches the last bea.rn position monitor, and then toto reduce the r.rn.s of thenumerical orbit correction
monitors
orbit displacements measured at the beam
During the manual phase the machine physicists often
have to make some checks and reason about possible
malfunctions of the equipment such as incorrect beam position
measurements, quadrupole polarity errors, ineffective steerers,etc.
CARSO automizes the first phase and combines it
effectively with the second. CARSO performs routine
equipment checks systematically, notifies the operator whensome possible errors have been found and tries to correct forsome of them at their source. For the ones it can not correct,CARSO provides a fine adjustment of the beam towards thebeam axis in a semiempirical way.
CARSO combines for the first time two concepts whichitself are rather new for machine physics software. First, it
actively uses the beam itself as a measurinis device to test thecomponents of the ring (a possibly similar approach is
described in [3]). Before steering, first the relevant components
are checked by sweeping the beam. Only if they behave as
expected, I.hey are used to adjust the beam towards the beamaxis. The second concept is that rather than comparing themodel of the storage ring with the measurerl beam positions
globally, CARSO checks each monitor and the elements
surrounding it separately (the same philosophy is applied in[4]). Thus it is able to localize gross errors rather precisely.

* Supported by an ICTP fellowship.

CARSO is capable of steering the beam successfully inspite of certain types of component malfunctioning, because it
can recognize a few classes of error patterns and correct its
model of the ring accordingly. CARSO still provides many
interactive input/output messages and prompts, in order tothe human operator complete control over its
performance. In this respect, CARSO can be viewed as an"apprentice" doing the simple and obvious routine tasks,
reducing the load of the operator, who can thus concentrate on
global reasoning.
CARSO uses machine theorf as well as some heuristic
experience of a skilled operator to evaluate the checks. If a
problem is encountered that can not be solved
using thisknowledge, CARSO informs the operator and waits for his/herintervention. Sometimes CARSO may "overlook" a severe
error, but from its output the operator is nevertheless able todetect the error or to get at least some hints about the
problem.

IL THEOF CARSO

A. The Guidelines
The guidelines for the development of CARSO were:- compare the predictions of the theoretical optics, which isrepresented by the model, with the measured beam position ;- in case of a mismatch between the two, correct either
directly the source of the error, correct the model, or at least
minimize the effect of the error on the beam trajectory;
make as little as possible assumptions, that can not be
verifieda measurement - i.e. use the model only forcomparison and not for calculations;- avoid pure quantitative checks if qualitative ones can givereasonable answers, because there might be too many
unexpected errors, degrading the numeric precision below
acceptable levels;- ensure that no action taken by CARSO sets the hardware
beyond its limits;- adjust algorithms to include heuristic rules of a humanoperator.

B. The Approach Chosen
For the purpose of first turn steering, when the beam
traverses each element only once, a storage ring can be viewed
as a simple beam transfer line. In a transfer line the basic
approach is to adjust the elements so that the beam travels
from one monitor to the next and so on, until the last monitor
is reached. If the beam does not reach a monitor, it is obvious

S18BPA04
Beam Physics Applications

587

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S19SP01

Control Protocol : The Proposed New CERN Standard
Access Procedure to Accelerator Equipment. Status Report
G. Bari.baud, I. Barnett, G. Benincasa, 0. Berrig,
Brun, P. Burla, A. Burns, R. Cappi,
G. Coudert, C. Dehavay,
Desforges, R. Gavaggio, G. Gelato, H.K. Kuhn, J. Pett, R. Pittin,
J.P. Royer,
Schulte, C. Steinbach, P. Strubin, D. Swoboda, N. Trofimov (*), L. Vos
CERN European Organisation for Nuclear Research, 1211 Geneva 23, Switzerland(*)Home Institute IlIEP Institute for High Energy Physics 142284 Protvino, USSR
Abstract

Control protocol provides a normalized access procedure for
equipment of the same kind from a control system.
Modelisation and the subsequent identification offunctionalities with their parameters, variables and attributes
have now been carried out at CERN for representative families
of devices.
ISO specifications, such as the ASN.1 metalanguage fordata structure representation and .M:MS definitions and services
have, to some extent, been introduced in the design forgenerality and compatibility with external world. The final
product of this design is totally independent of the control
systems and permits object oriented implementations in any
controls frame. The present paper describes the different phasesof the project with a short overview of the various
implementations under development at CERN.

I. INTRODUCTION
Studies on protocols have been carried out at CERN for
more than three years. The basic ideas have been set up in theframe of the Technical Board for Controls and Electronics(TEBOCO): this consultative Board had the mandate ofinvestigating and proposing unifonnisation and standardizationin the concerned field.
The generalities of the control protocol and the results
obtained with first prototypes implementations, have beenpresented at the Accelerator Control Conference in Vancouver,
October 1989 [1] [2],At the beginning of 1990, a working group called
WOPRO (Working Group for Protocols, whose members are
the Authors of this paper) was set up with the CERNManagement mandate of studying and proposing control
protocols for all accelerators at CERN.
Studies on Protocols have been carried out by WOPRO
through two activities :i) the different CERN equipments have been grouped inclasses of similar devices. For each class, behavioural models
have been proposed and the corresponding functionalities withthe associated parameters have been identified. Appropriate
structures for representing data have also been proposed. This
activity, which is independent of the control system layout,
has been carried out by the specialists of the WOPRO group.
II) the Control Protocol must be implemented in the actual
CERN controls structures. This activity concerns more
precisely all those services allowing the external visibility ofthe protocol, i.e.the access procedures to the equipment, andthe software structures required by the protocol realisation.
This implementation study is carried out by controls
specialists together with the WOPRO members.
The first and main activity of WOPRO (conceptual designphase) has been terminated by mid 1991 [3] [4] [5] [6]. The
second, implementation oriented phase, is under study andmajor results are expected for spring 1992.
CHARAC1ERISTICSOFTHECON1ROL
PROTOCOL
Standardization and unifonnisation of equipment access is
not a novelty in accelerator controls field. In fact the control
system of each accelerator or Complex has introduced its own
standard. What is different in the proposed WOPRO's
approach, can be summarized in the following five points :- The investigations have been carried out CERN wide.
Each considered class of devices includes examples comingfrom the more concerned machines.
- The study has at first been bottom-up oriented, from theequipment to the control system. The proposed protocols
fulfills then principally the needs of the users of the control
systems at CERN.
• The functional description of the devices includes all
aspects related to operation. In the accelerator field a device
works very often in close connection with other equipmentthat is necessary for the accomplishment of its activity(triggering systems, function generators, etc.). The proposed
protocols consider these equipment as part of the device andinclude them in the design.
• The design is based on behavioural models. For eachfamily of the considered devices, the relevant specialists havefirstly developed one or several behavioural models: the model
includes all aspects that are necessary for an operational use of
the device. This conceptualization has provided the degree ofabstraction needed for the generality of the design.
- An object oriented approach has been used. The user has
to specify "what" to do: the object-device knows "how" to doit. This allows a large independence between theimplementations of the controls specialists and those of thedevice specialists. Other features of the object oriented design,
such as class structures, inheritance, etc., are proposed in theimplementation phase.

S19SP01
Standardization and Protocols

591

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Man-Machine Interface Workshop Summary*Stuart C. Schaller
MP-6, Mail Stop H-852
Los Alamos National Laboratory
Los Alamos, New Mexico, 87545, USA

Abstract
This report is a summary of the Man-Machine Interface
Workshop that took place on 14 November 1991 as part of the1991 International Conference on Accelerator and Large
Experimental Physics Control Systems in Tsukuba, Japan.
The conference was sponsored by KEK, the Japanese HighEnergy Physics Laboratory.

I. INTRODUCTION
The topic of man-machine (MMI) interfaces has received
much attention in the general computing literature, (see, e.g.,[I]). The Man-Machine Interface workshop at this conference
was motivated by desires to provide an interactive forum forthe discussion of how current methods and new ideas can beused to make communications between the accelerator control
systems and the control system users as effective andcomprehensible as possible. The goals of this workshop were
two-fold:1) To identify unifying principles in the design andimplementation of man-machine interfaces foraccelerator/physics control systems;

2) And, looking to the future, to encourage discussion ofnew, possibly speculative, man-machine interface techniques
and their application to such control systems.

The 1989 ICALEPCS conference in Vancouver included aworkshop on the use of workstations in accelerator control
systems. Part of that workshop dealt with the problems andpossibilities presented by the use of workstations as manmachine interfaces in accelerator control system environments.
It is interesting to compare the changes in emphasis that havebernme evident in two years. Comments from the 1989
workshop emphasized several aspects of the man-machineinterface including: the need for realistic feedback for analog
controls whether implemented through physics knobs or awindow interface; the desirability of multiple, nonoverlapping screens on each operator console; and theimportance of tools for rapid prototyping.
As part of the 1991 MMI workshop, we hoped toencourage discussion of a wide variety of topics, including:display methodologies, interaction techniques, human- andsoftware-related engineering concerns, user construction ofinterfaces, and speculative aspects of three dimensionalpresentation and virtual reality. In this year's session, we wereparticularly interested in learning about the current use of
windowing systems and third party interface builders, and theconstruction and maintenance of interfaces by users.
II.PAPERSThe Man-Machine Interface Workshop at this conference
featured four invited papers and a discussion period. The
papers were selected based on the abstracts submitted to theconference program committee. The full papers are available
elsewhere in these proceedings.
Kevin Cahill describe<l the uses Fermilab has made of the
X-Window environment for accelerator control consoles
Fermilab is using DEC Vaxstations. A single
keyboard/trackball and set of knobs is interfaced to multiple
screens using a locally engineered interface box. The XWindows environment has been exploited to allow remoteconsoles across long haul networks and to support multiple
consoles on a single workstation. A Fermilab console wasactually running on a Vaxstation at KEK during theconference. Read-only consoles and consoles with limitedcommand capability help to allay feelings of unease among
their operators. In addition, all commands areon acentral server.
Frank Di Maio from CERN discussed the workstations thatare being introduced as part of the rejuvenation of the CERN
control systems (3]. The rejuvenation effort is based on Unix
workstations with X-Windows, Motif, and TCP/IP
communications. CERl'l"'s first attempts included console
emulation for some of the NODAL-based applications. The
workstation environment includes a user interface editor and aninteractive application builder.
A completely new system based on Unix, X-11 and the
PHIGS graphics standard was described by Franco Potepan of
the ELETTRA Synchrotron Light Source in Trieste, Italy [4].
The ELETTRA system has a very natural interface that allows
direct access and manipulation based on CAD-derived picturesof the entire accelerator complex. This interface was an
attempt to continue the desktop metaphor in the accelerator
environment.

*Work supported in part by the U.S. Department of Energy

S20PD01
Panel Discussions

595

595

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S20PD01

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

which is expected to continue. At levels of control lower thanthat of operator interaction, the prognosis is not so good.
Much of the low level software of any system revolves aroundthe database, an area in which there is no standardization as toproduct used or even as to the nature of the data stored.

Summary
Panel Discussion on
Standards and World· Wide Sharingof Software
Organizer:

P. Lucas (Fermilab)

Participants:

Briegel (Fermilab, P.Clout(Vista), D. Gurd (SSCL), N. Kanaya(KEK), U. Raich (CERN)

It has been a dream in the accelerator community for sometime that software developed for one control system be easilytransferrable to and usable at another. Until recently this goal
was seldom realized in practice. This has been primarily
because the various control systems have been developed inhouse with little standardization among them. The world ofaccelerators was dominated until a few years ago by very large
machines constructed for doing high energy physics. The large
laboratories could likewise afford large controls groups, whichwere able to build these complete systems from the ground up.
However the accelerator scene has now shifted, with a large
fraction of the new work being done at much smaller
installations, installations which cannot afford the large staffs
previously employed in control system production. Different
approaches to this problem were outlined by P. Clout: having
one or more smaller laboratories follow in the footsteps of alarger one, use of industry standards to such an extent that asignificant amount of software is transferrable, or purchase ofcontrol systems from commercial vendors.

At a less involved and more practical level it was suggested
that a computer bulletin board could be initiated on which
control system problems and insights could be made available
to the community.
It was also noted that for software to be shared effectively it
must be documented well. Although there were differences of
opinion on who could best document any software and on whatsort of documentation was most appropriate, there were noneon the blanket statement that this is an area in which weshould all strive to do better.

This discussion centered on the second of the points mentioned- that use of standards could foster transferability. Standards are
becoming very important in the world of distributed
computing as they allow the equipment of various vendors tointeroperate on an integrated network. Since most accelerator
control systems utilize such networks, they are indeed in theprocess of adopting various various standards. Among thosementioned, which have achieved to a lesser or a greater extent
penetration of the accelerator field, are the Unix operating
system, the Xl 1 windowing system, the Motif presentation
layer, and the TCP/lP networking protocol residing primarily
on Ethernet but also on Token Ring physical layers. Most
controls hardware being constructed resides in VME and to alesser extent Multibus II, with a large installed base of Camac
and its attendant driver software. The Oracle product isbe.coming a de facto standard for off-line database work, but noclear one is emerging for real-time databases. Similarly there is
no standard for a microcomputer operating system, but at least
there are a few commercial products being utilized, as opposedto the do-it-yourself philosophy espoused in the past
The consensus of the discussion was that at the level ofworkstation console applications the prospects for sharedsoftware were good. Use of Xl 1 and Motif have alreadyallowed portability of some graphics widgets, an activity

S20PD02
Panel Discussions

597
597

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

doi:10.18429/JACoW-ICALEPCS1991-S20PD02

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S20PD03

Panel Discussion on Management of Control Systems
Don Barton (BNL), Axel Daneels (CERN), Winfried Busse (HMI), Lindsay Coffman (SSCL & DOE),
Shin-ichi Kurokawa (KEK), Rudolf Pose (JINR)
Reported by Axel Daneels (CERN)I.

INTRODUCTION

In scientific organizations one often encounters theopinion that management is a trivial activity and that project
managers enjoy the easy side of the project life, far away from
where the real work is. However, examples abound of projects
failing to meet their objectives, running behind schedule,
overrunning costs, etc., because of poor management. To
several aspects which are crucial for the successful completionof a project the attention they deserve has to be paid if the
project is to meet its objectives within the constraints that are
imposed upon it. Whereas the engineers do things, themanager gets things done; managers are particularly concerned
with:conducting control systems but also because they represent avariety of backgrounds and environments. Indeed, they all
represent laboratories which are of different sizes and which
operate in diverse economical and political conditions.
Each panelist introduces himself and describes briefly his
current activities, the project he is concerned with, the size ofthe group involved in these activities and any possible"cultural" particularities of his environment that influence his
activities.
Don Barton (BNLJRHIC-AGS) heads a group of 11 program
analysts, 8 electrical engineers and 9 technical support
people. The group is in charge of the controls of both the
Alternating Gradient Synchrotron (AGS) and the future
Relativistic Heavy Ion Collider (RHIC). In addition toproviding maintenance support for the running physics
program at the AGS (for both protons and heavy ions) andfor the commissioning of the new booster, the group soon
will need to initiate the study of the RHIC controls.
Besides the evolving technology, the biggest challenge
stems from the sheer size of the entire accelerator complex,
and consequently also of the control system. At present
there are about 60 workstations and 80 to 90 multibus I
crates with real time systems in a very distributed
environment. The total effort invested so far is around 60 to
70 manyears.

- what is planned to be done: i.e. the product which should
be delivered, in our case the control system,
how long will the project take: i.e. schedule,
how one will know when the project is finished:completion criteria,
how much will it cost to implement and to maintain: Le.
the cost.
These issues can e.g. be classified in three categories
respectively relating to:
the project:
analyse the requirements, define the quality that needs to beachieved, estimate the schedule, evaluate the cost, analyse
the trade offs in order to decide e.g. whether it is preferable
to phase out or to upgrade an existing system, whether one
should build in house or buy commercial products, etc.,- the logistics (hardware and software):what level of support should one expect during the life cycleof the project; how reliable should the system be; howmaintainable; what level of safety should one reasonably
expect; how much training will be requested so that theuser can take up operating the new system himself, etc.,- Winfried Busse (HMI/VICKSI) is responsible for the control
system of the VICKS I facility. VICKS I is a comparatively
small installation which was put into operation in 1978.
Despite an upgrade program, started in 1987, the support thecontrols receive from the upper management of thelaboratory is continuously decreasing. Originally 9 persons
strong, the group is now limited to 3 people looking after
the everyday running of the system and one person
endorsing the entire upgrade program. It is thus no surprisethat progress is very slow.
Lindsay Coffman (SSCL & DOE) works on the DOE(Department of Energy) side of the SSC Laboratory. He is
responsible for Systems Engineering across the SSC
project. Coffman's office, currently 5 persons but intended
to grow to 12, has to ensure that the SSC project follows
the proper engineering practices: i.e. follows the modern
systems engineering and management practices withdiscipline, adheres to current standards, follows state of theart software guidelines and development practices, delivers
the proper requirement documents, etc.

the technology:
what standards should be used; are these standards likely tostay actual during the life cycle of the system; what
techniques should be applied for the implementation, (e.g.
computer aided software engineering - CASE-, other tools,
use of advanced techniques,. ...); what products are available
on the market that meet the requirements, etc.

II.

INTRODUCING THE PANELISTS

The panelists who were invited to animate this session
were selected not only on the basis of their experience in- Axel Daneels (CERN/AT) involved in controls until 1990,
was responsible for the development of the application
software of CERN PS accelerator complex. Currently

S20PD03598

Panel Discussions

598

Content from this work may be used under the terms of the CC BY 4.0 licence (© 1992/2024). Any distribution of this work must maintain attribution to the author(s), title of the work, publisher, and DOI

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S21CS01

ISSUES in ACCELERATOR CONTROLSA personal view, from a distance and in soft-focus(Conference Summary, ICALEPCS-91)
Berend Kuiper, CERN, Geneva, Switzerland
Dear colleagues,
The fact that I am standing here in front of you at this moment of the conference should issue twodifferent signals. To you it should signal that the more frivolous part of the meeting has started; to me
it signals that I must have reached a certain age ....
The second personal comment which I want to make is that, at the lunch meeting in San Francisco,when the International Scientific Advisory Committee, ISAC, were discussing the ICALBPS-91
programme, my friend Shin-Ishi Kurokawa suggested that I should say the "closing words". Of course
I was very flattered and, since that looked to me like an affair of ten minutes, I promptly accepted
By the time I received the final programme, two weeks ago, I found myself put down for a"conference summary" of 40 minutes. Of course I am still very much honoured and - noblesse oblige- I shall try ..... But what I shall really present to you, will be in the form of a, somewhat handwaving, overview of a number of main controls issues, as I think to see them, from a certain distanceand in a soft-focus, with occasional side comments on what the conference gave. So it is neither of
the two, or both, however you like to see it.
When attempting to make conference summaries of this kind, one is always tempted - and possibly
even expected - to "discern'' and then to point out the "great lines" of evolution of the subject andthen to make predictions, "far sighted" if possible. Of course such an activity is jolly risky since atthe beginning of any such trend, a few discernible examples and implementations of one sort, or a
new product here and there, do not necessarily make a trend By the time the developments havereally taken on, however, the "great line of evolution" has become obvious to just about everyone andchances are that the trend is already approaching its end and that some other trend - at that point withhardly decodable patterns - is already infiltrating the old situation which - since it is by now known has become comfortable and homely and - thank God - at long last more or less efficiently usable.
What, then, is there - other than the technical novelties themselves, which are so disconcertingly
complex and changing - what is there to guide us in deciding our directions, to decide what course
we shall choose, what we shall buy, etc. Well, ladies and gentlemen, it may sound like a platitude,
but the sole constant factors in all this - on the long term - are, on the one hand, human nature with its
penchant for comfort and simplicity in doing one's job and, on the other band, the omnipresent
limitations in our resources, in other words considerations of economy.
Now I am not trying to deny that some future technological breakthrough can bring an enormous
benefit and change radically the way we think about our problems and that, in doing so, it may hit us
from an ambush or so to speak pull the rug out under our feet. We have lived through that before.
What I want to say is that this will only happen if that breakthrough brings convincingly more
comfort and/or economy. Vendors are slowly learning to bring their new products and trends in amore constructive way and not any more with the sole aim of wiping out the competition and thereby
possibly also the very customers they are trying to court. The reasons for this - recently more rational- behaviour is human nature and economy. The human wish for comfort blows up the software
packages - systems and applications (just think of transmission protocols, graphics, etc.). The
investments are then becoming so enormous that frequently learning new systems and porting
software become insurmountable barriers. And creating new such barriers becomes increasingly
unpopular with the clientele, who are constantly growing and, through user groups and other

S21CS01
602

Conference Summary602