ii

PrefaceFOREWORD

International Conference on Accelerators and Large Experimental Physics
Control Systems (ICALEPCS'91) was held on November 11 - 15, 1991 at
KEK, Tsukuba, Japan. This was the first conference in this series held inAsia. It was a great pleasure for the organizers of the conference that morethan 240 participated. Among them we were delighted to see large delegatesfrom countires and institutions such as Russia, China, Korea, India, SRRC in
Hsinchu, etc. from which very few had participated in the former conferences.
This reflects the fact that the society has come to its maturity, to which thecontinuing effort by EPCS(Interdivisional Group on Experimental Physics
Control Systems under European Physical Society) has contributed greatly.
The maturity was also demonstrated by a naming of the "standard
model" of control systems which we heard during the conference. Also, in theconference, discussion was held on prospects of making a generic tool-kit ofcontrol system on the basis of world-wide collaboration. Of course, we arefar from this goal; however, it is sure that we glimpsed our future during theconference.

hin-ichi Kurokawa
Chairperson of ICALEPCS'91--iJ-1 ~ i /?-_Tadahiko Katoh
Chairperson of Local Organizing Committee

Preface
Foreword

(vii)

iii

LIST OF INTERNATIONAL SCIENTIFIC ADVISORY COMMITTEE MEMBERS
BLUMER, Thomas (PSI)
CLOUT, Peter Norman (VISTA)DASGUPTA, Subrata (VECC)DUNAITSEV, Anatoly F. (IHEP-Serpukhov)
HUMPHREY, John (Rusty)(SLAC)
KATOH, Tadahiko (KEK)KUIPER, Berend (CERN)KUROKAWA, Shin-ichi (KEK) - Chairperson
LUCAS, Peter Wayne (Fermi/ab)
LUONG, Tam T. (GANIL)
NAVRATIL, Jiri (CTU)
OWEN, Edward Charles (Daresbury)
RAUSCH, Raymond (CERN)STEINER, Rudolf (GS/)
WON, Sangchul (PLS)BARTON, Donald S. (BNL)
BUSSE, Winffied (HM/)
DANEELS, Axel Jean (CERN)DOHAN, Don A (SSCL)
GURD, David P. (SSCL)
JAN, Gwo-Jen (SRRC)KIMURA, Toyoaki (JAERI-Naka)KUPER, Edward (/NP-Novosibirsk)
LIU, Shi-Yao (/HEP-Beijing)
LUDGATE, George Arthur (TRIUMF)
MULLER, Klaus-Dieter (KFA)NISHIMURA, Hiroshi (LBL)
PETERS, Franz (DESY)SCHALLER, Stuart (LANL)
WADA, Takeshi (RIKEN)

LIST OF LOCAL ORGANIZING COMMITTEE MEMBERS
KIMURA, Toyoaki (JAERI-Naka)
KUROKAWA, S~in-ichi (KEK)
NAKAHARA, Kazuo (KEK)OYAMADA, Masayuki (LNS)
TAKEDA, Shigeru (KEK)
WADA, Takeshi (RIKEN)

KATOH, Tadahiko (KEK) - Chairperson
KOHNO, Toshiyuki (NIRS)MORITA, Koh-Ichiro (NAO-NRO)
OGATA, Hiroshi (RCNP)
PAK, Cheol On (KEK)
URAKA WA, Junji (KEK)
WATANABE, Shin-ichi (INS)Organized by:

KEK, National Laboratory for High Energy Physics

Supported by:

European Physical SocietyIEEE Nulcear and Plasma Sciences Society
Japan Physical Society

Sponsored by:

Tsukuba EXPO '85 Memorial Foundation
Foundation for High Energy Accelerator Scienceiv( ix )

Preface
Foreword

Contents
Preface
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i
iii
v

PapersS01SRA01 – A Users View of the SPS and LEP Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA02 – Experience Controlling the LAMPF-PSR Accelerator Complex . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA03 – Status Report on the Advanced Light Source Control System . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA04 – Lessons from the SLC for Future LC Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA05 – Process Control for the Vivitron: the Generator Test Set-up . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA06 – Recent Developments of the ALPI Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA07 – The GSI Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA08 – VME Applications to the Daresbury SRS Control System . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA09 – Accelerator Control Systems in China . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA10 – HESYRL Control System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA11 – The Control System of HIRFL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S01SRA12 – Control System for a Heavy-Ion Accelerator Complex K4 - K10 . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU01 – Future Directions in Controlling the LAMPF-PSR Accelerator Complex at Los Alamos National Laboratory
S02SRU02 – Common Control System for the CERN Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU03 – New Control Architecture for the SPS Accelerator at CERN . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU04 – The Next Generation Control System of GANIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU05 – Replacement of the ISIS Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU06 – Upgrading the Control System for the Accelerators at The Svedberg Laboratory . . . . . . . . . . . . . .
S02SRU07 – Upgrading the BEPC Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU08 – The Rejuvenation of TRISTAN Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU09 – Upgrade Plan for the Control System of the KEK e⁺/e⁻ Linac . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU10 – The New Control System for TARN-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S02SRU11 – A New Architecture for Fermilab’s Cryogenic Control System . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD01 – Controls for the CERN Large Hadron Collider (LHC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD02 – A Performance Requirements Analysis of the SSC Control System . . . . . . . . . . . . . . . . . . . . . .
S03SRD03 – The Computer Control System for the CESR B Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD04 – Standards and the Design of the Advanced Photon Source Control System . . . . . . . . . . . . . . . . .
S03SRD05 – The ESRF Control System; Status and Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD06 – Centralized Multiprocessor Control System for the Frascati Storage Rings DAΦNE . . . . . . . . . . . .
S03SRD07 – The Operator View of the Superconducting at LNS Catania . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD08 – The UNK Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD09 – Moscow University Race-Track Microtron Control System: Ideas and Development . . . . . . . . . . . .
S03SRD10 – Present Status of Control System at the SRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD11 – Status Report on Control System Development for PLS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD12 – Design of SPring-8 Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD13 – Design of a Control System of the Linac for SPring-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S03SRD14 – Control System for HIMAC Synchrotron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S04SRS01 – Digital Control of the Superconducting Cavities for the LEP Energy Upgrade . . . . . . . . . . . . . . . .
S04SRS02 – A PC Based Control System for the CERN ISOLDE Separators . . . . . . . . . . . . . . . . . . . . . . . . .
S04SRS03 – Status of the Control and Beam Diagnostic Systems of the CRYRING Project . . . . . . . . . . . . . . . .
S04SRS04 – Magnet Test Facility Control System for Superconducting Magnets of UNK . . . . . . . . . . . . . . . .
S04SRS05 – Beam Extraction Controlsystems of the Fast-Cycling Synchrotron . . . . . . . . . . . . . . . . . . . . .
S04SRS06 – Instrumentation & Control System For PLS-IM-T 60 MeV LINAC . . . . . . . . . . . . . . . . . . . . . . .
S04SRS07 – Multi-Microprocessor Control of the Main Ring Magnet Power Supply of the 12 GeV KEK Proton Synchrotron
S04SRS08 – VME Computer Monitoring System of KEK-PS Fast Pulsed Magnet Currents and Beam Intensities . . . .
S04SRS09 – Magnet Power Supply and Beam Line Control for a Secondary Beam Line K6 . . . . . . . . . . . . . . .
S04SRS10 – Specific Beam Delivery System of Medical Accelerator HIMAC . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN01 – A Control System for a Free Electron Laser Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN02 – Control System for JAERI Free Electron Laser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN03 – Control Software for the ESO VLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
7
11
14
19
23
27
31
35
40
44
47
50
54
59
65
71
78
82
85
89
93
96
100
105
110
116
121
128
131
134
140
143
147
151
154
156
159
162
167
171
174
177
180
184
188
192
195
198
202

Contentsv

S05SRN04 – Distributed Control and Data Acquisition for the EUROGAM Gamma Ray Spectrometer . . . . . . . . . .
S05SRN05 – A Control System of the Nobeyama Millimeter Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN06 – Present Status of the JT-60 Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN07 – Conceptual Design of Centralized Control System for LHD . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN08 – Status of LHD Control System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S05SRN09 – Control and Monitoring System Design Study for the UNK Experimental Setups . . . . . . . . . . . . . .
S05SRN10 – Hard-and Software for Measurement and Control of the Pulse Thermonuclear Installation . . . . . . . .
S05SRN11 – A Control & Data Acquisition System for Photoelectron Spectroscopy Experiment Station at Hefei National
Synchrotron Radiation Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S06SA01 – Overview of the Next Generation of Fermilab Collider Software . . . . . . . . . . . . . . . . . . . . . . . .
S06SA02 – Ideas on a Generic Control Systems Based on the Experience on the 4 LEP Experiments Control System .
S06SA03 – The LEP Alarm System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S06SA04 – The Software for the CERN LEP Beam Orbit Measurement System . . . . . . . . . . . . . . . . . . . . . .
S06SA05 – A VMEbus General-Purpose Data Acquisition System . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S07IC01 – Interfacing Industrial Process Control Systems to LEP/LHC . . . . . . . . . . . . . . . . . . . . . . . . . . .
S07IC02 – SPS/LEP Beam Transfer Equipment Control Using Industrial Automation Components . . . . . . . . . . . .
S07IC03 – EPICS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S07IC04 – A Front-End System for Industrial Type Controls at the SSC . . . . . . . . . . . . . . . . . . . . . . . . . .
S07IC05 – The Influence of Industrial Applications on a Control System Toolbox . . . . . . . . . . . . . . . . . . . . .
S08NC01 – ARCNET as a Field Bus in the Fermilab Linac Control System . . . . . . . . . . . . . . . . . . . . . . . . .
S08NC02 – Multi-Processor Network Implementations in Multibus II and VME . . . . . . . . . . . . . . . . . . . . . .
S08NC03 – A Distributed Design for Monitoring Logging and Replaying Device Readings at LAMPF . . . . . . . . . .
S08NC04 – Synchronous Message-Based Communication for Distributed Heterogeneous Systems . . . . . . . . . . .
S08NC05 – The Transmission of Accelerator Timing Information around CERN . . . . . . . . . . . . . . . . . . . . . .
S08NC06 – Time and Load Measuring in the SPS/LEP Control System . . . . . . . . . . . . . . . . . . . . . . . . . . .
S08NC07 – The ELETTRA Field Highway System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S08NC08 – Network Communication Libraries for the Next Control System of the KEK e⁺/e⁻ Linac . . . . . . . . . .
S08NC09 – A Program Development Tool for KEK VME-MAP Control System . . . . . . . . . . . . . . . . . . . . . . .
S08NC10 – Network Performance for Graphical Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S08NC11 – A New Approach in Development of Data Flow Control and Investigation System for Computer Networks .
S09DPP01 – Concurrent Control System for the JAERI Tandem Accelerator . . . . . . . . . . . . . . . . . . . . . . . .
S09DPP02 – Palantiri: A Distributed Real-Time Database System for Process Control . . . . . . . . . . . . . . . . . .
S09DPP03 – Intelligent Trigger by Massively Parallel Processors for High Energy Physics Experiments . . . . . . . .
S10TS01 – Realtime Aspects of Pulse-to-Pulse Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S10TS02 – Injection Timing System for PLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S10TS03 – Automated Control System Structure of the USSR Academy of Sciences Kaon Facility . . . . . . . . . . . .
S10TS04 – The Development of RF Reference Lines and a Timing System for Japan Linear Collider . . . . . . . . . . .
S10TS05 – A New VME Timing Module: TG8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S10TS06 – Modular Pulse Sequencing in a Tokamak System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S10TS07 – The Timing System of the RFX Nuclear Fusion Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . .
S10TS08 – An Optical Fiber Phase Lock Network of a Radio Interferometer . . . . . . . . . . . . . . . . . . . . . . . .
S11LLC01 – Replacing PS Controls Front End Minicomputers by VME Based 32-bit Processors . . . . . . . . . . . . . .
S11LLC02 – Device Controllers Using an Industrial Personal Computer of the PF 2.5-GeV Electron Linac at KEK . . . .
S11LLC03 – High Accuracy ADC and DAC Systems for Accelerator Control Applications . . . . . . . . . . . . . . . . . .
S11LLC04 – Driving Serial CAMAC Systems from VME Crates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S11LLC05 – Fast Automatic System for Measurements of Beam Parameters of the MMF Linac . . . . . . . . . . . . .
S11LLC06 – Beam Position Monitor Multiplexer Controller Upgrade at the LAMPF Proton Storage Ring . . . . . . . .
S11LLC07 – The KEK PS Fast Beam Loss Monitor System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S11LLC08 – Non-Destructive Fast Data Taking System of Beam Profile and Momentum Spread in KEK-PS . . . . . . .
S11LLC09 – A CAMAC-Resident Microprocessor for the Monitoring of Polarimeter Spin States . . . . . . . . . . . . .
S11LLC10 – High Accuracy Measurement of Magnetic Field in Pulse Magnetic Elements . . . . . . . . . . . . . . . . .
S12FC01 – Feedback – Closing the Loop Digitall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S12FC02 – Generalized Fast Feedback System in the SLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S12FC03 – Smart Machine Protection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S12FC04 – Feedback Systems for Local Control of Race Track Microtron RF Accelerating Sections . . . . . . . . . . .
S12FC05 – PLS Beam Position Measurement and Feedback System . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

208
214
218
224
228
232
235
239
243
246
254
260
265
269
274
278
283
287
291
295
299
302
306
310
313
318
322
326
329
333
336
340
345
349
352
356
360
364
367
371
375
378
382
386
389
393
395
399
403
406
408
414
420
424
427

Contents

S12FC06 – A Position Feedback Control System for the Test Facility of JLC . . . . . . . . . . . . . . . . . . . . . . . .
S12FC07 – RF Control System of the HIMAC Synchrotron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S12FC08 – Development of a VME Multi-Processor System for Plasma Control at the JT-60 Upgrade . . . . . . . . .
S12FC09 – Very Fast Feedback Control of Coil-Current in JT-60 Tokamak . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI01 – Workstations as Consoles for the CERN-PS Complex, Setting-Up the Environment . . . . . . . . . . . . .
S13MMI02 – General Man-Machine Interface Used in Accelerators Controls: Some Applications in CERN-PS Control
Systems Rejuvenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI03 – The Replacement of Touch-Terminal Consoles of the CERN Antiproton Accumulator Complex (AAC) by Office
PCs As Well as X-Windows Based Workstations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI04 – The Elettra Man-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI05 – Exploiting the X-Window Environment to Expand the Number, Reach, and Usefulness of Fermilab Accelerator Control Consoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI06 – A Virtual Control Panel Configuration Tool for the X-Window System . . . . . . . . . . . . . . . . . . . .
S13MMI07 – X-Window for Process Control in a Mixed Hardware Environment . . . . . . . . . . . . . . . . . . . . . .
S13MMI08 – An Open Software System Based on X Windows for Process Control and Equipment Monitoring . . . . .
S13MMI09 – Porting Linac Applieation Programs to a Windowing Environment . . . . . . . . . . . . . . . . . . . . .
S13MMI10 – A New Workstation Based Man/Machine Interface System for the JT-60 Upgrade . . . . . . . . . . . . .
S13MMI11 – A Flexible Graphic Display System for Accelerator Control . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI12 – Human-Machine Interface Software Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI13 – Correlation Plot Facility in the SLC Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S13MMI14 – Iconic Representation of Particle Beams Using Personal Computers . . . . . . . . . . . . . . . . . . . . .
S14OOP01 – Object-Oriented Programming Techniques for the AGS Booster . . . . . . . . . . . . . . . . . . . . . . . .
S14OOP02 – A Simplified Approach to Control System Specification and Design Using Domain Modelling and Mapping
S14OOP03 – The Direct Manipulation Shell: Creating Extensible Display Page Editors . . . . . . . . . . . . . . . . . .
S14OOP04 – Object Oriented Programming Techniques Applied to Device Access and Control . . . . . . . . . . . . . .
S14OOP05 – An Object-Oriented Implementation of the TRIUMF 92 MHz Booster Cavity Control System . . . . . . . .
S14OOP06 – The State Manager: A Tool to Control Large Data-Acquisition Systems . . . . . . . . . . . . . . . . . . .
S15CSE01 – CASE in CERN’s Accelerator Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S15CSE02 – Automation from Pictures: Producting Real Time Code from a State Transition Diagram . . . . . . . . . .
S16MS01 – SSC Lattice Database and Graphical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S16MS02 – Framework for Control System Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S16MS03 – The LEP Model Interface for MAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S16MS04 – Optimization of Accelerator Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S16MS05 – Modelling and Optimization of Beams Dynamics in Linac . . . . . . . . . . . . . . . . . . . . . . . . . . .
S17AIA01 – Development of a Diagnostic System for Klystron Modulators Using a Neural Network . . . . . . . . . . .
S17AIA02 – Diagnostic Expert System in the RF Linac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S17AIA03 – GLAD: A Generic Lattice Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S17AIA04 – Development of Operator Thinking Model and its Application to Nuclear Reactor Plant Operation System
S18BPA01 – Operational Decoupling in the SSC Collider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S18BPA02 – Frequency Domain Analyses of Schottky Signals Using a VME Based Data Server and a Workstation Client
S18BPA03 – New Controls for the CERN-PS Hadron Injection Process Using Operating Tools and High-Level Accelerator
Modelling Programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S18BPA04 – CARSO – A Program for Automated First Turn Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S19SP01 – Control Protocol: The Proposed New CERN Standard Access Procedure to Accelerator Equipment. Status
Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S20PD01 – Man-Machine Interface Workshop Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S20PD02 – Summary of Panel Discussion on Standards and World-Wide Sharing of Software . . . . . . . . . . . . .
S20PD03 – Panel Discussion on Management of Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S21CS01 – Issues in Accelerator Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

431
434
438
442
446
452
456
460
464
468
471
475
479
483
487
490
493
496
500
505
511
514
520
524
528
535
538
542
546
550
555
558
562
566
570
576
579
583
587
591
595
597
598
602

Appendices
List of Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Institutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
List of Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

613
613
619
626

Contents

vii

viii

Contents

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

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-S01SRA01

LEP

Figure 1
Logical schematic of the networks

S01SRA01
2

2

Status Reports: Accelerators

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

information that he needs but not swamped by auxiliary data that
he rarely uses. Online documentation is a big help, particularly
when the applications are new.

3. Different types of user
The control systems of SPS and LEP are used at different times
by a variety of different personnel. These largely divide into
three categories; operators, accelerator physicists and equipment
specialists, each of whom have somewhat different requirements
for the control system. These requirements are not only for theunderlying architeeture (network, operating system etc), but also
for the applications that run on top of it. In other words, the user
here is seen as the person who runs the applications programs,
rather than the person who writes them.

Since many tasks have to be performed at the right time in asequence, the applications that perform them need to be highly
reliable. Since operations is a long and repetitive process, it isessential that the speed of execution of programs is adequate,
which generally means completion of the task in a matter of
seconds. Good error reporting is also very important.
Key requirements;

All types of user of course need reliable network
communications, with good diagnostics when things go wrong.
An adequate speed across the network from console toequipment is also generally required.

ease of use
stability
standardisation
execution speed
error reporting

3.1 Equipment specialists
Equipment specialists need to access a diversity of accelerator
hardware, setting and reading a multitude of parameters that are
not of interest to other users of the control system. In many cases
they also need to do this locally, in order to closely monitor theeffects on their equipment This means that they need to run
specific programs both in the central control room and in thefield, the latter requiring local console facilities. They may wellwant to run locally when the network is down. Most of these
programs are written by the person who will run them, or at leastby a close colleague, and as such the reliability of the application
is not of great importance.

3 3 Accelerator physicists
Accelerator physicists have essentially the same requirements as
the operators, except for the important addition of flexibility toallow new, non-standard applications to be used. Indeed sincemachine development periods usually involve doing several
unusual things, standardisation and error reporting are not soimportant
Key requirements;
flexibilty

In many cases the amount of equipment accessed is far morethan during normal operations, in order to thoroughly test asystem, for example. For this reason the speed can be of prime
importance to the equipment groups.

ease of use
stability
execution speed

Key requirements;

4. Comparison of the different control systems

local console facilities
execution speed

Table 1 summarises the results discussed in more detail here.
In all three cases the speed and reliability of the network is
adequate. However when there is a problem, it is much easier topinpoint on the TITN system than on the Token Rings, whichhave become extremely complex.

3 .2 Operators
Operators rarely work on individual pieces of equipment, butrather on combinations of accelerator systems or even on theaccelerator as a whole. In performing this work they prefer to seea high level of standardisation across the different applications
and across the different accelerators. The applications also need
to be easy to use, with the operator being presented with all the

Local facilities are also better on the TITN, where much of theequipment data is stored locally rather than in a central database.

S01SRA01
Status Reports: Accelerators

3

3

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

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

Table 1

sextupoles, octupoles etc were all controlled by different suites
of programs all essentially doing the same thing. Adding a new
system involved adding a new suite of programs to control iL
Apart from the obvious problems of duplication of effort, thishas also led to a certain diversity of the way similar functions had
to be perfonned in different applications, which is very
confusing to the user and makes it difficult to remember how todrive the different programs.

Comparison of observations
SPS old

SPS new

LEE

Network
Speed
Reliability
Diagnostics
Local facilities

•• ••
•• ••
••• •
••• ••••••

Because it is so easy to write or modify programs in thisenvironment, in the absence of any real software management
the stability of the applications is never fully achieved, andmaintena11ce is consequently very difficult.

••

The very limited memory available in the control room consoles
meant that most of the applications had to be kept small, and as adirect consequence of this error reponing had to be kept to aminimum, as did commenting the code.

Applications
Execution speed
Stability
Error reportingStandardisation
Flexibility
Ease of useKey•• •• ••• ••• •• ••• •• ••• ••••• • •••• ••• •••Finally the speed at which the applications run has been found tobe adequate. Since no online database exists the individual
programs do their own data management, and though this brings
its own problems it tends to be fast. Consequently the speed isdetennined by that of the NODAL interpretor and that of the
TI1N network. As a benchmark. sending a 100 point amplitude
vs time function to the accelerator takes around I second per
hardware address, which is considered acceptable .

4.2 SPS new
There were two significant differences between the way the new
SPS applications were developed as compared to the old. First! y
the overall functionality of the software needed to operate theaccelerator was analysed in detail before any design wasconsidered, and secondly the underlying data structures werecompletely detennined before any implementation wasundertaken [4]. By its very nature this kind of softwaredevelopment leads to software that needs little change once
implemented, and results in a very stable system. The highly
modular way in which the applications were designed allowed
an easy and standard way of handling errors, and the error
reporting is excellent.

The more blobs the better

•

••
•••

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA01

poor
adequategood

4.1 SPS old
A key feature of the NODAL based control system is flexibility.
It is extremely easy to produce a working application program,communicating with the machine and displaying data to the user.
While this is an excellent feature, particularly for equipment
testing or for one-off applications, as operations become more
complicated it becomes more difficult to control the overall
coherence of the system.

Knowing the detailed functionality led to a high unifonnity, notjust at the level of the operator interface [5] but more generally inthe facilities the different applications shared. As examples there
is only one function editor, one dataviewer and one applicationthat is able to send to the equipment anything from a single
function to the settings for the whole machine. This has
contributed greatly to the ease of use of the software, and this isenhanced by a standard online help facility describing how to

In the SPS the operational applications grew out of equipment
commissioning programs, essentially on a system by system
basis, and in an iterative way. As an example quadrupoles,

S01SRA01
4

Status Reports: Accelerators4

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

drive the applications.
The operational software relies heavily on servers running at alllevels of the network, from the control room Apollos down to thefront end computers. While communication between theseservers is normally transparent to the user it often involves
passing through several bridges. If one of the bridges or servers
dies it is sometimes difficult to diagnose which one, and in manycases a procedure of sequentially restarting one after the other isrequired.

Having a sound definition of the data has allowed theapplications to be largely data driven, giving coherence to thedifferent accelerator systems and allowing new systems to be
integrated without writing a single word of code.
The major disadvantage of this approach is that the software has
been produced specifically to operate the SPS in the various
modes forscen over the next ten years. Any novel running of theaccelerator during machine development sessions invariably
requires new features which are very difficult, sometimes
impossible, to accomodate. Up to now these problems have been
overcome by exploiting the high flexibility of the old TI1N
system.

Furthermore many applications are dependant on certain
computers to be up in order to run. There are presently around l 0such critical nodes on the control room token ring, the failure of
any one of which would affect operations to some extent, inmany cases seriously.

The speed of execution of tasks is similar to the old system, but
in this case database access times and the TI1N network are thedetermining factors. The reliability of the gateway into the TI1N
is not good but problems are easy to spot and rectify.

These two implementation details directly affect the overall
stability of the software needed to run the machine.

4.3 LEP

Quite apart from the application software used to drive theaccelerator, there is another area of the control system that is ofgreat importance during routine operation of the machine,namely the surveillance system.

5.

Before the construction ofLEP was complete, an analysis of thesoftware required to run the machine was made. Naturally theemphasis was put on the software needed to commission theaccelerator, and for the stanup of LEP the controls andequipment groups provided a suite of powerful utilities forsending settings to and acquiring data from the hardware. Theseutilities exist as commands on the control room consoles andprovide a means of quickly making script programs to do
standard or non-standard things to the accelerator. Much use ofthis facility has been made during the commissioning phase, andmore recently by accelerator physicists during machinedevelopment sessions.

Ideally this should work on the simple principle that software,
running without operator intervention, should check that allelements required to be ON are ON, that those that should be
OFF are OFF, and that all settings stay within a tolerance
acceptable for operations. This software, running frequently,
should report any abnormal findings to an alarm system forprocessing prior to presentation to the operator as a new alarm on
his screen [6].
In practice the viability of such a system depends very much onother parts of the control system. It is imperative for such asystem to have available a definitive source of data reflecting theway the machine is actually supposed to run at the time.
Furthermore because most machines run in several modes ofoperation, each requiring a different configuration, this image ofthe machine has to be dynamic.

The applications used today in operations also make heavy use
these utilities for accessing the hardware. While this may be
convenient for the programmers it invariably introduces
overheads in the execution speed. The speed is further reducedby the underlying online data organisation, since the structuringof the data does not reflect the way in which we now want to run
the machine.

It has already been mentioned that the LEP operational
applications have not been developed in an integrated way, andone consequence of this is that there are several different ways ofstoring the actual machine settings. This makes it very difficult
to provide standard surveillance programs; in reality each set of
equipment has to have it's own program, a situation which is ofcourse very difficult to administrate. So while for LEP thecentral alarm server works well, the amount of useful
information reaching the operator is presently rather limited.

The development of the operational applications has notfollowed an integrated approach, which has brought low
coherence and a very variable level of error reporting.
Uniformity across the user interface applications has beenachieved to some extent. Following the standards of the SPS has
ensured a look and feel of the individual applications that is liked
by the operators, and most programs are now easy to use.

S01SRA01
Status Reports: Accelerators

5

5

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

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 Publishing

The same problems were encountered with the alarm systemrunning on the SPS TITN network. Again there was no coherent
image of the machine, and it took several years before the alarmsystem was providing infonnation of sufficient credibility forthe operators to use with confidence.

The same thing now has to be done for LEP, this time after 3
years experience but drawing on the lessons learned in the SPS.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA01

7. References[ l) M.C. Crowley-Milling, "The Design of the Control System

for the SPS", CERN 75-20

It is ironic that the new SPS operational software, which isdriven from a central online database, does not yet have any kindof alarm system. Indeed we are experiencing problems due tothis as more and more systems are migrated from the TITN to theApollo-based software, since there is presently no means ofsurveying them. The aim is eventually to use the same systemthat is presently in use for LEP, hut with simple surveillance
programs comparing measurements with settings in the online
database.

(2) M.C. Crowley-Milling, "Experience with the Control

System for the SPS", CERN 78--09(3(

6. Conclusions and remarks

R. Rausch, "Real Time Control Networks for the LEP and
SPS Accelerators", in Control Systems for Experimental
Physics, Villars, Switzerland, September 1987, pp.
244-247.
P.G.Innocenti, 'The LEP Control System", in Accelerator
and Large Experimental Physics Control Systems,

In the case of both the SPS and LEP, the network and control
room utilities proved adequate during the running in of themachine. As testimony to this, beam was circulating in LEP one
or two days after first injection, and the first zo was reported
within a month.

Vancouver, Canada, 1989, pp 1-5
P. Lienard, ''The SPS and LEP Control Network
Architaecture", in Accelerator and large Experimental
Physics Control Systems, Vancouver, Canada, 1989, pp
215-220.

However, remember also that machine commissioning is doneby specialists and over a limited period of time. When it comesto building the complex, integrated software packages that are
required in routine operations, it has proved difficult to do sofrom the utilities provided. What is needed is a review of theoperational requirements and a corresponding rewrite of theapplication software. Furthermore it is very difficult todetermine these operational requirements in advance of getting
hands-on experience of the accelerator.

(4) R. Bailey, J. Ulander, I.T. Wilkie, "The New Applications

Software for the CERN SPS", in Control Systems forExperimental Physics, Villars, Switzerland, September
1987, pp. 158-163[5] A. Ogle, J. Ulander, I.T. Wilkie, "Experience with
Workstations for Accelerator Control at the CERN SPS", in
Accelerator and large Experimental Physics Control
Systems, Vancouver, Canada, 1989, pp 437-441.

The new SPS software is a good example of what can be done. It
was based on 10 years experience of running the SPS in a variety
of modes, and the software produced satisfies most of theoperational requirements.

(6) M. Tyrell, 'The LEP Alann System", these proceedings.

S01SRA01
6

Status Reports: Accelerators
6

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

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 Publishing

through terminal servers. The color CRT and knobs areattached through CAMAC.
The color CRT in the LCS operator interface allows any
LCS program to be called up at the operator's demand. This
interface also gives the operator access to a number ofsupervisory tools which allow the state of any devices to be
displayed and controlled. The touch panels also allow accessto a fixed number of application programs.
LCS operator consoles are now supported in the LAMPF
Central Control Room (CCR), the Injector Control Room
(ICR), and the LANSCE Control Room (LCR). (See Figure
4 for a geographic representation of this distributed
functionality.) The main CCR control computer was thecenter of the original star configuration. It still maintains its
central position as it drives four of the five LCS operator
consoles in CCR and serves as the central repository for LCS
software and databases.
Since the RICE hardware was and still is a primary featureof the LAMPF Control System, a VAXELN front-end
computer is dedicated as its interface with the rest of thecontrol system (Figure 2). The RICE system is composed of
73 hardware data acquisition modules arrayed along the linac
and in the injector and experimental areas. A distinct advantageof the RICE system is that it supports simultaneous timed
data takes on each RICE modules. This provides a very
powerful method for acquiring longitudinal snapshots of theentire linac at a particular time on a particular beam pulse.
For untimed data takes, data caching facility is provided. In
addition, the RICE system interfaces with the accelerator "fastprotect" system. If a hardware monitor determines that too
much beam is being spilled, the fast protect hardware sends asignal that simultaneously inhibits the injector and notifies theRIV computer that a fast protect has occurred. The RIU
computer immediately reads the state of all hardware monitors
to determine where the fast protect occurred.

that know they need large amounts of data can improve theirsystem throughput by forming "aggregate devices." The LCS
data access interface makes use of information supplied by the
program to optimize network usage.
Because of the uniformity of data acquisition interfaces, if
the correct application programs and databases are supplied toit, any LCS operator console on the network could run theentire accelerator.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA02

B. PSR Control System
The PSR Control System attempts to achieve high data
throughput and reasonable operator interface response bytightly coupling a central database to external computers thatare continuously polling data. Detailed descriptions of thissystem have been published elsewhere (5-6].
A diagram of the PSR operator interface and front end
computers is given in Figure 3. All PSR operator consoles
are attached to the PSR VAX. This machine serves as theoperator interface computer and the central data concentrator.
A typical PSR operator interface screen consists of a color
graphics scope whose face is overlaid with a touch sensitive
surface. The graphics scope is driven directly from thecomputer bus; the touch panel is driven through a terminal
server on Ethernet. A set of analog control knobs is controlled
via CAMAC. The top level screen on each color graphics
scope provides an entry to a tree-structures menu of possible
programs that can be started.
The PSR front-end computers are PDP-1 ls each connected
to a CAMAC serial highway for data acquisition and control.
These front-ends are know as Instrumentation Sub-Systems(ISSes). They continuously update their local databases withdata from their serial highways. The ISSes are also connectedto each other and the PSR VAX via a separate CAMAC serial
highway over which the PSR VAX reads the latest data fromthe ISS databases and transfers changes in control values.

73 RICE Modules

Serial Highway to IS.SC.

Serial Highway for this ISS

RICEInterface

CAMAC

Timing

Unit
PSR

RIU
VAXELN

CAMAC

Color

Timing

VAX/VMS

Grapbica&ope

ISSPDP-11
RSX-II

Touch Pane

Fast Protect
SerialHi~

Ethernet

Ethernet

Figure 2. LAMPF RICE Interface Front End Computer

CAMAC

Figure 3. PSR Operator Interface and Front End Computers

LCS data acquisition is demand driven. Each node in the
LCS network contains a static database derived from a masterdatabase on the main CCR computer. Application programs
request data and issue commands through a standard data accessinterface which uses the local database to resolve device
addresses at run-time. Application programs may be split up
among several nodes. A locally designed Remote Procedure
Call (RPC) interface allows the pieces to communicate
without dealing with the complications of DECnet. Programs

Application programs running on the PSR VAX typicallyhave exclusive access to a single graphics scope. The programs
access data and set control values in the central database. They
can also be notified asynchronously of changes in databasevalues. Device data addresses in the central database areresolved at link time for many of the PSR application
programs. This limits run-time overhead, but results inproblems if the database structure changes.

S01SRA02
8

Status Reports: Accelerators

8

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

ICALEPCS1991, Tsukuba, Japan

When the Proton Storage Ring was first commissioned, it
was controlled entirely from LCR. LAMPP at that time had
operator consoles in CCR and ICR, although most operations
activities took place in CCR.
The first attempt at LCS/PSR integration was to place
PSR control consoles in CCR. Since we also wished to keep
LCR available for PSR beam development, we had to pull
cables between the two control rooms to physically connect
the remote PSR consoles with the PSR VAX. At the sametime a LCS console (CPU, color CRT, graphics scope, andknobs) was installed in LCR.
We then approached the more difficult job of sharing dataand controls between the two systems [7]. By adding software(mainly run-time libraries and a copy of the LCS database) and
LCS console hardware, we were able to make the PSR VAX
into an LCS operator interface computer. This meant that
PSR application programs could access LCS data through the
LCS data interface. Several PSR applications that wereinterested in linac data were so modified.

I---------------------1
LCS PSR I

H+lQperator Interlace

0

Q

I

l~::t.:'::1~~£1:~--~--':_ __ J
Linac

____

B. Databases?-·------<~-~-_->
H-

A database system in an experimental installation must beable to add and change device definitions quickly without
taking the control systems offline. The LCS database succeedsin this respect; the PSR database does not After a PSR device
definition has been modified, it can take hours to regenerate a
new PSR database. To be able to communicate with PSR
devices, the LCS database must contain the PSR device
names. This is possible because both systems use the samedevice naming scheme. Unfortunately, there is no automatic
scheme for rationalizing the names that occur in the two
databases. For now we use editors to compare lists of names
to determine what should be a changed.

Central Control Room
00000 0000
All.A

LANSCE
Con1rol RoomooooaooFigure 4. Distributed Functionality in the LAMPF-PSR Network

The situation with LCS programs was a bit more difficult
Since only programs residing on the PSR VAX could accessthe PSR database, we added an LCS Data System server
process to the PSR VAX. This process (which is a variant on
the standard LCS Data System server) handles network requests
for information on PSR devices. Since the LCS programs
make standard requests for data, all the LCS programs,
including the supervisory display and control tool, the LCS
knobs, and the LCS data archiver could get PSR data.
Figure 4 show the geographic distribution of LCS andPSR consoles and front-end computers. This figure does notshow details of CAMAC highways, Ethernet connections,
RICE cabling, or timing distribution.

C. Application Programs
The difference in design philosophies between the twocontrol systems is most noticeable in the application
programs. The absence of a notification on change in the LCS
data access interface makes it hard to allow PSR programs toaccess LCS data through the PSR data access mechanism. As
a compromise, we have made it possible for PSR programs toaccess LCS data through the LCS access mechanism. On theother hand, it was relatively easy to enable LCS programs toaccess (possibly old) PSR data. For application programs
driving a future common LCS/PSR operator interface weshould like to have data from both systems provided in a
uniform manner.

III. EXPERIENCE
A. Front Ends
The RICE hardware system presents some unique problems
to the control system. Since more than 60% of the LCS
hardware is attached through the RICE system and is only
accessible through the RIU front-end computer, this represents

S01SRA02
Status Reports: Accelerators

9
9

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

a major bottleneck. The fact that we have a limited amount of
RICE hardware available means that we cannot easily expand
the system.
The RICE interface can only perform one timed data takeper beam pulse. This severely restricts tuning operations
which are typically performed at low rep rates. We would liketo improve on this performance even though we would like tokeep the capability for doing synchronized timed data takes.
Other RICE problems include not being able to send analog
commands to more than one device in a RICE module at atime. This constraint creates problems when one is trying toscan wires in two wire scanners in the same RICE module.
The primary problem that we have found with the PSR
ISSes is that of performance. The PSR equipment modules
which reside in the ISSes are flexible and can acquire data
rapidly. But the overall response is slow because data isscanned and transmitted regardless of its usefulness. The
inherent flexibility becomes a problem because some modules
respond differently to the standard read and command requests
that are issued from the application programs. We need acarefully designed application program model of the world anddisciplined equipment module implementations that ensure
standard responses.

C. Control Systems Integration

Injectors

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA02

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

D. Operator Inteifaces
Neither the LCS nor the PSR operator interface lendthemselves to upgrade. The LCS technology is old and cannot
integrate graphics and control functions. The PSR screens are
becoming unmaintainable and cannot be moved to other nodes
in the network because PSR applications need to access thecentral PSR database directly. The LCS supervisory tools
allow operators to directly access any device. The PSR tools
must be recompiled to allow access to new devices. We havefound that the flexibility provided by the LCS interface is vitalin running a basically experimental accelerator.

E. Reliability and Maintainability
Hardware reliability and maintainability has been a key
issue during recent accelerator runs. The RICE hardware isgetting old and becoming difficult to maintain. Replacement
hardware is no longer being manufactured. While CAMAC
hardware is available for replacements and additions, its use inharsh environments sometimes leads to short lifetimes.
The use of long serial CAMAC highways, especially in
the PSR system, has led to difficulties in problem isolation.
Frequently it is necessary to remove one crate controller/fiber
optic driver at a time from the highway in order to isolate afault. This can be a very time consuming operation,
especially if it has to done during production.
We have also been concerned about single points of failure
within the control system. As the systems stand now, thefailure of a single LCS operator interface or front-end computer
only means that the CAMAC attached to that machine isinaccessible. As mentioned above, with the correct data files
and programs, any LCS operator interface computer in the
network, including the PSR VAX, can run the accelerator.
The failure of the RIU front-end computer would be more
serious for then we would loose all RICE data, a significant
portion of the accelerator's data.
Loss of the PSR VAX would mean loss of the entire PSR
system since the serial highway connections are only to thatmachine and the central PSR database resides on it.

IV. THE FUTURE

The concerns described in the previous sections are being
dealt with through several projects being currently planned or
implemented at LAMPF. The projects and several otherconsiderations are described in detail in a companion paper atthis conference [l]. In the remainder of this paper we will
briefly summarize these projects.
At the lowest level, the front end data acquisition hardware
will be upgraded to meet new requirements for reliability andmaintainability. The plan is to use VAXELN-based microVAXes as the standard front end computer. These front ends
will be used to replace the PDP-lls currently being used for
the PSR ISS interface to CAMAC. At the same time, it isplanned to replace the RICE hardware with CAMAC and again

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA02

use VAXELN front ends. The effect of these two projects will
be to unify all device access through a common client-server
model.
A new common operator interface project has also been
proposed. A common interface will reduce both training andmaintenance requirements.
We plan to use VAX-based
workstations as the primary operator interface. We plan to use
a user interface management system to keep the development
and maintenance of the operator interface more manageable.
Since the new data access mechanism will not
automatically put the data in the PSR database, existing PSRapplication programs may have to be changed. There is thepossibility that some of these programs may be rewritten to
make use of the new common operator interface. In the longrun, this is what we hope to do with all application programs.
To improve the overall responsiveness of the control
system, we hope to pursue several hardware upgrades beyond
replacing the front end computers and introducing operator
interface computers. Since, for a while, some application
programs will still be using the old interfaces through the
LCS and PSR central control computers, we hope to replacethem with higher performance VAXes which can be clusteredto provide hardware and file backup for each other.
With these upgrades we will be able to respond to increased
demands on the LAMPF control systems in the future. Of
most immediate interest are the controls necessary to support
the proposed Pion Linear Accelerator (PILAC) to be built at
one of LAMPF's beam lines. There are also proposals to
upgrade the PSR from 100 to 300 µA to drive a possible
pulsed lepton source, and to use LAMPF for prototype workin using an accelerator to transmute radioactive waste.

V. REFERENCES[l) R. Stuewe, S. Schaller, et. al., "Future Directions inControlling the LAMPF-PSR Accelerator Complex," theseproceedings.
[2) G. Carr, S. Schaller, et al., "The Status of the LAMPPControl System Upgrade," Proc. Europhysics Conference onControl Systems for Experimental Physics, CERN Yellow
Report 90-08, (1990) p.107.
[3] S. Schaller and E. Bjorklund, "Distributed Data Access in the
LAMPP Control System," Proc. 1987 IEEE Particle
Accelerator Conf., Washington, DC (IEEE Publishing, New
York, 1987) p. 745[4] S. Brown, S. Schaller, et al., Proc. 2nd Int. Workshop on
Accelerator Control systems (North-Holland, 1986) p. 122.
[5] P. Clout, et al., ibid., 1986, p. 116.
[6] P. Clount et al., "The Proton Storage Ring Control System,"IEEE Trans. Nucl. Sci. NS-30 (1983) p. 2305.
[7) S. Schaller, "Providing Common Data Access for the LAMPPand PSR Control Systems," Nucl. Instr. and Meth., A293
(1990) p. 416.

S01SRA02
10

Status Reports: Accelerators

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 Publishingmemory. In addition, it has on board I/O resources of four 16bit DACs, four 13-bit ADCs, 24 bits of digital control, and an
SBX bus for expansion. It is a low power(< 5 watts), 3U highEurocard-based controller in a shielded metal can that cancommunicate at a 2 Mbit/sec rate using twisted pair cabling.
We had commercial companies build 200 of these first generation ILCs. Twenty of them (10%) were not functioning when
received from the manufacturer; ten had minor problems (chipleads bent, missing chips, infant mortality, etc.) and were
repairable. The remaining ten we have not attempted to repair(they have missing traces or shorts on the circuit boards) since
we decided the cost ofrepair was not justified. We are currently
using about 140 ILCs in the accelerator, with an additional 20
to be used for the Booster-to-Storage-Ring line. See Figure 2 fora typicalinstallationshowing3ILCs,Opto-22interface, and the
3 quadrupole power supplies. We expect to use an additional
500 ILCs to complete the project (Storage Ring, Beamline Front
Ends), however, these will be the next generation design.
These new ILCs will have 16 Mhz, 80C186EB chip as the mainprocessor (a 60% speed improvement over the older IL Cs' CPU,and also lower-power dissipation), 256 Kbytes of memory, 16bit ADCs and DA Cs, 16-bit SBX interface, a serial channel, and
28 Boolean lines. The analog and digital design is completed;layout and prototyping/testing will start shortly. The cost of
the current ILCs is $650 each; the new ones will be about $950.
To exercise the ILCs, and test the accelerator hardware, we use
laptop computers (80386/80486-based), connected directly to
the ILCs, using much of the same software as we use on theoperating stations in the Control Room.

are required. These boards allow us to handle approximately
800 messages, of about 75 bytes each, per second per line.
Therefore, the total I/O bandwidth currently coming into the
CMM is approximately 720 Kbytes/sec (12 x 800 x 75). This
represents, on the average, about a 10 refresh/ sec of the entire
active part of the current accelerator database. We are currently evaluating a 33 MHz, 486 Multibus I board and aredesigning a new SBX interface that would allow us to service 8lines per Multibus board at about 1600 messages/line/ sec. At
project completion, we plan to have approximately 64 lines(using 8 Multibus I processors operating in parallel) for a total
I/0 bandwidth of 128 Mbits/sec, and a useful data rate 7.5
MBytes/ sec. This would represent, on the average, about a 15
to 20 per second refresh rate of the active database of the entire '
accelerator. We are also exploring the possibility of a second
CMM; this would double our I/0 bandwidth to 240 Mbit/sec
at a modest cost.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA03

IV. LAYER 3. (DISPLAY MICRO MODULE)
The DMM (Figure 3) consists of a 20-slot Multibus II System, bought as a unit from Intel Corp., that has fast parallel
access (via a bus converter) to the CMM. This system contains
a SCSI disc controller, an Ethernet interface, and a number ofhigh performance singleboard computers. Under current operation, weareusing2DMMs (we had not planned to install thesecond DMM till Storage Ring commissioning, so we are aheadof schedule in this area) to access the database in theCMM. The
DMMs currently use RMX II as the real-time operating system(we are evaluating using RMX III, a full 32-bit system) using
standard Intel hardware and software. The first DMM currently supports 6 (we have tried 7) commercial (Intel) 25 MHz,486-cpu boards, while the second DMM currently uses3 CPUs.
The CPUs within each DMM operate in parallel, and each has
2 serial links (we promised 1, so this doubles I/0 performancein this area) that directly connects it to the operator station.
Each of these links has the same configuration as the links
between the ILCs and the CMM (i.e., 2 Mbit/ sec). At projectcompletion, we will support at least 6 operator stations per
DMM, for a total of 12 or more for the whole accelerator. We
have enough bus bandwidth in the CMM so we could support
even a third DMM. We plan to upgrade the CPUs in the DMM
with processors that will be at least2.5 times a fast as the current
ones.

v. LAYER 4. (OPERATOR STATIONS)
Figure 3. DMM, CMM, fiber optic interface, and file server.

The operator station is the human interface of the Control
System; it presents accelerator data, including real-time data,
scope traces, and live video (via multi-media programs andhardware) to the operator. The operator can use mice, keyboards, or nine dynamically assignable/labeled knobs. Six
operator stations make up a console (Figure 4), and eachconsole is supported by one DMM. The operator stations use
33 MHz, 486-based AST Personal Computers (PC), but they are
upgradeable to faster CPUs via a simple card swap. Most use
Windows 3.0 as the operating system, a few use OS /2 1.2. The
serial communication links to the DMM allow us about 8001000 database accesses/ sec for each PC in the database client/server "request" mode. In the "driven" (i.e., when the DMM
drives the PC) we can achieve about 1500 messages/ sec. Both

III. LAYER 2. (COLLECTOR MICRO MODULE)
The CMM (Figure 3) contains all the data gathered from all
the ILCs (i.e., it represents the entire accelerator database at any
moment). The ILCs are connected to the CMM via fiber-optic
lines. The serial communication on these lines is bi-directional(though using only a single fiber), and the bitrateis2Mbit/sec.
We are currently using 12 of these lines for a total I/O physicalbandwidthof24Mbit/sec. Weuseacommercial(Intel)20 MHz,386-based Multibus I board with 4 single chip processors (viacustom built SBX modules) to service 4 serial lines. Therefore,
to service the 12 lines currently in use, 3 Multibus I processors

S01SRA03
12

Status Reports: Accelerators12

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

ICALEPCS1991, Tsukuba, Japanof these rates are CPU limited, we expect them to be about 2500
and 3000 messages/sec (at those rates we will be 1/0 limited)
respectively at project completion. Since we plan to have atleast 12 operator stations, we will attain accesses in excess of
30,000/sec; however, even at these rates, we are using only
about 10% of the bus and data bandwidth available in the
CMM-DMM combination. These facts demonstrate the very
high performance available in our star-based, shared memory
approach to control system design. The choice of the PC as ourhuman interface has proved to be a judicious one. As the
popularity of Windows grows, the availability of commercial
software for use in the control system grows rapidly. We
currently make extensive use of DESIGNER (graphic editingtool), EXCEL (spread-sheet), TOOLBOOK (HyperCard-likepackage), VISUAL BASIC, TURBO PASCAL for WINDOWS,
as well as the usual languages C, C++, etc. With these PCs, we
also have available the usual collection of word processors,
databases, and utilities (screen capture, etc.). The use of thiscommercial software has greatly increased our productivity,and has allowed us to keep our staffing requirements very low.
The one area where we need improvement is in support of full
32-bit modeling applications. These are currently done on
workstations and can access the database via Remote Procedure Calls (RPC). We plan to shift this work to OS/2-2.0, or its
equivalent, as soon as possible. In the meantime, X-Windowsbased applications can appear as a window on the PCs underWindows 3.0 or OS/2, using commercial software.

A. Scheduling and Costs.

JACoW Publishing

The control system is being used to commission the accelerator as it is being built. Weare on target both in terms of costand schedules, and are beginning to shift over to pre-operation.
The staffing to date has been exactly as projected (with fiveprogrammers, one coordinator, and one half of an electronic
designer) over the length of the construction project. Cost to
date is approximately $3.65M of a total projected cost of $5M.
Storage Ring commissioning is scheduled for the 2nd quarterof 1992, with project completion in 1993.

VII. ACKNOWLEDGMENT.
This work was supported by the Director, Office of Energy
Research, Office of Basic Energy Sciences, Materials Sciences
Division of the U.S. Department ofEnergy, under Contract No.
DE-AC03-76SF00098

VIII. REFERENCES.
[1] Magyary et al., "Advanced Light Source Control System,"
Lawrence Berkeley Laboratory, LBL 26028 and Proc. 1989
IEEE Particle Accelerator Conf., Chicago (IEEE Publishing, New York, 1989).
[2] Magyary et al., "The Advanced Light Source Control
System," Nuclear Instruments and Methods in Physics
Research, A293 (1990) 36-43, North Holland.

Figure 4. Operator console with six operator stations.

VI. LAYER 5. (NETWORK)The PCs are networked via Ethernet to a Laboratory-wide
network. This allows workstations, etc., to access the database
via RPCs. An IBM RS6000 Workstation is used by the physicists for modeling and 32-bit numeric intensive applications.
We also have a PC on this network with a 600-Mbyte disk as afile server for the operator stations and software development.
A spare server is available to minimize down-time in case of
failure by the main server. This network will also be the "user''interface into the control system for wiggler /undulator andbearnline front end controls. A protection scheme to limit user
control, to specified devices only, is under development.

S01SRA03
Status Reports: Accelerators

13

13

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-S01SRA04

SLCWEST
Profile Monitors

Jan. 1989
Critical units
underUned
Index to abbrevations
AE - used for energy spreadmonitoring£ - used for emittance (T1=0)£ LJ04

0

Lll9
1153

0

Lll6
1453

0

Lll2
1853
Ll08
2253

900 •

Ll02
£ 9!4/6 •

LI04
.2653

£ Ll02137 •Location of beam

monitors in the SLC injector,

emittance and other n;;·r:>nnPtP'""tobeam are affected
orbit distortions. One
understand this is to remember that wake field tails arecausedoff axis beams in the linac's disk loaded wave
guide. As a result of this sensitivity, the mix of beamdiagnostic systems required for the SLC is affected. Diagnostics which measure beam shape, beam size, and emittance are many. As shown in Figures 1 and 2, there aresystems.

monitors and 37 wire
scanners.
The beam
monitorhas been described
elsewhere [3]. As noted there and elsewhere [4], the useof profile monitors is destructive to the beam, but they
allow shape changes to be observed in real time and givedetailed information of transverse tail formation. (SeeFigure 3.) In concert with an adjustable upstream quadrupole, beam profile monitors can be used to measureemittance [5].

S01SRA04
Status Reports: 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

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-S01SRA04

Damping Rings

e

e

·~

....e

•
:

SpecialPurposee+ Return Line
11-91
7061A1

Figuxe 2. Location of wire scanners in the SLC.

Figure 3. Images of an electron bunch on a profile monitor at 47 GeV showing wakefield growth with increasing
oscillation amplitudes. The images from left to right are for a well-steered beam, a 0.2 mm oscillation, 0.5 mm oscillation and a 1.0 mm oscillation, respectively. The beam intensity is 2 x 10 10 electrons. The core sizes crx and cry are about
120mm.

The wire scanners have been discussed
elsewhere [6]. The beauty of wire scanners is that they
allow nondestructive measurement of the beam emittance, and thus could be used as an online device in, forexample, beam feedback systems (we have not yet doneso).

John Seeman has pointed out the need for what hecalls "corroborating measurements." As an example ofwhat this term means, consider the fact that emittancecan be measured by both profile monitors and wire scanners. The presence of two techniques allows the resultsof such measurements to be compared. If the measurements are equivalent, then they corroborate (or confirm)
one another. This increases the credibility of the resultsan important factor in a prototype accelerator.
Beam position monitors (BPMs) used in the SLC
number approximately 1700. All the BPMs in the Jinac
itself are instrumented for single pulse data acquisition;
every BPM so instrumented can be read out, under control of the timing system, on any given pulse for a particular beam bunch. BPM systems in the SLC arcs and in thedamping rings have multiple BPMs which are multiplexed into a common data acquisition module; this precludes reading all the BPM inputs into one of thesemodules on the same beam pulse. However, over the
past year, we have had a couple of projects to "demultiplex" BPMs; that is, to instrument more BPMs in the same
way as the linac BPMs so that orbit measures on a single
beam pulse can be done. The builders of future Jim'M
colliders need to look carefully at the requirements for
single pulse orbit measurement.
The impact of these beam diagnostic systems on thecontrol system is large. Fundamentally, the data acquisition requirements for a linear collider correspond to thatof the "first tum" for a circular collider. The abi Ji ty totake a single pulse "snapshot" of the orbit, or a snapshotof many parameters associated with the beam or withindividuaJ pulsed devices is a requirement. As the references detail, emittance and beam shape measurements
require sophisticated image processing and accelerator
matrix manipulation and fitting. As the maps of profile
monitors and wire scanners show, and as the number <if
BPMs implies, these systems are everywhere, and timespent on generaliz.ation and sophistication is well spent.
To restate the functional requirement: linear collidL'r
operation requires careful attention to diagnostics whichmeasure beam orbit position and distortion, emittancL',and beam shape.

S01SRA04
16

Status Reports: Accelerators

STABILITY, AUTOMATIONThe SLC is a large complicated device. Stability of the
SLC is a large problem. Feedback systems, in which thecontrol computer system is an active component of the
feedback loop, have been oparational at the SLC since1988. Feedback based on signals derived from beamdiagnostic instrumentation allows a much higher degreeof control over the beams, since these data can beacquired from many sources and statistically fit. Single
device tolerances could never provide this level of stability. The main application of these feedback systems is
steering (launch angle and position); but feedback systems to correct energy, energy spread, and collision point
are also used.
The earliest version of these was "slow feedback,"with update times measured in tens of seconds; suchloops are closed through the VAX mainframe which is thehighest hierarchical level in the SLC control system. This
was quickly augmented by prototypa pulse-to-pulse
feedback ("fast feedback") systems using a dedicatedmicroprocessor based system, instrumentation, and controlled steering supplies. This prototypa system was avery successful, but could only be replicated with difficulty and was difficult to maintain. We have since generalized this prototype and integrated it into the SLC
control system. That generalization is propagating at a
rapid rate to a large number of installations in the SLC,
replacing both the prototype version of itself as well as
many of the older "slow feedback" applications. This
being presented tosystem is described in anotherthis conference [7].
One of thebenefits of these fast feedback sysallow
forward in automation thatAs described[8],
a number of different events
such class of events
each time anturns·an:~~~tulecl knob, that event isAsknow that fasthas"""''-'"'"'""'""
to do knob turns
as much as
vention of80%; fastis doing the knob turning for us.

The SLC is the prototypa for a linear collider. The
SLAC staff is working to understand how a linear collider
the SLC accelerator physicists has noted
works.
that " ...there are more interesting accelerator physics
tests being proposed each day than there is accelerator
time to parform them" [4]. The environment is such that
there are numerous questions to be answered and there
is often the need find answers quickly so that the answers
can be incorporated into oparation. It is an essentialfunctional requirement that the control system supply

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA04

tools that allow the staff to do machine physics experiments which have never before been even considered.
The major tool-actually a set of tools-for this is theCorrelation Plot Facility, described in a poster session
papar of this conference [9]. This powerful software provides a set of tools for realtime online analysis, fitting,plotting, control and measurement of a large number ofvariables. The facility is well integrated into the SLC control system, and programs or functions which are developad for physics studies are often incorporated into
oparational software [10].
This functional requirement will exist for the next
linear collider, since it will be built on an exparience baseof one-the SLC.

COMMENTS
The control system for an accelerator must satisfy
many functional requirements-many more than thefour described above. These four were described because
SLAC's exparience shows that they are, in some way,
unique to the class of linear colliders.
There are other functional requirements which arecommon to all accelerators. And there are functional
requirements which are unique to the SLC-a prototype
linear collider based on the existing SLAC linac. Neitherof these classes of functional requirements have been discussed, although some of the solutions described above
help to meet them.
The four functional requirements described above
have been awhich has been met by a large
team ofcommitted people. Some of that team isnamed inbut there arewould like to thankson, Nan Ph1nri<•v~n1~1Jva:ru for recent discussions on this topic.

For a furtr-':!r discussion, see M. Ross, "Machine Protection Scilemes for the SLC," 1991 Particle Accelerator Conference.

[2] S. Clark, A. Grillo, N. Spancer, D. Hutchinson,
J. Olsen, D. MiUsom, G. White, T. Gromme,
S. Allison, K. Underwood, M. Zelazny, and H. Kang,"Smart Machine Protection System," Proceedings ofthe International Conference on Accelerator and Large
Experimental Physics Control Systems.
[3] M. C. Ross, "Beam Diagnostics and Control for SLC,"
1987 Particle Accelerator Conference.
[4] J. T. Seeman, "The Stanford Linear Collider," SLACPUB-5607.

S01SRA04
Status Reports: Accelerators

17

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[5] M. C. Ross, N. Phinney, G. Quickfall, H. Shoaee, and[8] N. Heinen, N. Spencer, and J. Tinsman, "Improving
the Reliability in the SLC Control System," 1989
ICALEPCS Proceedings. ·J. C. Sheppard, "Automated Emittance Measurements in the SLC," 1987 Particle Accelerator Conference.
[6] M. C. Ross,

J. T. Seeman, E. Bong, L. Hendrickson,

D. McCormick, and L. Sanchez-Chopitea, "Wire
Scanners for Beam Size and Emittance Measurements at the SLC," 1991 Particle Accelerator Conference.

[7] L. Hendrickson, S. Allison, T. Gromme, T. Himel,
K. Krauter, D. Nelson, F. Rouse, R. Sass, and
H. Shoaee, "Generalized Fast Feedback System in
the SLC," Proceedings of the International Conference on

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA04[9] L. Hendrickson,

N. Phinney, and L. SanchezChopitea, ''The SLC Correlation Plot Facility,"

Proceedings of the International Conference on
Accelerator and Large Experimental Physics Control
Systems.
[10) For example, M. C. Ross, N. Phinney, G. Quickfall,
H. Shoaee, and J.C. Sheppard, "Automated Emittance Measurements in the SLC," 1987 Particle Accelerator Conference.

Accelerator and Large Experimental Physics Control Systems.

S01SRA04
18

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: Accelerators

19

19

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 Publishing

The most important features for the generator tests are thecontrol of the terminal voltage and the current flow inside theaccelerator tank. The GVMs (Generating Volt Meter), which
register the electric field along the tank in a standard electrostatic accelerator, are inefficient because the internal electrodestructure shields the field in the Vivitron.

color screen (Figure 5). A second identical computer near the
first one is dedicated to the off-line data analysis (Figure 6)
and the back-up. A third identical computer is devoted to thesoftware development and to the process data base management. They are linked together by the Localtalk/Appletalk
LAN. A Fastpath bridge provides access to a SUN server via
Ethernet. They all run under MacOS. Communication between
level 1 and level 2 is made by a NuBUS - VME Micron fastparallel interface. The two operating systems share a VME
mailbox.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA05

Therefore, no beam being available, the terminal voltage
is given by the sum of all the inter-electrode voltages. The
only way to determine them is to measure the current flow
along the calibrated resistor chains in each section. We developed therefore a powerless floating current monitor for the Vivitron (Figure 1), starting from an original Munich design [4].
The information is fed to the outside ground level by a plastic
optical fibre. The measurement range extends from 1 µA to
1 mA with an accuracy of about ±1 %.

C. Tests of the generator
The tests of the generator started in the early 1991. Aterminal voltage of 17.5 MV, the half of its nominal value, hasbeen reached within a few weeks. Some tens of sparks occurred without disturbance of the process control.

B. Set-up
This reduced control system has been designed on the fullscale control scheme but with some limitations (Figure 2).

About 100 parameters are controlled. Unidirectional andbidirectional currents are measured by about 60 current monitors and displayed as bar graphs on the central main permanentcolor screen (Figure 3). The column currents are displayed inreal time as well as their differences in order to monitor thecurrents distribution and to locate current leaks. The belt
charging currents and balance are also displayed graphically inreal time. Intershield and terminal voltages are determined anddisplayed numerically on the same screen [7].

Figure 2. The control set-up for the generator tests.

Data acquisition and control is achieved by real time
crates on levels 2 and 3, model of the final ones. Two disklessdownloaded 3U VME crates on level 3, one at each end of themachine, are equipped with opto-isolated TIL I/0, 12 bits analog I/O, and timer/sequencer I/O boards. They communicate
with level 2 by two serial glass fibre links. A 6U VME cratewith hard disk on level 2 is in charge of the downloading of
the former level 3 crates, of the message switching and of thedata managing. The VME crates run under the OS9 real time
operating system.

One standard, cheap, off-the-shelf available Macintosh
Ilfx 4/40 computer provides process control on level 1. It also
provides the operator interface with multi-screen displays on
one main 19' high resolution color screen (Figure 3), one 13'
touch sensitive color screen (Figure 4) and one standard 13'

Figure 3. The operator main control display.

The control is achieved by the right hand touch sensitive
color screen (Figure 4 ). Virtual push buttons switch the drive
motors and the high voltage power supplies ON and OFF.
They also control sliders which drive the charging systems. Interlocks are provided for security. The status is displayed byvirtual green, yellow or red lights.
The left hand color screen is devoted to all the other functions : schematic display, wiring display, off-line and on-line

S01SRA05
20

Status Reports: Accelerators
20

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Figure 6. The 3D time I position current display.

Figure 4. The command screen.

IV. THE FUTURE
Equipment crates on level 3 will migrate inside the accelerator tank. The possibility to fit equipment crates inside thetank and their reliability have been tested in the :MP accelerator. After more than one year and hundreds of flashes of up to
17 MV, we registered no transmission failure, no optical fibre
failure, no measurement disturbance during flashes and only a
few electronic failures (5). The number of these crates will increase to more than ten.
The concentrator crates on level 2 will be connected to ahigh speed LAN and their number will grow. The process control and operator interface will be achieved by standard workstation clusters connected to the LAN. Processing power willgrow from level 1 to levels 2 and 3. Software has to be more
flexible.
Figure 5. The real time current graph.

V. CONCLUSION
numerical data display, time chart of any selected parameters(Figure 5).

The process control of the Vivitron had to be done in two
steps. The first one has been used for the generator tests since
early 1991. It represents a fast available control but it is reduced and limited in performance. Nevertheless, good experience is gained for the second step which concerns the full size
control. Our aim is to perform a smooth transfer from thepresent status to the final one whereas the generator tests aregoing on.

The refresh rate, of about 500 ms, depends on the computer load. All the data measured for 100 seconds are stored in afile with date and time on an operator command or automatically before and after a flash for later use and analysis (Figure6). Every hour also, all the parameters are automatically stored
on a backlog file.
The off-line analysis of the machine behavior and thestudy of the sparks can be achieved in two ways. The playbackof on-line recorded data files by the control program performs
continuous real time replay or step by step reading. The second way makes use of specific data analyzing programs or
standard spreadsheet and graphic representation of data like
EXCEL or WINGZ. A MACRO Language or Hyperscript are
useful in this case. Figure 6 represents the currents flow inside
the volume of the tank during a spark.

VI. REFERENCES

a la construction
des machines electrostatiques. Un exemple : le Vivitron", Rev.
Phys. Ap. 23 (1988)1431[2] M. Letoumel and the Vivitron group, 'The Strasbourg project. A
35 MV VIVITRON Tandem." IEEE Catalog n° 87CH2387-9,
Vol.1, p.346[3} J.R.Lutz, J.C.Marsaudon, R.Baumann, G.Frick, R.Knaebel,[1] F.Haas, "Applications de techniques nouvelles

S01SRA05
Status Reports: Accelerators

21

21

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-S01SRA05

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

[4]
[5]

[6]

[7]

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA05

C.Muller, J.A.Persigny, G.Rech, D.Stadelmann, "Controle etCommande du Vivitron ",Rapport d'Activite 1987 Centre de Recherches Nucleaires, F- Strasbourg
L.Rohrer and H.Schnitter, "A light link coupled current monitor",Rev.Phys.Ap. 12 (1977) 1415
J.R.Lutz, J.C.Marsaudon, R.Baumann, G.Biechel, E.Kapps,
R.Knaebel, C.Muller, J.A.Persigny, G.Rech, D.Stadelmann, "MP
tests for the Vivitron process control", 5th International Conference on Electrostatic Accelerators and associated Boosters, 2430 May 1989, F-Strasbourg - D-Heidelberg
J.R.Lutz, J.C.Marsaudon, 'The Vivitron process control", International Conference on Accelerators and Large Experimental
Physics Control Systems, October 30 - November 3, 1989, Vancouver, B.C, Canada
J.R.Lutz, J.C.Marsaudon, E.Kapps, J.A.Persigny, 'The Vivitronprocess control", 2nd European Particle Accelerator Conference(EP.4.C), June 12-16, 1990, Nice, France

S01SRA05
22

Status Reports: Accelerators22

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

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, Japanexplicitly non-equipotential.

settling time witherror 0.001%
0.1 s
analog part capacitywith respect to the body 150 pF
module widthl M
In the process of energy retuning of the storage ring?f char~e particles the matched variation of parameters
is required for many power supply sources of magnetic
elements with its
high accuracy and highly
synchronous. In the power supply systems of first
generation this problem was solved by theappropriate selection (taking into account theindividual ·Characteristics of magnets) of special RCfilters on the DAC output. At present, the most relevant
solution of the problem given is the use of DAC withthe built-in digital interpolators. Two types of
converters have been developed.
The multichannel DAC provides the conversion of a
16 bits code with the error 0.01 % over 16 channels.
The built-in processor makes the simultaneous
variation of the output voltages. The variation law
for each channel is given with the intermediate values
by which the portion-linear interpolation is performed.
Up to 80 intermediate values can be given for eachchannel. In addition, in each linear part theinterpolation time is given within the range from 1 to
63 s with the quantization step of 1 s or in the range
from 0.1 to 6.3 s with the quantization step of 0.1 s.
For the control of the precision channel a 20 bit
DAC was developed with the built-in signal error
amplifier. The conversion error is 0.001 %. The
functions of the digital interpolator are similar tothat described above. ·The converter control is performed through thecontroller with the protocol MIL-STD 1553B. The
controller is designed in the CAMAC standard.

Fig.2. The analog section of multiphase PWM-DAC.

For the problems with higher requirements to thecontrol accuracy (power supply systems of the main
magnets and lenses of storage rings) the precision DAC
was developed that is based on the use of themultiphase pulse-width modulation. This method is the
improved version of the PWM. Its use enables one to
reduce the settling time by a factor of the number ofphases with respect to the conventional case andsimilarly to reduce the switching frequency. In thiscase, the requirements to the fast switching time of
the analog switches determining the PWM signal
became .weaker. This fact enables one to simplify
substantially the technical-design solutions of theswitches and drivers using the standard logic elementsof CMOS kind. The schematic diagram of the analog
part of the apparatus is given in Fig.2. DAC isperformed according to the two-cascade circuit. The
output voltage is the sum (with weights 1/2048) of
voltages of two independent DACs. The first one
converts 11 senior bits and has an 8-phase generationof the output signal (switches Kl - Kl6). The second
DAC for junior bits is a single-phase, 8-bit (K17 - Kl8).
Th~ voltages of both the DACs are summed by theresistors and smoothed by one filter of low
frequency (Al, A2). The bipolar voltage is producedby the output circuit (K19 -K22, A3, A4). in thesource of output voltage the precision reference
diod is employed in the oven wil.1:i the stability oftemperature lK.
The apparatus has the following parameters:

scale length
voltagerange••
quantization step
error (for 3 months)
nonlinearity
temperature factorof output voltage

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA06

20 bits
8 I 192 v
15,625 µV
0.001%
0.0001%0.00002%/K+2µV/K

Apparatus for measurements of direct voltages
As alre~dy me.n_tio~ed, ·the real operation of any
large physical fac1hty is usually accompanied by thegeneration of a large wide range of very different
electromagnetic noises and quite often the amplitude ofthese noises is substantially higher than the signal
to be measured. Therefore, in the analog-to-digitalconverters the most noise-resistantmethodofpreliminary integration of the output signal is used.
Using various modifications of the method: thedual-slop integration, multi-tact integration, themethod of dynamic integration, the series of ADCs isdesigned at INP aimed at the use in the multichannel
noise-resistance measuring systems. Let us consider
briefly the features of construction and parameters ofthe most characteristic versions of this series.

S01SRA06
24

Status Reports: Accelerators383

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

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

integrated by a certain algorithm. When the integrator
output voltage reaches its threshold value (either A2 or
A4 comparator is operated) to the integrator input
the reference voltage is applied whose polarity is
opposite to the input voltage for the fixed period oftime, i.e. the multi-step integration of the reference andinput signals is performed. After input signal
integration the operation algorithm is the same as thatin the previous method. The end of the 3rd step,during which the reduced reference voltage is
integrated, is defined by the comparator A3. In thisscheme the integrator transfer factor is approximately
the same as the number of integration steps when ·measuring the input maximum signal.
Fig.3. Three-step integrating ADC.

The three-step integration with respect to the dualslop one enables the reduction of the error that is dueto the noises of theintegrator amplifier and comparator. An additional
advantage of the method is its high resolution atcomparatively low frequency of the tact generator. The
simplified block diagram of the device is given in Fig3.
The input signal with the help of amplifiers Al and A2
is converted into a current. A3, T2 is the current
mirror. To a<;hieve the fast action the switches Kl - K3
are made with diodes. The main reference signal isgenerated by the current generator on A5, T4. The
reference signal of the third step 64 times lowered ·isformed with A6,
TS. During the first step th~
integration of the input signal is performed. During
the subsequent two steps the integration of the mainand divided reference signals is performed. Thismethod is realized on the ADC 15 - 256. Its main
parameters are given in Tab.1. The device has a builtin memory for 256 words and the control circuit for
the analog multiplexer that transfers the address ofthe measured channel in the subsequent code throughthe socket on the front panel. While performing themultichannel measurements the operation is performedin the following way: preliminary to the service
register of ADC the initial and final addresses ofchannels are written along which the measurements
should be performed. By the start command ADC
performes the given series of ~easurements andwrites the results into the corresponding cell of thebuilt-in storage. The presence of this given mode
enables one to reduce substantially the load of the
CAMAC data bus in the measurement system.
The method of multistep integration enables one
to reach the high resolution and linearity of theconverter at quite high fast action. The block diagramof the method performance is given in Fig.4. Itsessence is the following. Simultaneously with the
input signal integration the reference signal isc+Uref~-Uref~+Uref~K-Uref~

I<

Fig.4. ADC with multicycle integration.

Note that conversion errors related to thepolarization of integrator capacitor dielectric are
reduced similarly. On the base of thi~ method theprecision converter ADC-22 was designed (Table 1).
Let us give some additional characteristics of thedevice that are important for the construction of
measuring systems of high accuracy: integration timeof the input signal - 20 ms; settling time for the input
amplifier (with an error 0.001 % - 8 ms; signal
measurement range 0.1; 1; 10; 100; 1000 V; resolution
capability, respectively, 0.1; l; 10; 100; 1000 µ.V;
relative error of conversion in the range of 10 V for 8 hours - 0.0005% of the scale,anadditionaltemperature error - 0.00005%/K; temperature drift ofvoltage - 0.03 µ.V /K; input current - lower than 10 pA;
the input resistance or! lower ranges - higher than 100
GOhm.
The method of dynamic integrator. This method isthe version of the pulse width modulation PWM
conversion with the pulse feed back. The block
diagram of the dynamic integrator operation is given
in Fig.5. The input signal is applied to the input of
integrator Al through resistor RZ. Depending on the
integrator input voltage polarity, defined by thecomparator A2, an appropriate reference voltage is

S01SRA06
Status Reports: Accelerators

25
384

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

applied to the integrator input through the switches Kl
and K2. (The operation oftheseswitches is
synchronized with the switching frequency by the Dtrigger.) The specific feature of the method is thatsimultaneously with the input and reference signals
through the capacitor C2 to the integrator input theperiodic voltage is applied of the rectangular shapewhose amplitude exceeds the sum of modules of the
input and reference voltages. The main advantage ofthe method is that it enables one to vary the time andbits of conversion. This property is especially useful for
ADC designed for the multichannel measurements:
measurements with not very high accuracy are
performed quickly but those of high accuracy - slower
but with larger number of bits. With larger time of
measurement an additional filtering is envisaged forhigh frequency noises in the measured signals.

Fig.5. ADC with dynamic-integrator.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA06

Table 1
'fype of device

AJX:22 AI:C20

lllC20-256!llClS-256

Conversion time, ms

40

7.5-48a 1.25-160

Scale (binary)

22

lH?O

13-20

15

a.001% o.au

a.au

0.011

256

256

120

80

Error (tor 3 months)
llemcrr (words)
Connon mode rejection, db

140

120

a.1

The metrological characteristics of devices remain
the same within the range 20 K - 50 K.
For the arrangements of the multichannel measuringsystems some analog multiplexers been developed at theInstitute:- AM-16R and AM-128R: with 16 and 64 channels
respectively, the commutation elements - s.ealed contact
reed relay with switching time of 1 ms, maximum
voltage - 200 V, commutation error - 50 µ,V.
- AM-16RM and AM-32R: with 16 and 32 channels
respectively,
thecommutation
elements
thermocompensated reed-relays, commutation error - 1µV. They are designed for the measuring systems inthe microvolt range.
AM-128: 64 channels, produced based on
microcircuits with the complementary MOS-transistors,
switching time - 10 µ,s, input voltage range - 10 V,
commutation error -100 µ,V.
The multiplexing of input signals is usually
performed according to the two wire circuit.
In all the versions the protection is envisaged against
the overvoltages by the input. The address register ofmultiplexers have 8 bits, that enables the union of up
to 256 measuring channels per one converter.

On the base of the method of dynamic integrator
ADC-20 and ADC-20-256 (Table 1) are designed. Eachof these modules has 8 time ranges of measurements(when switching the ranges the scale length changes
respectively) and 2 ranges for the input signals (8 V
and 500 mV) which enables the measurement of voltage
in the microvolt range. ADC-20-256 has a built-in
memory and the control for the multiplexer.

S01SRA06
26

Status Reports: Accelerators

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

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

VAX

ICALEPCS1991, Tsukuba, JapanThe second layer .<:onsists of two main process control
codes, one for UNILAC and all beamlines, the other for
ESR and SIS (SD(l], ZV).
- These application programs organize the access to devices using a number of specialized tasks. Each individualtask uses the same context (i.e. same machine cycle, device
setting etc.) and shares all process data.
- The acceptance of commands is acknowledged immediately, processed directly or passed to a subtask. All windows are organized by the central task and divided into
areas with constant display of information and areas which
are used by subtasks concurrently.
-The actual status of all devices in the selected segment isvisible at a glance: device alarm (status or values changed)
and appropriate refresh cycles guarantee an actual stateof display. Icons reflect the current status of the device(switched on or off, positioned in beam or out, active orinactive etc.). Icons are unique for every device type. Additional windows are used for display of magnet read-outs
showing deviations between actual and reference setting(see fig. 2), beam current profile and spill signals. History
recordings offer an easy help to find a faulty element incase of beam-loss.

VAX
ETl-EFltETTIHING BUS

r-

r---

1

1

I
I
I
I
I
I

I
I
I
I
I
I

L

L

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA07

IHIL WSl

Figure 1: Hardware structure of the control systemmental facilities. For device controlling about 40 VME nodes
with about 150 ECs are installed, driving more than 1200
devices.

T:T

T

'~:~

<

'

'

3

. '•'
:~

T

,,

,5

6

<

Z3

'z

,T

T:T

,

'K:i::

7i~

,,

.

s

~:~
?•~IZ:IV. OPERATORINTERFACE
For the variety of possible interactions with the control
system, handling machines with ·a quite diverse nature, anoperator console and operator interface has been defined
combining every aspect of the operating modes.
The operator interface must offer a model of the process
to be controlled. The process varies with the selected segment of the accelerator environment (SIS, ESR, UNILAC
or transfer beamlines). Three software layers are present
to support the selection mechanism to form the operating
environment.
Layer 1 mainly consists of a code for selection of an accelerator segment. All computers forming a console arededicated to the selected segment. Only codes which areusable in this context are provided, therefore all application, utility and service codes are grouped into categories.
These categories are, e.g. usable at all consoles and accelerators, specific to an accelerator, to a beamline, a beamline segment or an experimental section. All specific codes
serve only devices defined in the selected segment.
Additional codes are server for access to common databases for definition of application codes, accelerator andbeamline segments, device names, properties, network addresses, error codes and help topics. Likewise alarm anderror handling tasks and a logging facility for messages concerning starting and stopping tasks, abnormal conditions,failure of devices, are available in the console environment.

c:::~,=:~:::··
lllmm· ...-1

ogJ~~~~®+**~o~~LJ~LM 0i!liJ!J00~~@00!~~®®0~ I~~ ! ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ! ~ ~ ¥~~ ~ ~ ! 3~ ! ~ ~ ~ ! ~ ! ~ ~ ~ ~Figure 2: Process control for beamline

Additional codes of this layer are utility tasks, e.g. savemagnet settings and restore saved or theoretical sets due
to actual physical parameters, codes for manipulation ofsynchrotron devices according to algorithms, models andparameters, and for management and monitoring of theaccelerator cycles. For supervision of the console environment (which task is running, on which node, network trafficetc.) a number of tasks is at hand.
The third layer consists of a number of specialized tasks
which are managed by the main process control codes. Twogroups are discernible, first codes used for supervisory control and update of device information. These tasks do notneed output devices, servicing purely all other, sharing theS01SRA07
28

Status Reports: Accelerators

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingsame process data structures. The second group consistsof interactive tasks like emittance measurement, isotope
and charge spectra, beam profile display, etc. needing input/ output devices as there are graphics, knobs, beam current control monitors.
All application programs provide a consistent "look andfeel" by a standard color scheme to present device status
and action. There is an unique screen layout management
for programs on graphic screens and terminals. Selection
fields performing similar actions are standardized in colors,
position and names. An uniform access mechanism forall devices and a transparent handling of processes andfunctions guarantees that the operator does not need theknowledge about the actual control sequences.
Beside the operating environment, for troubleshooting,debugging, test and running-in NODAL [2] is widely used bymaintenance people.

Before sending a command to the appropriate controllers
the operating representation is changed to the device representation. This includes the transformation of the device nomenclature to addresses used for identification on
the device level, property /property class to the identifierof the associated software module (see section VII.) anddata. from operating to device format since both may bedifferent, i.e. REAL on operating level, INTEGER. on device
level.
Data in the responses to a command are converted fromdevice to operating representation and then the response
is supplied to the user or buffered for later reading.
Device accessing is handled by one universal softwaremodule, using the same mechanism for all devices. All
EM and device informations needed are extracted from a
Central Data Base (CDB).
ETHERNETV.

DEVICE MODELING

To ease handling of the big number of devices they areclassified by types (DC magnet, pulsed magnet, beam position monitor, rf-structure, ... ). All devices of the same
type are represented identically to the operating level anduse the same software on the device level. Different device parameters like maximum current of power supplies
or number of wires of a position harp are considered bydevice specific constants in databases on device level.
The set of relevant features of one device type is called
Equipment Model (EM) of which actually 42 are supported.
They are modeled and described in a standardized way toallow the same access mechanism for all devices.
Every device is identified by an unique name of 1 to
8 alphanumerics, called nomenclature. Each feature of adevice of every EM is represented by so-called property andproperty class. The properties are described by a name of
1 to 8 alphanumerics, the property class as designation ofdata exchange (R read from device, VI write to device, ll nodata. exchange), and a description of the data associatedwith the property: the number of data to exchange andtheir representation (INTEGER, REAL, BITSET, ... ).
For a. magnet the feature "set value of output current"
would be described as
property:
CURREllTS (s indicates set value)
property class: VI (data send to device)data count:1
data type:
REAL
Properties are EM dependent, but standard ones likema.ins switch (POWER), device status bit pattern (STA.TUS),
reset (RESET), etc. are identical for all devices.
Accessing devices from the operating level means simply calling the associated property /property class with exchange of data for a device represented by a nomenclature. For greater flexibility several ways of calling are supported like execution with or without response (at least
acknowledge) from the device level, synchronous (wait for
response) or asynchronous (response may be read later),automatic command execution periodically, etc.

CP

D
HARD\./ ARE
0SOFT\./ ARE
CALL+DATAMPDATABi . . .

8'bi ... bj

USRs

Ai··· Am EOMs
Bi ... Bn

to devl ces

to devices

Figure 3: Software structure on the device level. ED:ETHER.NET driver, DD: device bus driver, DPM: dual ported
memory, LDB: local data base

VI.

DEVICE CONTROLLER LEVEL

Device controlling in the closer sense of generating thecommand sequences for remote control is realized on the
EC only. This is the only level where real time requirements
have to be fulfilled. To enhance the power and to facilitate
fast reaction with well defined response time the task of theECs is limited to device driving only without interruption
by higher levels. All data needed by the device are stored
on the EC and it runs completely autonomously. Communication with higher levels is by dual ported memory on
the EC and thus may be carried out asynchronously.

S01SRA07
Status Reports: Accelerators

29

29

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

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, JapanOn the EC is coded what to do. Timing requirements(when to do) are managed by the central timing system
which delivers 255 different time signals, so-called events,
to all ECs.
Activities are coded in EM specific EQuipment Modules(EQM) as the smallest independently executable units on
ECs. They may contain complex actions consisting of several device commands. EQMs are connected to events with
an identical connection for all devices of an EM. Execution of EQMs is on reception of the associated event. Thisguarantees system wide synchronous operation of otherwise
independent devices if only connected to the same event.
Besides event driven EQMs other ones may be called bydirect request from higher levels signaled in the ECs dual
ported memory. Execution is not immediate but at command events always delivered in the gaps between accelerating cycles when real time reaction is not required. For
pure DC devices no events are evaluated, all actions are
executed directly when initiated by operating request.
EQMs cannot be interrupted so execution on the EC isstrictly serial. If an EQM could not be started in time sincea previously started one is still running, an error is signaled
allowing EM dependent handling.
Event reception and calling of EQMs is done by the Equipment Control Monitor ECM, installed on every EC. Furthermore it supervises the status of the EC and the connected
devices.
Process control by the timing system enables an easy way
of fast switching between different accelerator cycles. To
do so for every device 16 datasets for different accelerating
cycles are stored on the EC. Selection and thus establishing
the generated cycle is by a dataset number as part of thedelivered event code. So the timing system determines thesequence of accelerating cycles with switching from pulse
to pulse. This allows alternative supply of several experiments, each with different beams, including the injection
to the next accelerator in sequence.
For a detailed description see reference [3].

to EC or receiving data from it, calling an EQM or another
USR and performing consistency checks of exchanged data.
USRs are called by the Master processor OPerating
System (MOPS). Since commands are sent in standardized
form, analysis, dispatching and sending results to the operating level is the same for all devices and can be handled
completely within MOPS. The handling of connected commands, i.e. periodically calling an USR, is implemented in
MOPS, too. MOPS supervises and displays the status of MP
and assigned ECs. Extensive multitasking allows quasiparallel execution of commands on the MP level.

VII.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA07

COMMAND LEVEL

The task of all components between the operating and theEC (implemented in hardware as well as in software) is tolink the operational representation of devices to the device
handling on an EC. ECs are linked to the operating by the
MP to not burden the EC. The additional communication
processor CP only manages the ETHERNET handling and ismainly transparent.
The MP has to evaluate commands from the operatinglevel and to send back the responses.
EM specific command evaluation is coded in modules,
called User Service Routines (USR). Every existing combination of property /property class/EM is represented by
one USR on every MP where the EM is realized. Calling aproperty /property class simply results in execution of theassociated USR. An USR may do any combination of dataprocessing like evaluation of measurements, sending data

VIII.

AUTOCONFIGURATION

Nomenclatures, device numbers and property description
are stored on device level in local data bases, one per MP.
From these databases the CDB, needed for device accessing,is automatically updated:- At startup of an operating VAX it collects the local
databases of all MPs to form the CDB,
- At startup of a MP the local database is sent to all control VAXes for update of the CDB.
A hierarchical still-alive supervision is implemented on
every level of the controls system.

IX.

CONCLUSION

The control system is in use since commissioning of the
new facilities three years ago. During this period no severe problems were encountered. Routine operation of themachines now shows a reliable system. This experience
confirms the structural concepts of the system being flexible enough to implement additional requirements and features.
Major effort now is to upgrade the old facilities and to install additional beam diagnostics both resulting in adding
a lot of devices to the system. On the operating level main
focus is in clarifying and unifying the complex handlingand thus enabling a simpler and more reliable routine operation.
We would like to take the opportunity to thank all ourcolleagues who have contributed to the success of this control system.

X.

REFERENCE[1] V. Schaa, G. Frohlich, M. Balloff, Jun-Ye Wang, "A
New Generation of Operating Programs for the Accelerators", GSI Scientific Report 1987, p. 357[2] M.C. Crowley-Milling and G. Shering, "The NODAL
System for the SPS", CERN 78-07 (3 September1978).
[3] R. Steiner, C. Riedel, W. Rosch, "Real Time Aspectsof Puls to Puls Modulation", this conference.

S01SRA07
30

Status Reports: Accelerators

30

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

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

processes in the 3205 computers monitor a table of parameters
every 5 seconds and transmit raw analogue and status data overthe RS232 links to the VME crate.
A matrix type display consisting of various zones
corresponding to different machine areas, forms the alarmsystem indication. Each box on the matrix is normally
depicted in black and white with a change to flashing red whenan alarm for that zone is detected. By selecting the flashingzone with the mouse, the operator is presented with detailed
information on the alarms in that zone and flashing ceases
although the box remains red until the alarm is cleared.
The software is arranged as a ring of processes
communicating via OS/9 signals as shown in Fig 3. Data
from the 3205s is transmitted over the RS232 links to the
input processes and piped to the alarm monitor process which
performs alarm checking and passses information for display
and logging to the display manager and then onto the disclogger for history storage and to the print logger for hard copy.
All processes have access to the alarm system database. The
alarm monitor process checks supplied analogue and status
data against limits in the database to determine the presence ofan alarm condition. Warning and danger levels may be
specified for the alarm condition. The operator may request thesystem to ignore or notice individual alarmed parameters.
Future extensions to the system include the implementation ofrate of change alarm conditions and the provision of audible
alarms.

5. The monochrome,text-only display did not provide
an eye-catching indication of alarms.
Whilst it would have been possible to improve theexisting system for points 2. and 3., the system could nothave been enhanced to address points 1. and 4. without
seriously effecting control system performance. It wastherefore decided to produce a new alarm system with separate
intelligence. Th~ new system was to have the following
features:-

1. The number of alarmed parameters would be kept
to a relatively small number of importantparameters.
2. Faster sampling of alarmed parameters was
required.
3. Operator interaction with an alarm display wasessential.
4. Audible alarms in the Control room weredesirable.
5. Alarm history for at least the last 24 hours should
be available.
6. A hard copy of alarms was required.
7. A clear,unambiguous display of alarm conditions
was essential.
A VME based system was chosen both for its long term
expandability and to allow us to gain experience with VME
and the chosen operating system,OS/9.
The hardware chosen consisted of a Motorola 68020
processor running at 16MHz with floating point co-processor,
4 Mb Ram, 5 RS232 channels, interface for high resolution
coloured graphics device, keyboard and mouse and 40 Mb harddisc and floppy disc drive. The system is shown in Fig 2.

CCC3205A

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA08

RS232

RS232

CCC3205B

VME
Fig 3. Alarm system software
Colour display,keyboard
and mouse

Fig 2. Alarm system

CCC3205A and B are connected to the VME crate with
RS232 links operating at 9600 baud. A future improvement
will be to remove the main control system CAMAC fast
serial data links and replace with an Ethernet LAN to which
the alarm system would be connected. Simple, low priority

IV. BEAM STEERING SYSTEM
Since the upgrade of the SRS to a high brightness
configuration in 1981[1] there has been a growing requirementfrom the user community for improved beam position
stability.
Beam stability measurements on the SRS andrequirements for a new steering system have been described
elsewhere[2]. Vertical beam position stability is most criticalfor users, with the largest movement being a peak
displacement of 250±100µm in the first 3 hours of a beam fill
followed by a roughly linear decay of approximately

S01SRA08
32

Status Reports: Accelerators

32

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

20µm/hour for the remainder of the fill which typically lasts
24 hours. The existing electron beam monitors have an
accuracy and repeatability of ±50µm and are capable ofproviding only gross orbit correction. A two wire photon
beam monitor has been used at Daresbury to monitor photon
beam position and has shown a useful range of 3mm with aresolution of lOµm at 2lm from the sourcc[2].
Steering elements on the SRS consist of 16 verticalsteering magnets, 16 dipole trims produced by backleg
windings on the main dipole magnets and 16 multipole
magnets each made up of 12 individually powered windings
which provide a combination of horizontal steering, verticalsteering,octupole and quadrupole fields. In total there are 224
individual power supplies which are driven from 12 bit
CAMAC DACs.
Planned improvements to the steering system arc:• Upgrade of the steering magnet supply DACs from12 to 16 bit resolution and accuracy.
• A VME based system to provide local intelligenceand increased bandwidth for steering magnet servo
control.
• Production of tungsten vane monitors for photon
beam position monitoring.
• Provision of improved electron beam monitors
having a resolution of 10µm[3].
The aim is to achieve a photon beam stability of 50µm at
20m from the source.

Winchester disc and lMb floppy drive in the steering systemprocess crate accessible to the Gateway processor.
CCC3230
Ethernet LAN

ervo
ocessor
Steering process system crate
Ethernet LAN

magnetpower
supplies

magnetpower
supplies

pip: Plant interface processor

magnetpower
supplies

magnetpower
supplies

D/A: DACs and ADCs

V. VME-BASED SIBERING SYSTEM
Fig 4. VME based steering system

The new steering system will involve disconnection of
the steering magnet DACs and ADCs presently in CAMAC
serial crates and connection to VME DACs and ADCs housedin VME plant interface crates. Fig 4. shows the arrangementof the new system.
The Steering Process system crate contains three
processors, Gateway, Database server and Servo. The Gateway
processor is the interface to the existing control system andcontains code which makes it appear as another 3205 processor
to the 3230. The 3230 and the Gateway processors are nodes
on a dedicated Ethernet LAN. The Database server processor
contains the steering system database and is connected toanother Ethernet LAN which also has plant interface crates asnodes. The Servo processor contains global and local feedback
algorithms. All three processors have access to the databasewhich is held in shared memory. The plant interface crates
contain a pr:ocessor (PIP) and enough DACs and ADCs toservice one quarter of the storage ring steering magnets. In
addition, these crates will have ADC channels to read insignals from electron and photon beam monitors and various
environmental parameters.
The Gateway processor has access to the hard and floppy
discs while all other VME processors in the system are ROM
based systems. The database will be continously updated by aprocess in the Database server communicating with the plantinterface processors.
The processors are MVME147s with a Motorola 68030
cpu with a clock speed of 2S:MHz, 8 Mb RAM, 4 serial and lparallel ports and floating point processor. There is an 80Mb

The Gateway processor runs under Professional
OS/9(V2.4) while all others run under Industrial(ROM based)
OS/9. Application software is written in C. The
communication protocol is TCP/IP.

VI. PRESENT STATUS AND CONCLUSIONSThe new steering system hardware has been purchased
apart from the DACs and ADCs which are presently being
evaluated. The interface software both in the 3230 and
Gateway processors has been written and tested and the
Database structure has been established. Work is progressing
on the processes in the Database server and Plant interface
processors for database updating. Further work is necessary todesign and write code for the Plant interface processors. It is
intended to install and test a minimal system without the newelectron beam monitors in 1992.
The power and versatility of VME make it a strong
contender to form a major part of a future accelerator control
system at Daresbury.

VII. REFERENCES[l] V.P.Suller et al., "SRS-2: Performance andAchievements" presented to the Particle Accelerator
Conference, Chicago, March 20-23 1989.

S01SRA08
Status Reports: Accelerators

33

33

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-S01SRA08

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-S01SRA08[2] P.D.Quinn and T.Ring, "Developments in orbit control at
the SRS at Daresbury", presented to ABI Conference,
KEK, Tsukuba, Japan, April 22-24 1991.
[3) T.Ring and R.J.Smith, "Orbit measurement techniques at
Daresbury", presented to ABI Conference, KEK, Tsukuba,
Japan, April 22-24 1991.

S01SRA08
34

Status Reports: Accelerators
34

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Accelerator Control Systems in China
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/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-S01SRA09

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 Publishingsection of equipment, such as ring magnet
system, vacuum system, transport line magnet
system, RF system, linac magnet system, BPM
system etc.
_ At the third level are NIM
signalconverter and isolator modules distributed at
equipment site. The NIM modules must match
BEPC hardware and are all developed by IHEP.

Because of the centralized architecture,
all control and monitoring operations must be
initiatedbyVAXll/750.
This
takes
substantial part of CPU time, especiallyduringa ramping process.
Manymemoryresident processes further increase the loadofVAXll/750. The processing speed
andresponse time of the entire system are notsatisfactory.
Furthermore,
systemreliability to some extent depends on thereliability of VAX 11/750, as it is the only
controlling master. Another problem is that
because of its limited processing power, VCC
sometimes becomes the bottle-neck of message
communication.
In order to overcome these problems,
plan has been made to convert the centralized
system to a distributed system. DECNET will
be used to link the VAXll/750, A micro VAXII
and a VAX Work-Station as three nodes. Fig.2
shows the upgraded system configuration.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA09

2. Software System
BEPC control software is a databasedriven system taking full advantage of multitasking ability of VAX/VMS operating system.
The database and its manager are
thecenterof the system. All themachinehardware and program operation parameters are
stored in the database which resides in a VAX
globalsection shared byallsoftwareprocesses.
Softwareprocesses
areexecutable
programs under VMS operating system. They canbe invoked by terminal command or by anotherprocess.
Two processes have special role in thesystem. A memory resident vcc I/O programCXCAMAC continuously performs I/O operation,
sends out messages to CAMAC systems, collects
status information from CAMAC systems andrefreshes database records. The other special
processis
AVTX, which isacommandreceiver/interpreterandscheduler.
It
receives
touchpanel andknob
commands,
decides which processes to call to performthedemanded
operation,andactivateappropriate processes.
Database
generation andmaintenanceprocesses are also included in the system for
easeof
database
ipitialization
andmodification.
Up to now, a total of 17 software
processes are implemented for BEPC system,
including ring magnet control and status
display, ramping process control, BPM datatakingandprocessing,closedorbit
correction, ring lattice calculation, ringand transport line modeling etc.

WORK
STATION

CQtlSOLE
OR6!TlAlllCEIJWU

PSIW'P
PSCTlU.
QXJ922SSCHJ I ._,-,.,"'°"--r~lDBS!ll

YAX-6330

COMPUTER CENTER

F'lp;1irt"2

Tht- upgrndt" of BBP(J eontrol 111yl'ltr111

The Micro VAXII will be dedicated to thetask of magnet power supply control. The WS
will be used to replace the present console
terminals. The rich window software functionsof WS will be fully utilized to update the
man-machine interface.
The WS will also
share some of the calculation tasks, such as
ring modeling, orbit calculation etc., with
the VAXll/750.
A KSC 3922/2922 Q-BUS CAMAC adapter will
be used to interface the Micro VAXII to thesystem crate for power supply control. The
communication bottle-neck problem will bebasically resolved, partly because the amountofmessagesthrough
VCC
arereducedsubstantially,
partlybecausethe
QIO
operation of 3922 is faster.
All hardware below the system crates
ensurewill remain unchanged. This will
hardware compatibility.
The software compatibility among VAX
family systems is an advantage for software
upgrading. Except for the CAMAC I/O driverprogram, most of the software developed for
VAXll/750 can be moved to Micro VAXII systemand the WS with only minor modification.
In order to coordinate the processes on

3. Present Status
The system was completed in the middleof1988, a few months ahead offirstcolliding beam experiment. After that it has
been operated for beam colliding experimentand machine study for more than two years.
System reliability is proved satisfactory.
Some modifications has been made to thesystem to improve its performance. Dual speed
Dual accuracy ramping function are developed
for main magnets and correctors to increase
the speed of ramping process. Analog control
part of. database is reorganized to enable
more flexible and faster I/O operation. RF
control function is added and a new BPM dataacquisition program is developed to reduce
BPM scan time and generate graphic display ofbeam position.
4. Upgrading Plan

S01SRA09
36

Status Reports: Accelerators36

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdifferent nodes, new communication programs
will be developed to enable inter-node andinter-process message exchange.

controller which is the main controller ofthecrate an auxiliary
controller
forsubstation computer and other CAMAC modules.
Control command may either be issued by thecentralcomputer or by
thesubstation
microcomputers. Communication between
thecentral computer and substation computers is
also performed via the serial high way. A
substation can be further expanded through asecondary serial CAMAC high way loop if morethan one crates are required. Several typesof control substations have been constructedduring system development period. In order toreduce the number of different subsystems,
only two of them, the PC based and LSI-11
based CAMAC control substations are adopted
for present system.
Accelerator equipments are divided into
severalsubsystems. They arecontrolledeither by normal serial CAMAC crates or bycontrol substations.
The injection and extraction transportline and SSC magnet power supplies are allcontrolled by serial CAMAC crates which are
directly connected to the main high way loop
and controlled by the central computer.
RF system is controlled by a PC based
CAMAC control substation composed of 8 CAMAC
crates.
Vacuum system is monitored by another PC
based CAMAC substation.
Beam diagnose system is controlled by a
LSI-11
based
CAMAC
control
substation
composed of 4 CAMAC crates.
All equipments are connected to CAMAC
modules via signal conditioner electronics
which was developed by HIRFL.

III. HIRFL CONTROL SYSTEMHIRFL is a variable energy heavy ion
accelerator. It consists of a 1.7 meterradius sector focusing cyclotron modified
from a former 1.5 meter cyclotron as injector
and a new built separate sector cyclotron.
The
project was started in
1976,
and
completed in 1988.
Control system of HIRFL is a distributed
control system formed by a Vax cluster as thecentral computer and several microcomputer
controlled CAMAC control substations(CSS).
1. System Configuration
Fig. 3 is a block diagram of the HIRFL
control system. Two VAX8350 computers arelinked together through the CI bus and DECNET
to form a cluster. One of them, which serves
as the central computer of SSC
controlsystem, interfaces to serial CAMAC systemthrough a UNIBUS adapter and a serial branch
driver. The other serves as a data processor,
software development system and a backup
system. The cluster is equipped with 2X12MB
of memory, 4X520MB hard disks and otherstandard peripherals.
A DZll asynchronous interface, a DR-11
parallel · interface and a parallel
CAMAC
branch driver are also installed on thedevices,
UNIBUSfor connecting
consoleincluding 6 touch panel monitors and 6 color
monitors.
Serial CAMAC high way communication linkis used for the whole control system.
A. control substation is an intelligent
CAMAC
crate containing a
serialcrate

2. Software system
The software of HIRFL control system has
two levels. The main control programs for thecentral computer are all VMS tasks
and

TAPES ' HARD DIS¥.S

DlSP. Ch"I'?l.
CJ.WC S'iSTIM

6 X TtU:H P>.XEL

6 x arw 1-0{ITO?.

6>l:OLOR DISPLAY ~!TOR

FIG. 3

su:x:K DIUi?>.H OF HIRf'L CCN'm.::t. SYS'l"rn

S01SRA09
Status Reports: Accelerators

37
37

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-S01SRA09

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 Publishing

written in FORTRAN. They accept main consolecommand, generate various displays and send
control command and data to CAMAC crates orto the control substations.
Softwarefor thesubstations
were
written with FORTRAN and BASIC languages.
Menu
type
man-machineinterfaces
areimplemented for convenience of operation. The
substation control programs perform all thebasic control functions: equipment parameter
adjus~ment, on/off control, status monitoring
and generation of local status displays.

expansion board and a several other interface
boards. Because PCs are more convenient inprogramming and display we have also usedsome PCs as LCMs. The LCMs are located near
the equipments. One LCM controls only one or
one type of equipments.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA09

ccw;oLE PC

CCNSOLE PC

PDP!l/45

3. Present StatusAll
thecontrol
substations
werecompleted in 1988 and was in operation before
the beginning of SSC commissioning. They havesatisfiedtherequirementof
HIRFL
commissioning and operation.
A system composed of two 386 PCs and
CAMAC systems were built for the SFC control
recently.
The VAX cluster was installed in Jan.
1988. A VAX control program for SSC magnet
power supply system is completed and inoperation.
Development ofVAX
centralcontrol programs for other subsystem is underway.
The next goal of HIRFL control group is
to realize central control of all SSC
andthe SFC equipments.

LCM

LCM

TO STORAGE Rll'Kj EQJIPMENI'

FIG. 4

BU:X::K DIAGRAM OF' HESYRL RING cetrrnOL SYSTEM

Because of the local intelligence of theLCMs, direct control and monitoring of the
hardware equipments from the main computer
are unnecessary. Most of operations
areperformed by the LCMs, system reliability andspeed is improved. This is more obvious for
ramping operation. With preloaded rampingtable and hardware synchronization, ramping
time can be less than 1 minute.
The CMM is a microcomputer speciallydesigned for communication. It is a MULTIBUS
system consists of a master CPU board, a DMA
communication board and up to 10 intelligent
serial communication board. CMM exchanges
datawith PDP through DMA channel
andcommunicates with LCMs through serial links.
Maximum number of channels is 40.
Low cost and convenient optical isolated
asynchronous serial lines are used for data
communication between the CMM and LCMs.

IV. HESYRL CONTROL SYSTEMHESYRLis adedicatedsynchrotron
radiation source designed for UV and X-ray
experiments. The project started in 1984 andcompleted in 1989.
The main facilities of HESYRL are a 200
MeV electron linear accelerator, abeamtransport line, and an 800 MeV electron
storage ring. The control system are mainly
divided into three relatively independentparts: a linac control system, a ring control
system and a timing system.
1. System configuration
The HESYRL ring control system is a
distributed computer control system composedof a PDPll/45 computer, two 286 PCs, acommunication microcomputer and up to 40
local control microcomputers(LCM). Fig. 4 isa block diagram of the ring control system.
Originally we plan to use a VAXll/780 as
the main control computer. Both budget anddelivery time problem led us to the choice ofa
PDPll/45
computerasatemporaryalternative. Now because of the small memory
size and poor display ability, its function
is reduced to part of communication. Main
control functions and console operation are
all performed by the two PCs which areconnected to serial ports of the PDP.
Ring equipments are controlled by local
control microcomputers. Most of them are
MULTIBUS system composed of a crate, a CPU
board,
aserialcommunication/memory

LCM

2. Software
The software for the control system
consists of three levels: ROM monitor for the
LCMs, communication program and ring control
program.
ROM monitor of the LCM micros manages
the LCM resources, handles communication andperforms
various control andmonitoring
functions.
The communication program includes ROM ,control monitor for the CMM, DRll-B driverand data buffer manager for the PDP.
The main function of CMM monitor is tohandle the data exchange between the LCMs andthe PDP. All data are exchanged in records.
Error
detection andretransmission
are

S01SRA09
38

Status Reports: Accelerators

38

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

implemented.
The PDP DRll-B driver is installed as adevice driver under the RSXll-M operating
system and can be invoked by QIO. LCM status
informations are stored in a shared dataregion on the PDP which is accessible by the
console PC programs.
Ring control program includes transportline control, ring device status display,ring lattice setting and changing,
beam
energy ramping process control, close orbit
correction and equipment testing programs.
Presently only transport line control,
lattice setting, ramping control program andorbit correction programs are executed on the
console PCs. Ring modeling, ramping table
generation
and
other
calculations
areperformed off-line.

bottle-neck and increase data speed
whole system.

of

the

vw:; CN'ffiL
H:tcRO VAXIIPC

VAX63l0

TlWiSPORT

o:mroLPC

3. Present status
The system was completed in March 1989
and has been operated since then. During thecommissioning period the control system has
performed satisfactorily.
Ring magnet control assured stable ring
operation.
Ring control programs serve well for
injection and ramping process control. But
off-line calculation of physics parameters isinconvenient for machine study.
Beam energy ramping control is very
successful. With the table ramping techniqueenergy ramping or transfer todifferent
lattice is very easy and smooth. Beam loss
rate from 200 MeV to 800 MeV with 200 mA
current is less than 7%. This is a good
indication of ramping accuracy.
System communication has been reliable.
But the response is slow. This is due to the
speed of serial lines between console PCs andthe PDP. LCMs are reliable and easy tomaintain.
4. Upgrading plan
Several problems exist in the present
HESYRL control system: 1) Transport line
controland vacuum monitoringarenowcontrolled by two standalone PC
controlsystem. They are not linked to the ring
control system. This is not convenient forsystem management and data logging. 2) PDP
seems
unnecessary inthecommunication
system, also it becomes a weak point. 3) Lackofon-line calculation ability
isnotdesirable.
In order to solve the above problems,
system improvements are planned.
DECNET will be implemented to link a
Micro VAXII, the console PCs, transport line
control PC, vacuum monitoring PC andarecently installed VAX6310 system together.
This will give us a fully linked system withmuch expanded computing power.
The PDP computer will be replaced by two
BIT3 bus connector cards which connect PC bus
to
MULTIBUS
ofthecommunication
microcomputer.
This will
eliminate
theFIG. 5

Ul?GRADE OF HESYRL o::ttTI<OL SYS'l'EM

Console display and computation power
will be upgraded by replacing the console PCs
with more powerful 386 or 486 stations.
Control
programs
andsystemcommunication programs.will be rewritten to
include on-line calculation function and node
to node communication.
V. CONCLUSION
Started almost in same period,
thecontrol systems of the three accelerators are
now all in operation. In parallel with thedevelopment of the systems, ourchinesecolleagues
have gained
experiencesandestablishedtheirqualifiedcooperative
teams. This is a promising start.
Comparedwithworld
advancedlaboratories our systems are not advanced nomatter in architecture, hardware or software.
Some system upgrading and optimizing work
remains to be carried out.
VI. ACKNOWLEDGMENT
During design and construction periods
we have received great help from SLAC, NSLS,
KEK, CERN and many other laboratories. wewould like to take this opportunity
toexpress our thanks.
I would like to thank Prof.S.Y. Liu,
D.K. Liu of IHEP and Prof. T.S. Jiao of IMPforhelpful
discussions
andlettercommunications in preparing this report.
VII. REFERENCES
1. BEPC control group, The status and Upgradeof BEPC Control System, BEPC workshop, June
1991, Beijing
2. T.S.Jiao, HIRFL Control System, Proc. of
The Fourth Symposium of PASC

S01SRA09
Status Reports: Accelerators

39
39

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-S01SRA09

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: Accelerators40

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The DMA board controls DMA data transfer
between the dual port memory and a DRll-B DMA
interface of the PDP.
The main control console is made up of 9
modifiedindustrial cabinets
which
are
equipped with terminals, video monitors andvarious control panels. It is functionallypartitioned into several subpanels: transport
line
magnetcontrol,
injectionsystemcontrol, timing control, ring control, beamdiagnosis, interlock and personal safety etc.
Most of the operations are performed at theconsole PCs.

following seven subsystems:
HESYRL ring has 1 dipole group,8
quadrupole groups and two sextupole groups.
The main magnet power supply control system
consists of 12 LCMs, 11 of them are ramping
magnet LCMs each controls one magnet power
supply. A LSI-11 controlled CAMAC system anda DVM is used to read back DCCT values of all
the magnet currents. The dipole LCM also
contains a ramping timer board which is asynchronizer for all other LCMs. Fig. 2 shows
the configuration of the main magnet control
system.

B. System Software
1l:l MAIN CCM'ROL

There
are three levels ofcontrol
programs.
ROM monitors of the LCMs are at thelowest level. The basic design idea of LCM
monitor is brought from NSLS. It consists of
two parts: a basic control monitor and an
application part. The former initializes the
micro, handles communication messages andschedules operation of different
control
processes.
The latter is essentiallyacollection of interfacing routines designed
for the particular hardware configuration.
The Basic control monitor is identical for
all the LCMs.
At the second level are communication
programs including ROM control monitors forthe communication microcomputer,and a DRll-B
I/O driver for the PDP.
The main function of SBC80/24 monitor isto handle the data exchange between the dual
port memory and the PDP. .All dataaretransferred in DMA mode.
There is a ROM monitor program on eachCOMM
board of the CMM,
which
manages
communication with LCMs.
The I/O program for DRll-B interface isinstalled as a RSXll-M device driver which
can be called by QIO.
Ring and transportline control programs
are at the third level. Three programs areused for normal operation. A program called
RINGTEST performs ring device status display,ring magnet current and RF voltage setting,console command interpretation, ring latticeadjustment, file saving and restoration, beamenergy ramping process control etc. It mainly
deals with hardware signals. The second is
BLOS, which performs transport line and linac
magnet setting and adjustment. The third
program,
CORRECT,
does
closedorbit
correction.
Ring lattice modeling, ramping table
generation, closed orbit analysis and othercalculationareperformedbyoff-line
programs.

SYN:HHCtllZER
roARD

C<Ml'.JtUCATIW

M1Cl10'.XX1PIJ'l'I

NWJX; CWTROL 1l:l MAG:lE:l' !U'IER SUPPLIF.S

FIG. 2

BLO:K DIAGllJ\M OF IWlPING CONTROL SYSTIM

The injection energy of HESYRL ring is
200 MeV, which is only 1/4 of its operationenergyof 800 MeV. Ramping processiscritical for high beam current.
Duringan energy ramping
orring
configuration change process the currents ofthe magnet power supplies must follow certain
calculated curve synchronously in order tokeep the beam stable.
In a centralized
system the central computer has to modify
magnet current one by one in many small
steps. It will takes a lot of CPU time. The
local· intelligence of LCM allow us to takedifferent
approach. It is calledtable
ramping. Ramping data are pre-stored to the
LCMs. Synchronization of different LCMs is
kept by hardware signals.
A ramping magnet LCM is composed of aCPU, a serial line interface, a ramping
controller board and a 16 bit D/A converter
board.
A ramping curve is divided into manysmall straight segments. Each segment isdefined by ~ts end current and slope values.
As many as 1000 segments can be defined for
one curve. A ramping segment is generated bycounting up or down of a 16 bit counter on
the ramping controller. The clock input toc. Equipment Interfacing
The LCMs are mainly partitioned into theS01SRA10
Status Reports: Accelerators

41

41

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-S01SRA10

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 Publishing

the counter is divided from a common clock
outputsignal of the synchronizer.
The
ramping LCMs are programmed such that when asegment end is reached the new segment andslope values are .loaded. The synchronizer
also provides a start signal for all the
ramping LCMs. Tracking of different magnets
is automatically assured.
In order to start a ramping process, themain computer just needs to load the segment
table, send necessary command to the LCMs andthen issue a start command to the dipole LCM
to start the synchronizer.
A
fitting program is developedtocalculate optimized ramping table for any
required ramping process. The theoreticalfitting error is 1 bit.
12 auxiliary windings of dipole magnets
and 64 auxiliary windings of quadrupoles are
configured as 12 horizontal and 32 verticalclosed orbit correctors. Two LCMs are used tocontrol all these corrector power supplies.
Control of transportline focusing andcorrection magnets are performed by systemcomposed of a SBC80/24 LCM in the power
supply room and a PC on the operator console.
The PC acts as the control master and the
LCM accepts PC command and performs theactual control.
The beam position monitor signals areneeded on line for closed orbit correction. A
PC data acquisition system is used to readand display the BPM data.
Ion pump currents and vacuum
gaugepressure readings are monitored by a PC dataacquisition system.
Injectionsystem includes apulsedseptum magnet and three fast kickers. The
triggering signals are provided by timing
system. Pulse amplitude control are performed
by a SBC80/20-4 LCM with a terminal on theoperator console for command input.
HESYRL ring has only one RF cavity, sophase control is not necessary. A tuning loop
is built for cavity tuning control. Detuning
angle is controlled by a manual adjusted
phase shifter. Cavity voltage is regulated bya feedback loop. A ramping LCM is used tocontrol the cavity voltage. During ramping
process the cavity voltage is controlled inthesame way as the ring magnets
andtherefore can follow any desired curve.

Linac focusing and correction magnets fall
into two groups: 30 focusing and steering
magnets for linac proper and 32 magnets forthe extension section including a beam energy
analyzer.
They
are controlledbytwo
SBC80/20-4 LCMs and a PC. The PC serves as
the master and operator console. The LCMs
perform the local control and monitoring
functions. The links between the PC and thetwo LCMs are fiber optical serial lines.
A SIMENS S5-101 programmable controller
is used for linac interlock and protection.

doi:10.18429/JACoW-ICALEPCS1991-S01SRA10

IV. TIMING SYSTEM
The
timingsystemprovidessynchronization triggering signals for the
linac, injection system and beam diagnose
system. Since timing is only adjusted during
injection and linac set up time and most of
its parameters are fixed, It is built as anindependent system. Two LCMs are implemented:
a main timing micro(MTM) installed in themaincontrol room and alinac
timingmicro(LTM) in the linac control room.
The MTM generates master start and clock
signals which are the reference of the wholesystem. The master signals are transmitted
tothe linac timing micro.
MTM
also
provides trigger signals for the septum,
kickers and for beam diagnose system.
The
LTM
generates trigger signals
fortheelectron gun, the microwave source,
theklystron modulators and the switching magnet
pulse generator.
Structurally the two micros are almost
identical. They' consists of a CPU board and atiming generation board(TIG).
Present
timing system can onlybeoperated in full bunch injection mode.
V. PRESENT STATUS
During the commissioning period
thecontrol system has performed satisfactorily.
Timing system, linac and transport line
magnet control subsystems greatly eased linac
and transportline tuning. Resolution
anddelay adjust range of timing system aresuitable for optimization of linac operation.
Injection
control andring
timingsystems
assured conveniently settingofcorrect injection condition. The ring control
program has a linear approximation trimming
function to adjust the ring energy slightly
up or down. This is very useful for matching
ring and injection beam energy to improve
injection rate.
The measured accuracy of ring magnet
current setting is better than 7Xlo- 5
Thisassured stable and repeatable ring lattice
setting. The measured tune variation is lessthan . 001.
The
simplepractical
approachOf
RINGTEST control program served wellin

III. LINAC CONTROL SYSTEM
The linac control system is divided into
8 separate subsystems each has its
own
control panels and controls one part of thelinac
equipment. The
modulator
control
panels, klystron focusing control panels,
electrongun control
panels,microwave
control panels,
vacuum control panel are
all manual control panels.
The 200 MeV linac has an extension
section for future beam energy expansion.

S01SRA10
42

Status Reports: Accelerators42

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

ICALEPCS1991, Tsukuba, Japanmachine commissioning and normal operation.
Beam energy ramping control is very
successful. With the table ramping techniqueenergy ramping or transfer todifferent
lattice is very easy and smooth. Current
tracking was measured better than lo-4. Beamloss rate from 200 MeV to 800 MeV with 200 mA
current is less than 7%, which is of sameorder as normal lifetime loss. This is also agood indication of ramping accuracy.
System communication has been reliable,
but the system response is slow. This is dueto the speed of serial lines between console
PCs and the PDP.

l)Introducing
DECNET
tolink
theMicroVAXII, console PCs, transportline PC,
vacuum monitoring PC and a recently installed
VAX6310 system together. This will give us afullylinked system andmuchexpandedcomputing power.
2)Replacing the PDP by two BIT3 bus
connector cards which connect PC bus to
MULTIBUS
ofcommunication
systemanddirectly map the dual port memory to PC
memory. This will eliminate the bottleneck
and increase data speed of the whole system
3)
Improvingconsoledisplay
andcomputation ability by replacing the console
PC with more powerful 386 or 486 stations.
4) CATV is very convenient to display
machine status information to the users andother laboratory staffs. Installation of a 10channel CATV system is under way.
5) control programs will be rewritten to
include on-line calculation function and node
to node communication.

The operation experience showed us that
there exist
several problems in thepresent HESYRL control system: 1) It is not afullylinked system. A
few
standalone
subsystems are not connected. This is notconvenientforsystemmanagement
andsystematic data logging. 2)PDP is an oldsystem and difficult to maintain. It becomesa weak point. 3) Lack of on-line calculation
ability is not desirable.
Having analyzed these problems,andconsidering our available resources, we plan
to make the following improvements:

VII. ACKNOWLEDGMENTS
J.Yang of SSRL, J. Sheehan and J. Smithof NSLS contributed their suggestions during
their visit to our laboratory.
The control group have been working
cooperatively over the years to build andmaintain the system.
VIII REFERENCES

M!COO VAX!l

VN:.. OmlLPC

VAX6310

1. s. Magyary et al, Operating Experience
with a New Accelerator Control system Basedupon Microprocessors, Proc. of 1981 Particle
Accelerator Conference, Washington D.c.
2. K. Batchlor et al, Distributed Control
System for the National Synchrotron Light
Source, Proc. of 1979 Particle Accelerator
Conference, San Francisco
3. Yao Chihyuan, Beam Control and Diagnostics
of HESYRL Ring, Proc. of the 4th Japan-China
symposium on accelerator and its application,
1990, Beijing

TO LCCAL CCNTROL HICOO

FIG. 3UPGRADE OF f!ESYRL currroL SYSTEM

S01SRA10
Status Reports: Accelerators

43

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

VI. PLANNED SYSTEM UPGRADE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA10

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

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

ICALEPCS1991, Tsukuba, Japan(2) All local stations microcomputer links to
Host computer by CAMAC serial loop line. Twocommunication machanism are available:(1) A memory "mailbox" CAMAC module accessible from both host and remote processors. (2)A CAMAC Dataway Communications module or"DMAport" between
theremoteprocessor
memory and the Dataway.

board, DAC adjusting board with accuracy of
16bit-18bit and ADC data acquisition board withaccuracy of 12-16bit, had been designed and made.
They are. used for on I off power supply, statusmonitor, current adjusting and data acquisition.
A step motor control is used for units requiring accurate position setting, such as electrostatic
deflectors,
magnetic channels. The controller ofstep motor is designed to provide with local control function. They are slow acceleration when movable units is started and slow deceleration whenmovable units is derived to the front of end. So
movable
units
not
only
can
keep
runningsmoothly, but also can obtain higher operating
speed.
In order to save funds, a number of digital
and analogue multiplexer is used for devices ofsome slower action. Otherwise, the pressure operated control is mainly used for the units of two
movable position such as Faraday cup, vaccum value, secondary emisson multi-wire profile monitoretc.
3. Console

HIRFL is controled by means of 2 kinds ofprocessors: mini-computers as host computer andmicrocomputer as local stations. They arc linked
with CAMAC serial loop line.
The host computer is two VAX-8350 that areconnectedbycluster configuration. They
share
4x520MB disks, 2x300MB movable disks and tapes.
Each computer equipped with 12MB memory. Oneof them is used as a host computer for
HIRFL control system. The other is used as a re.
served computer when the former one is in fault.
In addition, it is also used calculation and dataprocessing for the experiments carried out in theexperimental areas.
Microcomputers for the local stations are
LSI-11/23
and IBM-PC.
They are used tocontrol subsystem for Vacuum, R.F, Beam diagnosis
system and so on. These microcomputers are acompleted system with memory, disk, terminal.
V AX-8350 control the SSC Cyclotron throughthe CAMAC bit serial loop. This loop was drived
by serial highway driver. Serial rate is 2.5MB.
There are about 20 CAMAC crates, corresponding
CAMAC module are used for the interface of devices.
2.2 Device control
In order to bring into being link andmatching between CAM AC modules and devices,
SV digitalized I I 0-signals, 24V switch signals, andSV analog voltage signals was planned. A varietyof condition circuits, such as switich board, status

Our console is designed
after a careful analysisof which have been done in GANAL<4> andRIKEN(S).
10The
console,mechanically
built
with
benches is devided in 3 operating console units L,
C, R. The central console unit C is devoted toequipments not linked to the computer, such asworksite monitor, RF waveform and beam signal
obeservation. The console units L and R are identi cal.
Controlling the HIRFL process withtheconsole system can be exercised at the elementarylevel or a higher level. At the elementary level
the control system behaves as a large multiplexer.
Equipments designed by their device name arehandled one by one.
The operator uses the touch panel and theturn pages of the device name to choose one corresponding equipment he wants to control. Then,
operator moves a cursor to a selected device name

S01SRA11
Status Reports: Accelerators

45

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

2.1 Computer

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA11

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, Japanon TV screen with a defined touch key and reads
the various informations such as the controlled value the actual value of the parameter and a status
word on the TV screen area designed.
Among the numerous signals collected along
the accelerator, most of them concerning parameters
values or status are digitalized and enter thedata flow transmitted by the CAMAC system forprocessing. A little analog form is remain which
are to be used in their anolog form. This is thecase of some beam diagnosis signals and R.F signals with time. These waveform siganl observationis necessary.
These signals can be displayed on autoranging
picoammeters or on oscilloscopes.

With time
will improve.

4. The present situation

The
HIRFL
operatingsoftwarecalledHIRFLCSF
which
is
writtenin
Fortran 77.
Presently, center console programs are developping
for the man-machine interface with Touch Panel.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA11

goes

on,

HIRFL

operatinglevel

Refernce(1]. Zhang Enhou, Wei Baowen etc., Survey of
Heavey Ion
Research
FacilityinLanzhou(HIRFL), proceedings of Heavy Ion Research Facility in Lanzhou, Vol. 8, 1 (1989)[2]. Jiao Tianshu, The Control and Beam
Diagnostic System, proceedings of Heavy Ion Research Facility in Lanzhou, Vol 8, 87 (1989)[3]. J. W. Tippie, etc., Discussion of Tools
and Techniques for Distributed Processor BasedControl
SystemsUsing
CAM AC,IEEE
Transactions for 1985
[4]. I. M. Prome, "The GANIL Control
System", IEEE Transactions on Nuclear Science,Vol. NS-28, No.3, June 1981[5]. T. Wada, H. Tarebe etc., Control system
of RIKEN Ring Cyclotron, RIKEN Accelerator
Progress Report, Vol.201, 170(1986)

S01SRA11
46

Status Reports: Accelerators

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~purpOQa

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S01SRA12SYSTEMCONTROL
JrorJ:staton

ICALEPCS1991, Tsukuba, Japan(K4_;_K10)

1Tor/i:statltm

Xwindow

XrnoveCartrid9e.E:r:alryte

Central PC.LAN ./£££ 802.S

FIG.t

In the project of the control system for the K4-K10 it isalso planned to use such a kind of real time system for the
lower control level. But taking into account relatively small
dimensions of the accelerator rings of the K4-K10 (the perimeter of the KIO is about 200 m) and the transfer rate of 1
MByte/sec. at distances up to 300 m for the MIL-1553, theconnection of the main node computers of the control systemat the front-end level may be done without a LAN 802.5,
directly on the system bus of the Multibus II with a transfer
rate of 40 MByte/sec and full message passing mode. In sucha way the possibilities of real time control are widened allowing for this purpose the use of interprocessor transfer in the
Front-End Computing of the upper level.
The control system architecture of the K4-K10 allows theuse of the standard operating system UNIX and SORIX for thenode computers. The main programming languages are C at
the system level and NODAL [8] at the application level. The
software at the lower control level [2] has to be as short as
possible (up to 10 KByte because at this level one may use 8
bit microprocessors) and has to provide a good reactivity: up
to 250 interrupts per second with quite long messages on the
MIL-1553 and up to 20 Kbyte/sec. All the software on thelower level is part of the system data base. It will be pickedout together with all tables of parameter sets necessary for thereal time operation and will be stored into the equipment controllers at the lower level.

III.

CONCLUSION

The control system architecture for the accelerator complex
K4-K10 represents an example of an open architecture system
based on the use of control and communication software andhardware corresponding to international standards. Though thesystem designers have the possibility to introduce their own
original technical solutions, the main effort will be directed tothe software and hardware design concerning the interfacing partof the system, i.e. the hardware and software ensuring the application of system resources as some kind of a set of control
facilities.

REFERENCES[l] R. Steiner et al.: The GSI Control System. Europhysics
Conference on Control Systems for Experimental Physics.
Villars-sur-Ollon, Switzerland, page 21-25, CERN 90-08,
12. 10. 1990.
[2] R. Rausch: Control System Architecture of the European
Accelerators LEP and SPS. CERN SL/90-109 (CO).

S01SRA1248

Status Reports: Accelerators48

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing[3] S .Kurokawa et al.: The Status and Prospects of the
TRISTAN Controls System. Europhysics Conference onControl Systems, page 15-21, CERN 90-08, 12. 10.
1990.
[4] SIEMENS SIMICRO, Industrial Microcomputers
SIMICRO SX. Catalog MC, 4. 1. 1991.
[5] A. N. Aleshov et al.: Accelerator Control System at the
INP. Europhysics Conference on Control Systems forExperimental Physics, Villars-sur-Ollon, Switzerland,

page 25-30, CERN 90-08, 12. 10. 90.
[6] D. Francart et al.: MIL-1553-B Multidrop Bus forControlling LEP and SPS Equipment. LEP Control Note
56 rev.
[7] V. Kotov, L. Dubovic, R. pose: Automation and Control
System for a ct Factory. Proceedings Workshop ct
Factory in Dubna 1991.
[8] M. C. Crowley-Milling and G. C. Shering: The NODAL
System for the SPS. CERN 78-07 SPS Div., 3. 9. 1978.

S01SRA12
Status Reports: Accelerators

49

49

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-S01SRA12

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ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU01

capacity, the upgrades should provide the needed capa.city tosupport twice the number of existing consoles and twice thenumber of data and control points in the system and increase
the overall data throughput by a factor of three to 450 untimed
read requests per second. Response time should be impro~ed
to provide a 5 Hz update rate at the operator consoles dun?gnormal operation and human speed, 1-2 Hz, beam profile
information.

B. Availability and Maintainability Goals

Figure 2. The PSR Control System.

The most significant difficulty with the PSR Control
System is that the current update rate is one-fifth of what is
considered optimal. This rate is directly limited by the systemarchitecture which migrates all data continuously through thecontrol system CAMAC loops to ·maintain the system's realtime database. Additionally, the complicated and timeconsuming procedures required to modify the PSR database and
the PDP-11 software discourage changes during run cycles,
restricting the flexibility to correct problems and add devices.
Finally, the PDP-11 database size limits are being approachedon all five computers now that the system is twice its original
design size.

C. UMPF and PSR Operator Interface Systems
In the LAMPP control system, data display and entry ishandled using color CRTs, graphics scopes, button panels,
terminals, trackballs and knob panels [I]. Experience over thelast two years has demonstrated that the demands for cpu powerand data generated by consoles can easily outstrip any central
control computer's ability to service the demand. This indicatesthat additional computing power is required to support future
console demands.In the PSR control system, data display andentry is accomplished using color graphics screens, touch
panels, and knob panels. The color graphics systems are
creating an increasing maintenance burden due to difficulties in
obtaining parts and adequate support from the manufacturer.
The PSR touch panels are an inefficient and often ineffective
method for interfacing to the control system.The graphics
software of both systems is created at a fairly primitive level.
This prohibits quick prototyping of application codes andincreases the overall time required to create an application
program.

III. GOALS AND CONSIDERATIONS
A. Performance Goals
Goals have been established for the performance elements
capacity and operator console response time. In terms of

Availability is a measure of the combination of failure rate
and repair rate. Maintainability is the level of resources
required to achieve a given availability. The availability goal
for the upgrades is specified as 99.7%. This represents an
improvement over the current systems which oper~te ~t
approximately 99.4%. For these purposes the system is said
to be unavailable if a failure occurs that prohibits planned
beam tuning, development or production. To achieve thisoverall availability, the Mean Time To Failure (MI'TF) goalis specified as 1 week, up from the current 4.2 days, and theMean Time To Repair (MTTR) goal is specified as 0.5 hours,
reduced from the current 1.3 hours. Achievement of thesegoals would provide approximately 11 hours additional beamtime per typical annual operation period.
In order to support the capacity goals, the upgrades arebeing designed with maintainability in mind. Currently 9.5
software personnel support 21 control computers accessing
approximately 16,000 data and control points. The upgrades
specify as a goal that the current staffing level must be able tosupport a minimum of 40 front-end computers accessing up to
32,000 data and control points. To achieve this, the numberof hardware diagnostics, software diagnostics and softwaretools must increase by at least a factor of two and the numberof distinctly different hardware systems utilized must be
similarly be reduced by a factor of two.

C. Considerations

Several specific considerations are being folded into theupgrade efforts. The first is long-term growth potential. Thisis directing effort toward the use of stable vendors andrecognized and developing software and hardware standards. A
desire for flexibility and robustness is to be addressed throughincreased modularity in both software and hardware. It would
also be desirable if the systems were designed such that beamline developers could rapidly prototype and develop their own
application software to reduce the support required by controls
staff.
A major consideration of the proposed plan is the desire tomigrate from proprietary systems, languages, andcommunication protocols to non-proprietary "open system"
standards in all areas. For operating systems, the intent is tomigrate to the POSIX open system standard when it is
implemented. For communications, the Open S~stemInterconnection (OSI) standard DECNET Phase V will be

S02SRU01
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

51

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

preferred if it meets performance needs. Portable languages
such as FOR1RAN, C and C++ will be preferred.

IV. THE SOLUTION MODEL
To address the problems a simplified model of the control
systems was used. This model, shown in Figure 3, is astatement of the elements and interfaces which must be
standardized if the desired results are to be obtained. The model
illustrates four levels; Data Acquisition and Control
Computers, Communication Systems, Applications Systems
and Operator Interface Systems.

Figure 2. The Solution Model

A. Data Acquisition and control computers
This element of the model refers to the remote computer,hardware interface and low level software used to connect thefront-end hardware to the communication medium.

B. Communication Systems
This element represents the hardware and software support
required for a network based distributed computer control
system. It provides the necessary interface between application
software and the remote computers that actually acquire data
and manipulate control points.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU01

V.THESOLUTIONIMPLEMENTATION
The application systems, communication systems andremote data acquisition and control computers are alreadyestablished in the form of existing LCS elements. The
additional solutions developed must integrate well with boththe existing and developing systems to preserve
maintainability goals.

A. Data Acquisition and Control Computers
This element will be provided by the proven LCS
V.AXELN-CA?\1AC system. It is intended that this element
provide both a RICE replacement and the PSR PDP-11
computer replacement.
VAXELN is the preferred remote computer operating
system for the upgrade at this time. It provides a large array ofdevelopment tools, integrates well with the current system andhas an apparently solid upgrade path for the next 5-plus years.
This implies a commitment to VMS, the development system
for VAXELN, for at least this period. The vendor has indicatedthat both VMS and VAXELN will be POSIX compliant in the
future, providing open system compatibility.
As stated, the device interface will be CAMAC, currently
in use in the PSR system and in a significant portion of the
LAMPP control system. As the PDP-11 computers are
replaced, existing applications software will be modified to use
a data-on-request approach thereby eliminating the resident
PSR database and the current PSR control system over time.
As RICE modules are replaced, the hardware that is removed
will be used as spare parts to support the remaining RICE
modules.
Experience with VAXELN controlled CAMAC systems
provides confidence that the performance goals of the upgrade
can be met. VAXELN/CAMAC driver testing has determinedthat CAMAC reads can be accomplished in 35-50
microseconds. A small number of these systems distributed
throughout the site can meet the current and predicted dataacquisition requirements.

B. Communication Systems

C. Application Systems
This element represents the algorithms and softwaresystems that relate operator interface tools and beam line
elements in a functionally useful manner. Physically, thiselement is an interface between the operator interface tools andthe communication system.

D. Operator Interface Systems
This is the set of hardware and software mechanisms
established to provide the user with the ability to interact withapplication software and thus the beam line instrumentation.

The communication system is intimately tied into theperformance question. The LCS Remote Procedure Call
(RPC) System will be utilized as the basic communication
mechanism. Controls staff have performed, and are continuing
to design, network performance tests to evaluate the system.
The level of network traffic anticipated for the newarchitecture has been estimated through measurement of peakdemands on the current network with allowance for future
expansion. Tests indicate that the current Ethernet/DECnet
network is adequate for the near-term future even with theaddition of the 10-20 computer nodes predicted for the RICE
and PSR Upgrades. The effects of the 5-10 additional nodes
needed to support proposed linac upgrades are currently being
considered. An Ethernet/DECnet-based network provides a

S02SRU01
52

Status Reports: Upgradestandard that is compatible with a variety of computer
platforms and operating systems.
While a simple network architecture will accommodate
current projections, future requirements for segmentation must
be included in planning. The addition of increasingly powerfulcomputers to the network is the most likely future growth
path and problem. When the networks are no longer cpu power
limited, segmentation, through the use of bridges and routers,
and new network technology such as FDDI will be required toprovide solutions.

C. Application Systems
An effective application system is dependent upon thestandardization of certain sub-elements and the development of
a consistent "application viewpoint" of the machine.
The manner in which an application views its relationshipto the data it desires is a critical element. The current PSR
applications view data as continuously available since thesystem uses a continuous polling mechanism. This contrasts
with the data-on-demand LCS applications. The upgrades
recognize that a system that combines polled-data at the remotelevel with demand-data at the application level may be required
to provide the performance that is desired and adapt to theconflicting application viewpoints. A version of such a system
is being used in the RIU-MicroVAX [1]. This system
continuously polls frequently requested data so that values canbe supplied from a real-time database for this data. Less
frequently requested data is read from the hardware when
demanded.
Questions surrounding application requirements for device
control locks, access to global data, data integrity and error
handling remain to be addressed. These issues are further
complicated in the highly distributed system that isenvisioned.
Concurrent with standardization of the applications
systems, the standards that are in place for control system
software development will be re-examined These include
requirement, design and user documentation procedures as wellas configuration management systems.

Inteiface Systems
It is believed that VAX-based workstations will provide thecommon interface hardware to replace both PSR and LAMPF
console systems. The selection of VMS systems is to provide
compatibility with the current VMS-based application andsystem software. Efforts are underway to evaluate userinterface management systems against operator and developer
preferences. The rapid development of commercial softwaretools in this area promises to assist in this effort. The firststep in this process is a planned emulation of the existing
LAMPF color CRT. This will provide a common interface
for all parts of the installation and provide computing power tooff-load the central control computer, thereby improving
performance. This distributed interface system will similarly

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU01

contribute to an increase in control system availability by
reducing the number of potential single points of failure.

VI. SUMMARY OF CURRENT EFFORTS

Several projects have been established to provide theupgrades to the systems as they have been described. The
projects are the RICE Upgrade, the PSR ISS Upgrade, theOperator Interface Upgrade and the LAMPF Database Upgrade.
Obviously, the pieces are not separate and must interact
closely with each other to provide the standard elements of the
proposed model. Existing resources and prioritization of thevarious problems are driving forces in selection of thesolutions. Effort is already underway through work on all of
the projects at various levels.
The RICE Upgrade has completed the requirements phaseand is moving into design. Network and driver testing has
been performed to insure that the systems selected will becapable of meeting the performance requirements. Evaluationof computer platforms is underway. The initial steps indefining a diagnostic system that will adequately support the
new data system have been taken. Part of this effort is todesign a CAMAC-based timed data system to replace thefunctionality of the RICE system.
The PSR ISS Upgrade is in the requirements phase,working rapidly in order to provide feedback to the RICE
Upgrade project to insure that incompatibilities are notdesigned into the new front-end system. Efforts at defining thescope and complexity of the project are ongoing.
The Operator Interface Upgrade is also in the requirements
phase. Much preliminary work has been performed. This
work involved evaluating commercial Graphical User
Interface's (GUI's), evaluating X-Windows as a graphics tool,
determining what solutions are being used at other accelerator
facilities and defining LAMPP control system user preferences.
The LAMPF Database Upgrade is in the requirements
stage, although significant effort has been expended to bringthe LAMPF database philosophically closer to what the PSR
system requires. The LAMPF database can now support PSR
devices, a necessary first step to integrating the systems [I].
A steering committee within L'1e controls section has been
established to coordinate the efforts. Quarterly internal projectreviews and an external review of the combined projects areused as a means assuring the quality of the effort. The goals
described in this document will be used as a measure of
successful project completion.

VU. REFERENCES[1] S. Schaller, R. Stuewe, et. al., "Experience Controlling the
LAMPF-PSR Accelerator Complex," these proceedings.

[2] G. Carr, S. Schaller, et al., "The Status of the LAMPP Control
System Upgrade," Proc. Europhysics Conference on Control

S02SRU01
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

53

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3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japanand SERVERS

UNIX

UNIX
CONTROL CENTRE NETWORKBACKBONE NETWORK IEEE 802.X

IEEE 802.3 ETHERNETIEEE 802.5 TOKEN-RING

TCP/IPREGIONAL NETWORK IEEE 802.X TCP/IP

Lya:rOSBRANCH

RT-UNIX

RT-UNIX

RT-UNIX.[p:rOS

Ly1i:rOS

EQUIPMENTSER!AlCAMN:.

(CIR)

1553 FIELD BUS<MESSAG81553 FIELD BUS. GPIB_

ECA's ..-....
CONT~--------EQUIPMElff CLUSTER --------I

Figure 1. Control System Architecture

B. Networking
The communication between the Control Room layer andthe Front End Computing layer, as well as the communication
within these layers, is based on modern standards using
TCP/IP as the main inter networking protocol suite. The
network is composed either of Token Ring or Ethernet
segments linked together through bridges or routers. However,where required, routers are implemented in order to filter theaccess to the control systems from offices, laboratories or theoutside world.
The future use of FDDI as an additional fast network is in
test between Meyrin and Prevessin sites (utilization by bothcontrol systems of an ORACLE on-line data base server).
A Remote Procedure Call (RPC) mechanism offers a way
for the programmers to call the libraries located in remotecomputers, hiding as much as possible the network (CERN
designed RPC including an interface to the old control
network). TELNET and FTP are also available in connection
with the TCP/IP protocol suite.

C. The Front End Computing layer:
The Device Stub Controller (DSC)
The Front End Computing layer is centered on the Device
Stub Controllers (DSC) which are based on both standards PC

and VME crates with 32 bit embedded microprocessors. A
diskless Real Time, UNIX compatible, and POSIX compliant,operating system is run in the DSC. The diskless solution
was chosen because the disks of the Process Control Assemblies (PCA) of the LEP control system proved to be a weak
point and because the back-up procedures and management offiles and data are supposed to be easier if storage is lessdistributed.
The main functions of the DCS are:- to provide a uniform interface to the equipment as seenfrom the workstations;- to provide direct control and acquisition for equipment likebeam instruments, interfaced directly to the DSC;
- to act as a master and data concentrator for distributed
equipment, interfaced via a field bus.
The choice of the standards for the DSC, PC and VMEbus, was not easy. With the limited resources (staff numbers
decrease while the number of new projects increases) theControl groups initially intended to provide support for the
VME bus only. However, after long discussions, because of
the 65 existing LEP PCA (Process Control Assembly) basedon PC and because of quite complementary advantages, it was
decided to give support to the two standards, PC and VME
bus. This decision mainly became possible with theavailability of an open Real-Time, UNIX compatible,
operating system which runs on both platforms. Figures 2
and 3

S02SRU02
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

CO~OLESCENTRAL

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU02

55

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

OIR::CI 110
CO-.'\ECT I~

DSC

RT-UNIX-··ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU02

buses. Since no predominant standard exists, a certain variety
of solutions, both for the ECA and for the field buses, isconsidered to be acceptable. As the main front end computing
device is supposed to be the DSC, the computing on the ECAlevel should be reduced to a minimum.

LJ•.OS

(

s 8 c
0 C T

!'5232

TC
I p

MU
T

0
L

VME
CRATE

!.-+-~GMT llMiN;;

JEEE••88 IG"lBl

1553 FJEl.0 SUS-----sYSTO<S & EOJIP>E>tlS - - - - - - -Figwe 2. Device Stub Controller
This Real Time UNIX compatible operating system,
LynxOS, has been chosen to allow running several tasks
concurrently (beam measurement, statistics, alarms, diagnostic
programs), and to provide a fast and deterministic response toexternal events when necessary (Pulse to Pulse Modulation for
example). It will make it relatively easy to port the XENIX
system libraries and servers developed for the LEP PCA to thenew operating system.
To provide disk service for the diskless DSC andworkstations (as well as boot server, secure disk space forapplication and data and back up facilities) file servers will bemade accessible. Central file servers are used in general.
However, in order to keep the load on the backbone network
acceptable and to maintain local control alive in case ofcommunication problems, it has been decided to implement
regional file servers on important network segments.
Associated to the DSC, one can distinguish between threedifferent types of local man machine interface:• Local display (for the DSC based on VME): a graphic
VME module is directly driven by the CPU. It could becompleted by a touch-panel when a more convivial
interface is needed for local operation.
• Local terminal: connected to the CPU of the VME cratewith an RS232C line. This access can be used during
debugging or testing.
• Regional console: a workstation, a PC with UNIX or a
X-terminal, directly connected to the network segment,
could be seen as a local use of the services available in theControl Rooms, and can be directly used as a local
terminal with TELNET connection.

E. Field buses
In the present CERN accelerator Control Systems, threefield buses are used to a large extent: the 1553 field bus [2] andthe GPIB in the LEP area and serial CAMAC in the PS area
and the SPS experimental areas. At the PS complex, the
CAMAC crates will be controlled directly by a VME modulethat drives the serial loop [3] whilst in the SPS experimental
areas the CAMAC crates will be connected to the VME or PC
DSC via the VICbus. The SPS main ring equipments will
mostly be interfaced to the 1553 field bus. Proprietary fieldbuses delivered with turn-key industrial systems will beinterfaced directly to the DSC. [4] Due to the large investmentin the associated interface equipment, all three field buses will
be supported in the DSC environment.

F. Support to Equipment groups
The equipment groups may need to develop software tocontrol their equipment either in the DSC itself or at the ECAlevel. When the DSC is directly dedicated to an equipment
through interface cards, the control group will offer assistance(cookbook, basic driver "frame") to write the drivers accessing
the specific hardware. When the equipment is connected to the
DSC through a standard field bus , the Control Group will

B BC

cc~

D. Equipment Control /ayer
The control crates of the third layer, the Equipment
Control Assemblies (ECA), are connected to the DSC via field

Figure 3. Process Control Assembly

S02SRU02
56

Status Reports: Upgrade

provide the equipment access functions in the DSC. At thelevel of the ECA, the use of OS9 and LynxOS will get some
support from the Control Groups.

G. Proposed Equipment Control Protocols [5]The best result for the control of a given equipment isobtained when the Equipment Group is totally responsible for
its implementation. It is proposed, and already in the
beginning of implementation, to use a general operational
control protocol which leaves the equipment specialists
dealing with all the intricacies of their equipment (either at thelevel of the DSC or the ECA, where applicable), whilst thecontrol groups take care of the operational requests for thisequipment as well as the communication part.
In this scenario, the accelerator operation crew defines a
uniform frame for a given equipment interaction, the specialist
realizes the specific, local software in the most adequate wayfor each device, and the controls provide a uniform softwareinterface to translate the operator requests into control
sequences for the equipment.

III. APPLICATIONS

A. Basic buildings blocks and tools
The basic building blocks and the tools for the
Applications are centered around Open Software Standards.
UNIX is confirmed as the operating system of theworkstations, the development environment of the DSC andthe network servers. The DSC operating system is a UNIXcompatible system with real-time performance. (LynxOS)
TCP/IP protocol suite and NFS are the basic components for
all distributed facilities. Compliance with standards is
enforced. rne POSIX IEEE 1003.1 interface definition must
be respected. The X-Windows is selected as the base graphic
system for workstations : for general data presentation
facilities and user interactions, all future developments will bebased on the X-Windows protocol and the OSF Motif toolkit.

Management
A well supported set of data management facilities inside
the CERN accelerator control systems is needed to cope withthe large quantity of data provided by modem electronicequipment and beam instrumentation. The study of thedatabase services sub-group concluded that a dedicated PS/SL
database server running ORACLE would be useful. The hostmachine for this service is installed and first tests andmeasurements concerning the performance of ORACLE as an
on-line database are in progress.

C. Software development facilities
The use of modem CASE tools are encouraged for analysis
and design of software projects, but one cannot expect to

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU02

enforce a systematic application for all projects and to allparticipants. Source code management tools provided with
UNIX are available for keeping track of the history ofconsecutive versions. "C" is the common base language, as it
is well integrated in UNIX platforms and offers a goodportability {as accepted by the Portable C compiler). The
NODAL interpreter (written in C) is available on the DSC andon both workstation platforms in use, DEC and HewlettPackard. Fortran may be used, but only for mathematicalapplications. (mainly modeling)

D. Environment of application software

The development environment should be as similar as
possible to the operational environment in order to ease thetransition from development to operation and to allow good
productivity and maintainability by the knowledge of a single
environment. Standard procedures must be established forvalidation by the users {operation, accelerator physicists,
equipment groups) and controls exploitation staff. A complete
application program must be designed with integration into
the Console Manager in mind; the Console Manager is thesupervisor of all activities induced by the workstation.

E. Application run-time environment

No synchronization with the cycle of accelerators will bedone through workstations. The equipment cannot rely on
software for its protection, and the equipment groups will haveto provide means to protect their equipment against unallowed
actions through the control system.
·

Man Machine Interface

The major goal is to reach as much uniformity as possible
for the operation environment. To preserve the future software
investment in MMI, the OSF tool kit MOTIF will be used on
top of the well established and widely used X-Windows
standard display protocol. The console manager activates andcoordinates the various processes according to the requests of
the user. Synoptics will be widely used in the controls of theaccelerators (as they are also the natural tool offered for various
industrial equipment); the DVDraw/DVtools product,
encapsulated in a man machine interface, will be used for the
production of such synoptics. [6] [7]

G. General Control room environment andoperator desk

The operation of accelerator clusters through the control
system is done by operator teams working 24 h a day in thecentral control rooms and using consoles as the main tool formachine interaction. The notion of "work place" is now
preferred to the one of console. The powerful workstations are
the main interactive tool composing a work place; they are thetools to select, visualize and drive the batch of application

S02SRU02
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

57

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
programs to control a selected part of an accelerator. The work
place is completed by tools to observe and select analog andvideo signals, and to display alarms.
Beside the workplaces, an accelerator control center must
contain tools to display general information summarizing thestatus of the accelerator complex, means to communicate withlocal building and other control centers, means to access othernetwork facilities, and tools to manage personal safety whichmust be treated separately from accelerator control.

IV. CONVERGENCE POLICY
Because of the large hardware and software investment
needed, the limited manpower available today, the similarity of
the control requirements for the various machines and theincreasing complexity of the software tools for running them,
it is mandatory to reduce the diversity of control
implementations at CERN.
The constraints imposed on the convergence by the historyof the different machines, the large amount of investment inexisting hardware and software, the different types of machines
to be controlled, and the habits adopted by the operation crews
interacting with these machines must be taken into accountwhen defining a common PS/SL policy.
This common policy will be based on a common control
system architecture, using well established industrial standards
for control networks, communication protocols, equipment,
operating systems and man machine interface. Thisarchitecture will profit from and enforce the use of OpenSystem products supported by many manufacturers andconsortiums. (UNIX, OSF, X-Windows for the software;
Ethernet and Token-Ring with TCP/IP for the control
network; UNIX workstations for the man machine interface;
PC and VME for the DSC and equipment interfaces).
As much software as possible must be written
independently of the development platform (using industrial
products), opening the possibility to transfer application
programs between the different accelerators.
An other main goal of the common policy must be topreserve the existing hardware and software investment. The
application software developed for the exploitation of theaccelerators represents hundreds of man-years of investment
which has to be maintained, improved and optimized to ensure
uninterrupted operation. The proposed architecture makes
provision to integrate the hardware investment in CAMAC
and MPX in providing adequate tools to access these crates.
The software investment in the SL-PCA is preserved by using
a UNIX compatible real time operating system in the DSC.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU02

V. CONCLUSION
This is the summary of the consensus which has emerged
from the discussions about the architecture of CERN's
accelerator control systems, their main components and thegeneral aspects of the application software. A major concern
was to preserve the existing hardware and software investment,
together with a non-duplication of the effort inside CERN's
accelerator community.
Our main aim was to propose an architecture which
permits continuous partial upgrading, as technology evolves,in order to avoid any "big bang" operation in the future. The
main components of our control systems are based on open
standards, for the hardware as well as for the software, tobecome independent of a given manufacturer.
Finally, to monitor the progress of the consolidation
project and to ensure that all our efforts stay directed towards acommon goal, the working groups (or at least an emanation of
the two working groups) continue to meet during theimplementation of the different steps of the project.

VI. REFERENCES
[1]
[2]

[3]
[4]
[5]

[6]

[7]

The PS and SL controls groups, "PS/SL Controls
Consolidation Project", Technical Report, CERN PS/91-09(CO), CERN Sl/91-12 (CO), April 1991.
R. Rausch, "Control of the large European LEP and SPS
Accelerators Based on the 1553 Field Bus", CERN Sl/9005
Report, Conference on MIL-STD-1553-Band the Next
Generation, London, United Kingdom, 29-30 November,
1989.
W. Heinze, "Driving serial CAMAC systems from VME
crates", these Proceedings, November 1991, ICALEPCS,
Tsukuba, Japan, 1991.
K.H. Kissler, R. Rausch, "New Control Architecture for the
SPS Accelerator at CERN'', November 1991, these
Proceedings, ICALEPCS, Tsukuba, Japan, 1991.
WOPRO Working Group, reported by G. Benincasa, Control
Protocol : "The Proposed new CERN Standard Access
Procedure to Accelerator Equipment : Status Report", these
Proceedings, November 1991, ICALEPCS, Tsukuba, Japan,
1991.
M. Boutheon, F. Di Maio, A. Pace, "General Man-MachineInterface used in Accelerators Controls: some applicationsin CERN/PS Control System Rejuvenation", these
Proceedings, November 1991, ICALEPCS, Tsukuba, Japan,
1991.
P. Antonsanti, M. Arruat, J.M. Bouche, L. Cons, Y.
Deloose, F. Di Maio, "Workstations as consoles in the
CERN/PS complex: setting up the environment", these
Proceedings, November 1991, ICALEPCS, Tsukuba, Japan,
1991.

S02SRU02
58

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

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 Publishing

Apollo file server via an IBM Token-Ring network. A
gateway from the Token-Ring to the old propri~tary s~
network of the SPS permits the Apollos to commumcate with
the NORDlOO computers.

[4]. Here only a short summary will be given to make thispaper self-contained.

doi:10.18429/JACoW-ICALEPCS1991-S02SRU03

A. Architecture
The new architectu're is based on three computing
layers:CENTRAL CONSOLES

the Control Room Layer which provides the operator
with a user friendly interface using modem UNIX
workstations with OSF Motif and X-Windows graphic
software packages. This layer comprises also a number ofcentral servers for data and file storage, model computing,alarm collection, network management and for an on-line
relational database.
the Front End Computing Layer with its so-called
Device Stub Controllers (DSCs) based on Personal
Computers (PCs) and VMEbus systems, running a POSIX
compliant real-time operating system. Secure disk space isprovided locally or centrally by dedicated file servers. Local
access and graphics are standard features of PCs and areprovided on VMEbus crates by terminals and displays
connected to dedicated modules. Alternatively, a local
terminal server or an X-Terminal, connected to the Ethernet
segment, will provide access to all computers (local or
remote) on the control network.

'""-............

.... ......."'".....:sac_...-____-..... _......
.... ...... ____ ...........

-~-~-:.. \..1.~i;.s

3 -~$\ S~"'

INJt::or1o·N·-------lINt::

Figure I. Present SPS Control Network.
The SPS was also used as a test bed for the LEP
control system [2]. To this end a full network infrastructure
including a backbone Token-Ring around the accelerator anda Time Division Multiplex (TDM) system for long distancetransmission were installed at the SPS well before this was
possible in the LEP tunnel. All SPS auxiliary buildings were
equipped with LEP type Process Control Assemblies (PCAs).
Each of these consists of a PC linked to a VMEbus crate via a1553 connection, the VMEbus crate containing the bus
controllers for the 1553 field buses which extend to theequipment. This infrastructure has permitted to validate thetechnical choices for LEP, but will now also serve in theframework of the new SPS controls.
III. CERN's NEW CON1ROL ARCJilTECTURE
The new control system architecture on which the
PS and the SPS/LEP control groups have agreed after
extensive studies and consultation with the control systemusers, is laid down in a comprehensive report [3] andpresented in some detail in another paper at this conference

the Equipment Control Layer with Equipment
Control Assemblies (ECAs) connected to front end
computers via field buses and to the equipment by mean ofgeneral purpose or dedicated electronic modules. Branch orserial CAMAC and 1553 field bus will allow to integrate
existing CAMAC and MPX crates at this level. Figure 2.

B. Network and Communication
The data communication between CERN's different
Main Control Rooms will be done via a Fiber Distributed
Data Interface (FDDI) network. The FDDI is a Local Area
Network (LAN) protocol defined by the ANSI X3T9
Standards Committee. The network has a ring topology, uses
token passing access, a fiber optic transmission media,
provides a 100 Mbit/s data rate, can span distances up to2000 meters and supports up to 500 network nodes. This
FDDI network will allow to share common PS-SPS servers
and an ORACLE data base computer.
The communication within and between the Control
Room and the Front End Computing Layers is based onmodem LANs: Ethernet and Token-Ring conforming to IEEE
802.X International Standards and using the TCP/IP protocol.
Program communication will rely on a CERN designed
Remote Procedure Call (RPC) until a standard is defined andindustrial products become available. Where long distances
are involved (>500 meters) a Token-Ring backbone is
implemented with transmission over TDM equipment
conforming to the CCITT G700 Standard.

S02SRU03
60

Status Reports: UpgradeCENTRALICALEPCS1991, Tsukuba, JapanCONSOLESandSERVERS

UNIX

UNIX
IEEE 802.X

CONTROL CENTRE NETWORK

TCP/IPIEEE 802.3 ETHERNETIEEE 802.5 TOKEN-RINGBACKBONE NETWORK IEEE 802.X TCP/IPREGIONAL NETWORK IEEE 802.X

I
BRANCH IORSERIALCAM ACTCP/IP

RT-UNIX

I
I
I
I
I
I
I
I
I
I
I

RT-UNIX

RT-UNIX

LyzvrOS

ECA's

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU03

LptxOS.l.y11xOSI

LOCAL
TERMINAL

EQUIPMENT

CAMAC
(C/R)
1553 FIELD BUS

CAM AC(MESSAGE)
1553 FIELD BUS, GPIB, ....

ECA's ••••••

L

CAMAC

laUl~MENf
Figure 2. New Control Architecture.

C. Operating Systems

It has been decided to use a UNIX environment forthe control of CERN's accelerators to the largest possible
extent.
UNIX is the only operating system supported byvirtually all computer manufacturers, from the PC clones up
to the large CRAY or IBM mainframes. UNIX provides
scalability which allows to move programs and data fromsmaller machines to larger ones. UNIX avoids getting
trapped in a proprietary environment: overcharges, poor
services, failure to provide an upgrade path, company whichgoes bankrupt, etc.. In this case the portability of UNIX
pennits to move programs and data to another brand of
hardware. For the programmers it is easier to port anapplication between any two versions of UNIX than any two
closed operating systems. In addition, combining UNIX witha public networking standard (TCP/IP), it provides
interoperability; the ability of networked computers to sharefiles and applications.

For the front end process computers, it has been
decided to use a commercial real-time operating system,
which runs on both industry standard 386/486 PC/AT
compatibles and VMEbus CPU modules, based on theMotorola 68030 microprocessor, and which complies with
the IEEE 1003-(1990) POSIX standard (POSIX.l for theapplication program interface, POSIX.2 draft for shell andutilities and POSIX.4 draft for the real-time extensions).
The acronym POSIX stands for Portable Operating
System Interface. POSIX is written by IEEE working groups
as a US standard and acquires international status via its
acceptance by ISO/IEC (International Standard Organization
International Electrotechnical Commission) as International
Standard 9945, [5].
POSIX is a software interface standard whichguarantees portability of application source code but is not an
operating system implementation standard. Real-time POSIX
addresses the full range of real-time systems, from full scale
UNIX down to small embedded kernels with the highest
demands on true real-time perfonnance.

S02SRU03
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

61

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

It is well known that basic UNIX is not designed to
be a real-time system. Its goal is to give a fair share ofsystem resources to every user, not to have, for instance, ahigh priority process taking the CPU and keeping it as longas necessary. On the contrary, real-time POSIX ensures anoperating system the ability to provide a required level ofservice in a bounded response time.
Following a CERN tendering procedure LynxOS has
been selected.

system Domain/Dialogue, all future developments will makeuse of the X-windows protocol and OSF Motif (toolkit, User
Interface Language, resource manager, style guide).

IV. IMPLEMENTATION OF TIIE NEW ARCI-IlTECTURE
ATTHESPS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU03

C. The SPS control network
As mentioned before, a backbone Token-Ring was
installed around the SPS a few years ago already, completed
by local Token-Rings in the main control room and in the
SPS auxiliary buildings. To this installation, local Ethernet
segments will now be added in order to guarantee a better
connectivity of equipment from different vendors to the
network.

A. General consideration
D. Front End Computers
CERN's new control system architecture describedabove defines the general framework and the guide lines tobe respected when replacing the old SPS system. It leaves,however, the freedom to take account of other facts proper tothe SL division: the existence of and experience with the LEP
control system as well as the infrastructure created during the
preparation of the SPS as a LEP injector. Both facts, inparticular the experience with the LEP system and the desire
to create a uniform controls environment for the two
accelerators, have had and are still having a strong influenceon the detailed choices made for the SPS.

B. The Control Room Layer
SPS and LEP are both operated from the same
control room. Apollo workstations running under Domain OS
10.3 are currently used to provide the operator interface to
LEP and also to control the supercycle operation of the SPS.
More powerful machines of the same workstation family
offer central services, such as data and file storage or modelcomputing. Recently, Hewlett-Packard workstations, model
9000/400 and 9000/425, still running under Domain OS, havebeen added to the system.
We are now in the process of introducing a few DEC
5000/200 workstations, running ULTRIX 4.2, into the SL
control system. Their main function is to provide centralized
secure disk space for applications and data, to provide disk
service for diskless front end processors and to be thebootstrap servers for front end processors, workstations andX-terminals. The DEC stations were mainly chosen in theframework of the collaboration with the PS division,
permitting to set up common services like a common
ORACLE database.
In the near future, HP 9000n3o and 9000n5o
workstations will make their appearance at SL. Running HP
UX 8.05, they will add to the diversity of UNIX flavors usedat the level of the SL control room layer. This diversity is
considered to be temporarily acceptable and should largely
disappear with the future introduction of the OSF 1 operating
system for both DEC and Hewlett-Packard workstation
families.
While the general data presentation and userinteraction in the SPS/LEP control room are presently stillbased on the Apollo proprietary user interface management

All NORDlOO computers will be replaced
progressively by front end computers based on PCs or on
VMEbus crates depending on the type of equipment they
control, on the necessity to have local mass storage, graphics
facilities and local interactivity for testing purposes. It isessentially the responsibility of the Equipment Group in
charge to decide which technical solution is best.
Typically, equipment like beam instrumentation
which needs fast response and high throughput, will bedirectly connected to modules located in VMEbus front end
computers. These in tum will be connected to the local
Ethernet segment and share either a local or a central fileserver. Such an arrangement has recently proved to be very
successful at LEP where some 40 VMEbus crates with directconnection to the network are used for closed orbit correction[7].

For systems with large numbers of identical
Equipment Control Crates (ECAs), PC based front end
processors will be used to regroup the ECAs via a 1553 field
bus and enable local supervision, alarm reduction and alarm
identification before transmission to the main control room.
The Process Control Assemblies (PCAs) described in chapter
II will be the most frequent configuration used in thiscontext.
Local consoles, PCAs and VMEbus based front end
computers installed in the equipment buildings will operate
under LynxOS and will be able to run the same programs as
the central workstations and servers located in the main
control room, all will communicate over the control network
using the TCP/IP protocol.

E. Equipment Field Buses
In LEP, ECAs usually contain microprocessor units
and are addressed in message mode via the 1553 field bus.
This mode of operation will also be used in the SPS
whenever old obsolete electronics will be replaced by newmodem boards housed in intelligent control crates [6].
However, many of the existing MPX crates are stillworking reliably and will be preserved. In this case the old
MPX multidrop bus, connecting them via a CAMAC crate to
the NORDlOO computers, will be replaced by a 1553 field
bus, generally controlled by a PCA. As no microprocessor is

S02SRU03
62

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 Publishingused in the MPX system, the 1553 field bus will be working
in command/response mode and a special 1553/MPX
interface card has been developed for this purpose.
It is at the field bus level that the General Machine
Timing (GMT) is distributed to the equipment. For
economical reasons and cabling simplicity, both control andtiming signals are transmitted over two twisted pairs of wires
in the same multidrop cable [8].
Other field buses can be used at the SPS to link
ECAs to the front end processors. Industrial systems are oftendelivered with a proprietary field bus: Bitbus, Fip, Filbus, Jbus, Profibus, Proway, etc.. To be integrated into the SPS
control system these industrial systems must be delivered
with a VMEbus or a PC/AT bus controller and an adequate
software driver, compatible with the LynxOS real-timekernel, must be available. In addition, the manufacturer's
equipment control protocol must be known and be converted
to the CERN standard to allow homogeneous access to all
equipment of the accelerator from the operator's workstation.
The experimental areas of the SPS present a special
case where the existing field bus, a serial CAMAC loop, will
be replaced by Ethernet. A PC connected to the local

Ethernet segment will be installed in each of the stations
which regroup the equipment control hardware. This
hardware will continue to be controlled by CAMAC modules
and their CAMAC crate will be linked to the PC by theparallel Vme Inter-Crate bus (VICbus).
V. THE MIGRATION PATII
A major step of the migration towards the newcontrol architecture is planned to take place during the 199192 winter shutdown of the SPS.
The existing gateway between the old multistar
network and the new Ethernet/Token-Ring infrastructure only
allows communication in command/response mode from theApollo workstations to the NORDlOO computers. It will be
replaced by a new bidirectional gateway which will enable
the NORDIOOs to address to services on the new network.
The library computer used for data and file storage and other
NORDlOO based servers, all operating with obsolete disk
units, will then be removed and their tasks taken over bymodem workstation based servers.

H.P.-APOLLOWORKSTATIONPCR NETWORK

PC.A
LJ'•xOSNORD100NORD

COMPUTER

Vt.IE
PARALLEL

PARALU!LSUS

UO BUS_../
VICbuo,,,,/'
B B

c
c

u u u

c c c

N

0

0

0

CA MAC
CRATE

VME
CRATE

MPX-BUSc c1553 FIELD BUS

v

s
I
c

1553 FIELD BUS. - - - - - - . (Command/Response) ,...__.__,(or/and Message)
ECA
ECA

\.
MPX-ST /

·..

i

~

i

'\. 1553-RT

I

ECA

'

'

EQUIPMENT TO BE CONTROLLED

EQUIPMENT TO BE CONTROLLED

Figure3. Migration from NORDlOO to PCAs

S02SRU03
Status Reports: Upgrade

63

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-S02SRU03

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-S02SRU03

The new gateway will be installed during the month overall planning is essentially determined by the duration ofof October and put into operation during the last two months the annual accelerator shutdown and available manpower,of the year. This new gateway will first operate in parallel particularly in the field of application software.
with the old one to allow for software debugging during
VII. ACKNOWLEDGEMENTS
accelerator operation while keeping the possibility to switch
back at any time in case of problems.
Many members of the PS and SPS/LEP control
At the same time a new version of the CERN RPC(Remote Procedure Call) will be introduced as well as an groups have contributed to the definition of CERN's new
improved version of the NODAL interpreter, written in C control system architecture and to the application of the ideas
within the SPS environment. The authors wish to thank themlanguage, providing additional functionalities.
During this winter shutdown existing VMEbus based all. Particular thanks are due to J. Altaber and F. Perriollat
front end computers and PCAs will be connected to local who where co-authors of the first proposal to harmonize the
Ethernet segments which in tum will be bridged to the controls of all accelerators at CERN.
Token-Ring backbone and all PCAs will be upgraded by
VIII. REFERENCES
using the VICbus connection to the VMEbus crates, insteadof the 1553 link.
M.C. Crowley-Milling, "The Design of the Control
It is also foreseen to install LynxOS 2.0 in the PCAs, [1]System for the SPS," CERN 75-20 Report, 22
in replacement of the present SCO XENIX.
December, 1975.
This upgrade combined with the general use of NFS(Network File System) and the hardware improvements
P.O. Innocenti, "The LEP Control System,"
described above is expected to provide a better overall [2]International Conference on Accelerator and Large
performance and response time compared to that of theExperimental Physics Control Systems, Vancouver,present LEP control system.
In the main control room DEC file servers have
BC, Canada, 30 October - 3 November, 1989.
already been installed to provide secure file space forprograms, applications, data storage and remote boot facility [3]The PS and SL Control Groups, (Editors: R. Rauschfor the PCAs and the VMEbus based front end computers.
and C. Serre), "PS/SL Controls Consolidation
Existing Hewlett-Packard workstations will be used
Project," Technical Report, PS/91-09 or SL/91-12,
with X-windows and Motif to write new application
CERN, Geneva, Switzerland, April, 1991.
programs for the systems linked to the new infrastructure.
Thus the complete chain, from the operator workstation down [4]R. Rausch, C. Serre, "Common Control System forto the ECAs including the network and the new front end
the CERN PS and SPS," International Conference on
computers can be tested and debugged.
Accelerator and Large Experimental Physics Control
To facilitate the migration of application programs
Systems, Tsukuba, Japan, 11-15 November, 1991.
from the old NORDlOO consoles to the Hewlett-Packard
workstations, for equipment remaining to be controlled by [5]C. Eck, "Standardization of Real-Time Software
MPX crates, an alternative access will be possible for test and
POSIX 1003.4," Real-Time 91 Conference, Jiilich,
debugging purposes during the transition phase. Figure 3.
Germany, 24-28 June, 1991.
VI. CONCLUSIONS
Modernizing the control system of a running
accelerator is a difficult task. Since its first operation in 1976
the SPS has undergone a number of smooth upgrades to copewith the changing demands of the accelerator exploitation.
Generally more installation of the same kind of equipment or
replacement of mini computers by more powerful ones of thesame family, was fairly straightforward.
This time, a drastic change is required. Computers,
networks, local intelligence, application and system
programming have changed totally over the last 15 years.
Hardware and software standards are available but the job
has not become easier for the control specialists. New skills
are required and system integration is the buzz word.
To preserve the integrity of the accelerator
operation, the migration work must be done in well defined
steps. The test bed chosen for the validation of the newarchitecture and the methodology adopted must be
representative and include all aspects of the project. The[6]

R. Rausch, "Control of the Large European LEP and
SPS Accelerators Based on the 1553 Field Bus,"CERN SL/90-05 Report, Conference on MIL-STD1553-B and the Next Generation, London, United
Kingdom, 29-30 November, 1989.

[7]

G. Morpurgo, "The Software for the CERN LEP
Beam Orbit Measurement System," International
Conference on Accelerator and Large Experimental
Physics Control Systems, Tsukuba, Japan, 11-15
November, 1991.

[8]

C.G. Beetharn, K. Kohler, C.R.C.B. Parker, J.B.
Ribes, "The Transmission of Accelerator Timing
Information
around
CERN,"
International
Conference on Accelerator and Large Experimental
Physics Control Systems, Tsukuba, Japan, 11-15
November, 1991.

S02SRU03
64

Status Reports: Upgrade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

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

I. The HOST level provides a general purpose and cosy system. These controllers which are referred to as front end
environment for software programming, debugging, off-line controllers (FEC) integrate the RTVAX300 chip, the CAMAC
calculations and displays, database management, and FEC replacing the present serial loop crate controllers.
- Programmable logic controllers (PLC) : S5-135U fromsimulation. It is built around I/ - a midrange DIGITALEQUIPMENT computer, the VAX600-4 l 0, connected to video SIEMENS, PB400 from TELEMECANIQUF/APRILCAMAC and VME FEC, as-well as the SIEMENS PLC
terminals through DECservers, 2J - workstations VS3100-76
equipped with 19' high definition color screens for graphics are directly connected to the controls Ethernet LAN.
oriented developments.
Communication between VAX processors and SIEMENS PLC
This level also realizes links with other facilities of the is achieved by DEC software packages : VSHl which supports
laboratory : compatible PCs and Mac serviced by a NOVELL the application-presentation - session layers of the OSI/ISO
server, CAD stations and the Physics acquisition Vax-cluster; standard and VOTS which provides services of the two nextin addition, it provides connection to remote physics lower layers. The PB400 PLC are connected to the server nodelaboratories via wide area netwoks (WAN).
µ V AX3800 by means of an asynchronous serial link that
2. The REALIIME CONTROL level allows operators to supports the master/slave JBUS communication protocol. The
control the accelerator by means of appropriate human very first APS30-12 programmable controllers, which areinterfaces. This level is based on a microVax3800, seven devoid of LAN connexion capability, are phased out.
The general Ethernet LAN, is linked to the sensitive
workstations VS3100 and X-tenninals VT1300 to benefit fromthe enhanced graphic capabilities within the XI I standard control Ethernet LAN via a bridge chosen for its filtering
multi windowing environment. V AXELN controlled VME capability. Communication protocols which are currently
boards are used to drive the shaft knobs. Man-machine DECnet, TCP/IP, LAT will comply with the OSI standard.
interaction will be emphasized in § II.4. The µV AX3800, Fig 2 displays the layout of the future control system.
which plays a key role in the real time control, is actually adual host cluster equiped with redundant disks to achieve someII.2 Software considerations
kind of "failure tolerance ".
3. The EQUIPMENT level perfoms low level controls
Requirementswith different kinds of front end processors :It is a matter of fact that software is taking a leading part
- CAMAC controllers (KSI3968 from KINETICSYSTEMS) and VME controllers (VME300 from AEON, ... ) in modem control system, as compared to hardware, with highadded value caused by large human effort (many people
running real-time applications under the VAXELN operating
involved over a long time to carry out).
VAX 6000-410

NOVELL
ServerPC
PHYSICS

VAX Cluster

Guicral Etlumtl LAN

VS3100-76µVAX3800

VT1300214 00Mb

VS3100-76

Control Etlumct LAN

PB400

VME/ELN

j 1s!5-135U

I

P

L

C

Figure 2. Schematic layout of the future Control System

S02SRU04
66

Status Reports: Upgrade66

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Our basic requirements are :- Dependable software to achieve productivity taking into
account modern tools and methods.
- Trustworthy and easy operation which implies
ergonomics.
·Well guided maintenance.
- Durability. GANIL evolutions, as a physics laboratory
may be stressing, unforeseen and of large amplitude. The
control system should face such a situation in the smoothest
possible fashion.

. Dispatch dedicated run time database to the proper
processor. Update in partial mode for some pieces of equipment or
Lr1 global mode (e.g. changing acceleration conditions). Archiving (e.g. beam parameters, profiles, settings,
operation logs, ... ) processing and presenting.
Workstations assum human operator interface :- Xterminal management for operator choice (task andhook names).
· - Process server to run processes selected by the
Xterminal.
- Translation algorithm to change hook names into

Choices
hardware addresses.
To meet our requirements, standardization is the key.
- Local presentation of alarms.
Operating systems : VMS for VAX processors and- Beam control processes with MOTIF widgets as operator
VAXELN for real time controls are adopted. VAX/VMS is anindustry (de facto) standard widely used in physics laboratories, interface.
At equipment level
VAXELN is chosen as a mature and powerful product which isControls are handed over to CAMACN AXELN andtailored for real time performances. It supports a host/target
connection over DECnet within a full VAX/VMS compatible VME/VAXELN front end controllers. GANICIEL functions
environment. Therefore, the host processor V AX6000-4 l 0 provided by these FEC are displayed on Fig 3.
performs developments and debugs while the targets (CAMAC Real time processes achieved at this level are :- Communication servers to receive all the requests fromand VME FEC) execute real-time controls.
Languages : A multilanguage system is chosen with workstations or other crate controllers.
- Hook to reserve and refresh the values of hooked pieces
ADA, Fortran and C. These languages comply with AFNOR,ANSI and ISO standards. ADA is our major programming of equipment.
- Surveillance to check whether a piece of equipment islanguage, while assembly language is relinquished.
Industry softwares : In addition to the software off specified limits.
- Alarms to send message to the main alarm server
packages devoted to the VMS environment, LANcommunication and management, some important software running onµ VAX3800.
- Handlers to control piece of equipment with drivers thatpackages are selected :. the INGRES family from ASK/INGRES devoted to only control the CAMAC.
relational database management (more in §II.3)
Control Ethernet LAN. the IMAGIN family from SFERCA devoted tosupervision (more in §II.4)• Xwindows and MOTIF (Xl 1R4).
DECnetI

Coma:unication server

Implementations
A basic software layer has to be designed to meet the
specific control requirements of the GANIL accelerator. This socalled GANICIEL layer is mainly transparent to the users andis built upon the industry softwares.
It makes widely use of the client-server model and takes
into consideration the distributed architecture which allows theclients and the server to run on different processors locatedanywhere in the LAN.
The following emphasizes the distribution of the
GANICIEL functions over the control system levels :At real time control level
The µ V AX3 800 assumes the function of a global server thatis fanned out into dedicated functional programs to handle
remote incoming requests.
Important ones are :- Initiation of appropriate functions (e.g. communication,tasking, ... ) on boot or on resumption.
- Surveillance of networking operation and FEC
execution.
- Alarm handling which deals with concentration, storage
and display for operator decision, in instant mode or differedmode with customized presentation.
- Data base management. SQL translation of request stemming from FEC

Remot,.
AccessDriver!!col< : 1COnsole -,Unhool< Update"

.j

And

!!ql.lipmant
Hardware drivers

I

I

1/0
su:v..1llanc6 Alllma Oatal:>asa
Hansg_,,tInter;>Nt"rI!IANDL!!RSInitialis.

Databua ..c:caH routines

I

I

I

CAl'.AC or VllE board"

Figure 3. GANICIEL Functions on FEC

II. 3 Information management
Information management is of basic importance in acontrol system. Due to :1. the various natures of information to manage :- acceleration conditions, beam parameters (ion species,
energies, ... )- realtime controls (node addresses, equipment
identifications and characteristics, alarm messaging, ...)
- operation logs
- reference characteristics ofcontrolled parts (hardware
installation and software)
2. the huge amount of controlled data (e.g. > 2500 piecesof equipment, beam parameters, .. )S02SRU04
Status Reports: Upgrade

67
67

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-S02SRU04

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 Publishing

3. the distributed topology of our control systemarchitecture (data flow vs time, up - and downloading, ... ),information management has to be carefully analyzed anddesigned to meet performances (access, integrity, speed, ... ) andavoid eonflicts which may be fatal.
Database managemept system
A careful investigation has led us to adopt a relational
database management system (RDBMS) to fulfil our needs
regarding NON-realtime purposes. We finally chose thecommercial INGRES RDBMS as having specifications which
fulfil our requirements and feature the open aspects we arelooking for. Main reasons are listed as followed :- Hardware independency, which allows straight forward
integration in the VAX/VMS environment.
• Comply with SQL standard.
- Encompasss a 4th generation language in windowing
environment (W4GL).
- High integrity, homogeneity of the products (QBF,
ABF, ... ) with good ergonomy consideration.
- ADA interfacing.
- and last but not least, a quality support.

Input device is keyboard to enter alphanum data, such as
the name of a piece of equipment or an expected value.
Output device for control tasks is commonly the screen of
the workstation for color graphics, associated with color printout devices.
Control devices are the popular reassignable knobs (shaft
encoded potentiometers) which are used on the "one knob - onepiece of equipment at a time control" basis. These shafts aregrouped into four-unit module to achieve ergonomy andperfonnances.
Pertinent alarm messages will be displayed on the console
screens following a uniform presentation strategy with color
coding to speed up interpretation. Operators can control specificactions from these consoles, such as activating the display ofdetailed DBMS messaging for inspection and diagnostics or
acknowledging a specific or a whole class of alarms to clear thescreens. Fig 4 shows an operator console unit.

doi:10.18429/JACoW-ICALEPCS1991-S02SRU04

Slurft~Realtime database

Realtime database is hosted in the µ V AX3800. It isfragmented into dedicated live databases reflecting the hardware
configuration of the frontend CAMAC or VME/VAXELN
local controllers. At these lower level locations, live databases
are eventually reformated into appropriate structures for easy
access by equipment handlers and for fast response, and reduced
for memory saving. These live databases actually include static
information ·and dynamic data about the operation of thecontrolled pieces of equipment or subsystems, under the
management of a DBserver. Downline loading of live database
may be a critical concern to be mastered.

II.4 Human interface

Human interface at GANIL integrates recent graphic
enhanced processing units, namely VS3100-7 6 workstations
and VI'l300 X-terminals, to benefit from their color graphic
high resolution capabilities and X-Window standard
compliance. It is accomplished via operator consoles,
supervision systems, and specific field graphic terminals.
Operator consoles
Operator consoles are installed in the main control room
for centralized controls and along the accelerator for field
controls and immediate interventions (e.g., the electronics
backbone gallery and the experimental physics areas).

Two control levels:

1. Elementary level for individual equipment controls, thecomputer control system acting as a sophisticated multiplexer.
This level provides utterly standardized controls for all pieces ofequipment, by turning reassignable knobs,
2. Higher level for complex and global controls involving
many different types of equipment, calculations and displays.
This. level achieves fully customized interactive controls, byrunmng tasks.

Implementation: .

Designation devices are currently trackball and mouse, totrack and catch the graphic objects (task or knob image) on thescreen of the X-Terminal.

Cofflrol Elh<m« LAN

Figure 4. Operator Console Unit

Supervision
It uses worstations VS3100 to run the commercial
software package IMAGIN supplied by SFERCA. This
supervisory system allows control of any processor which iswithin the reach of the workstations, management and displayof the collected data on animated synoptics over the backgroundview. Supervised processors are currently programmable logic
controllers (PLC) and the present control system. Imagin iscomposed of several software modules : a graphic editor, aconfigurer to create dynamic objects and an animator to perfom
real-time display. Mailboxes provide communication threads
between the animator module and the application process, aswell as access synchronization to the shared data memory pool.
PLC data acquisition is realized by the data server based on the
SFERCA subsets PROLINK+ and its industrial database BDI(Fig 5).

I
VMS

Mailboxes

I

IMAGIN Synoptic Animator

I
I
I
I
I
I

l

f

I
I
I
I
I
I

f

I
I
I
I
I
I

I Shared Dato Section
User Application

llDI (Inductrial databaae)IIn-house

l'llOLINK+
PLC data aarver.mus protocollntertaco

VllHl ( V&l< Si......,,, Hl )VOTS (Vaz OSITransport Services)

TCP/IP(VU/Ultrix
COnnact1on I

Aaynchronoua lina

&thernat 802.3&tllarnat 802.3

l\PlllL Pll400

8IllM1INll 85-13SU

Preaent
COntrol Syatu

controllers

controll era

Figure S. Supervision Structuration

S02SRU04
68

Status Reports: UpgradeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU04

Supervisory development environment is organized aroundwokstations linked to the VAX 6000-410 host processor, while
supervision is performed on workstations related to theµ VAX3800 cluster. ADA and FORTRAN application
processes are interfaced to the various SFERCA modules
through specific interfaces. Recent implementations encompass
DECwindows environment. Examples of supervision will bepresented in the following section.
Field graphic terminals
Programmable logic controllers are addressable bydedicated field terminals with attached keyboards to perform
specific actions. These devices are for use by specialists for
local inspection and expertise.

r.._.:

7. 3HHZ
DBFAUT

UllPBRATUR!

jArchlvace 11

III. FlRSTIMPLEMENTATIONS
III. I Controls of the new ECR Ion source

A new 14.5 GHz ECR ion source, named ECR4, wasinstalled on a l 00 kV platforme to increase the beam intensity
for metallic and heaviest ion species. This ECR source iscontrolled by a pair of SIEMENS S5-135U PLC. One PLC ison the high voltage platform and is linked by an optic fiberconnection to its grounded companion. The grounded PLC is
coupled to the Ethernet LAN to communicate with thesupervision system running on a VS3100 workstation. An
ADA application interfaces the IMAGIN software to animate
synoptics. The ECR4 synoptics consists of several views tohandle the RF power transmitter, to control the vacuum systemand to drive the main parameters of the ECR source like thegas pressure of the UHF power, as shown on Fig 6.

wEN u

Figure 7. Temperature of a RF Cavity Synoptic

This application is the first experience of introducing
relational database concepts into our controls environment. The
INGRES RDBMS is used to archive measurements at operator
request or in automatic mode, every 15 minutes. An off-line
application using the Windows 4th Generation Language(W4GL) from INGRES displays graphs and presents result,depending on the stored data, as shown in Fig 8. It
demonstrated the benefit that can be taken when developingwith this language. It also led us to face the sensitive
implementation of ADA/SQL interface and use of the ADA
multitasking features in this case. The whole application is
now about to be operational.

I

GAZ 2
I GAZ lHYPER I
10,00
vl.~:~~.og,g4 v lVcdlr::=::::J[!i"LJc:=:::;,oo,oov.!~i---:.

oo,57 vl.!!]f===l.00,00 v Lfilc=:::=i;----i.

£~

c~

Amfi

Figure 8. Off Une Display of a RF Cavity Temperature

111.3 Operation viewing and statistics
Figure 6. New ECR Ion Source Synoptic

III.2 Supervision of the internal temperature of the
RF cavities
The temperature of water cooling the seven RF cavities of
the accelerator are measured by the means of 34 PTl 00 probes
connected to a SIEMENS S5-135U PLC and are supervised
such as for the ECR source. In addition data related to beamcharacteristics, RF voltage and vacuum pressure are read fromthe present control system. Fig 7 shows the temperature
measurements inside the northbound RF cavity of the first
separated sector cyclotron (SSCl).

A W4GL application was written to store in an INGRES
database the chronology of the GANIL operation. According to
the screen displayed on Fig 8, the operator using a mouse has
to point to or choose various graphic objects to specify what
occurs while controlling the accelerator and the experimental
areas. Every quarter of an hour, he has to indicate time andlocation of occuring failure, as well as beam tuning conditions
and target experimental rooms. Later on, some of these manual
operations will be filled up automatically.
The other part of this application to be developed will run
on a Macintosh station. This application will read the INGRES
database through the graphic query language (GQL) product tofeed an EXCEL application for statics and report purpose. Thisapplication is planned to run by the beginaing of the next year.

S02SRU04
Status Reports: Upgrade

69

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

-

I

'

I

'
'
'I I

II

I
I

I

.. ...... ...

''8'*'''~"""

mJ
-·m:i
•CE

I

I

I

"a

I

! I_

1112-M-1991

m$c:e;:J.. u.9f ...........

•'

. ...

••

"" ti

"'
Ut at

." "''°" ......""....

I
y
I

..••'
'

UI OJ
Ut 01

" cu .. ...
UI ti&OMot•Nt"........

--...

".. "" . ...
Cit eJ

U1 H

'"
"'

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU04

to the fifteen other local control processes such as highfrequency or beam phase management.

.. .....
·-m.. ...' ... ..'-· "' "'..• . ...... .•• ••'' ....•' .'' .... l\T.l l"°"vnu..._.j'..
..........
.. ""' ...... ' .• • ..• ...'.:::".

ICALEPCS1991, Tsukuba, Japan.. "°"'".. ,_, _ _ , .. u..v,,,,,-iI

G;Jl FEun.1.E nE ROUTE II som IGJ•

Figure 9. Operation Statistics Display

/

/

L.··
............
"·' ....

-.. .. 11o•.· 1111•

I

I ..--

v

Figure 11. Beam Proftles

111.4 Beam profiler
It was important for us to validate by an example several
real time control system basis components :- Client server communication with workstations asclients and VME crates as servers.
- VME crates for the control of local pieces of equipmentwith data links to the control room workstation for display.
- The VME300 under VAXELN as crate controller.
- The DEC graphic editor VUIT to build MOTIF menus.
That was done with the beam profilers system in which
the VME crate contains the 20 acquisition slots for 160
profilers.
On the VME crate, a communication server receives therequests from the workstations, according to the different
allowed functions (gravity center, broken wires management,
full width at half maximum). There is one ADA task for eachfunction, so that simultaneous different requests can besatisfied. These functions find their data in an ADA task whichis started by an interrupt at every end of the acquisition cycle.
After that, the computed data are sent by the LAN to therequesting workstation. An ADA program on this VMS
workstation manages all the MOTIF widgets for the pop-up
menus dedicated to the operator's choice, then displays andrefreshes the graphic representation of eight beam profilers.
VAX S'l'A'l'ION /VMSl
Pecnat
Cc:municationclientR'l'VAX 300 /VAXELNI

CONCLUSIONSThe host level is fully equipped and operating as well as
the processors of the real-time control level : µVAX3800
cluster and workstations. The Ethernet LANs, to federate thethree control levels are installed and provide satisfactory
services.
Significant effort was deployed to analyze and build up thesoftware architecture.
The next step will be mainly devoted to completing the
GANI CIEL specifications and to coding the system and user
software.
The future control system is planned to run by spring
1993.
ACKNOWLEDGEMENTS
The control system described here is the result ofcontinuous and combined effort involving others members of
the Controls Group : P.de Saint Jores, E.Lemaitre, P.
Lermine, C.Maugeais, F.Regnault, J.F.Roze, and our visiting
guests: J. Galvez and G. Vega from the University of Bogota.
We benefit from discussions we continue to have with thepeople from the Electronics Group and the Operation Group of
the Accelerator Operation Sector.

Do=ot
CC-un1cat1onSarverltl.ib graphica

Gravityjllidth!Valuas

MoUf popup menu

Aoquiai tion

FURTHER READINGS- E. Lecorche and the GANIL Operation group "A New OpenGKS based Supervision System in use at GANIL" Proc. Int.
Conf. on Accelerator and Large Experimental Physics
Operator
J 8e4t1 profilers j
Control System, Vancouver, Canada, 1989
- L. David, E. Ucorche, T.T. Luong, M. Ulrich . "TheGANIL Computer Control System Renewal" Proc. Int.
Figure 10. Beam Profiler Software Structuration
Conf. EPAC'90, Nice, France, 1990
This beam profiler display application showed us that this - T.T. Luong "Real Time System for Local Intelligence"
Europhysics News 22, 1991
kind of communication is fully satisfactory and can be extended

S02SRU04
70

Status Reports: Upgrade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
trol system for a new beam line can be provided by buying aworkstation, another CAMAC controller and local interfacing hardware. The incorporation of this into the existing system is automatic (subject to the licensing agreement and an
upper limit on the number of databases).
The current operator interfaces (touch sensitive screens ,tracker balls, colour displays, knobs etc.) which are all obsolete or nearly so, will be replaced by high quality
mouse/tracker ball and keyboard driven workstation type displays.
No new system will look or behave as the old one did.
Users are familiar with the old system and will be reluctant
to change. Any shortcomings in the new system will bepicked on and amplified, shortcomings in the old systemhaving been assimilated years ago. Use of the new systemfrom a user-written program is more complex and lessflexible- we are currently developing a simple interface toimprove this..
There are three major parts to the management of change:

I. Transport of existing software.
2. Connecting to the new control system.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU05

for a live run of the new system ..

Ill. PROGRESS
Three databases have been written, those for the injector
magnets, the injector timing system and the injector general
purpose status modules- a total of 1200 channels so far.
Handlers for the programmable timing modules, the mostcomplicated of our magnet power supplies, and the status
reading hardware have been written. We are preparing a
specification for extra functions to be added to the Ethernet
CAMAC crate controller, to reduce the overheads on equipment access. Control screens for the timer modules and magnet power supplies have been prepared and a suite of hardware test programs written for test access of interface modules via the ECC controller (external to the database).
Fig. 3 shows a workstation in use in the new control system. The menu windows running around the bottom righthand comer are replacements for our existing touch screens,where further menus and/or control screens are called up.
The main part of the display is occupied by a control screen
for the quadrupoles in the Low Energy Drift Space of the
ISIS LINAC, showing control sliders and a monitoring strip
chart. Fig 4 shows the operation of the control screen for the
ISIS LINAC programmable timing system. No high level
programming was required to generate these windows.

3. Training users
Most of #1 can be done off-line, that is to say without interfering with the operation of the accelerator, and this is currently in progress.
#2 is straightforward because all equipment below the
dotted line on figure 2 is to remain the same. The CAMAC
crates which drive our MPX branches merely have to havetheir crate controllers removed and replaced with the ECC
controller modules. Changing the existing main control desk
is highly problematic. Workstations will have to be installedside by side with the old control system on the first live runs,
so that the old system can be reverted to if necessary. It must
be stressed that ISIS runs as if it were a commercial enterprise, and our "customers" will not allow scheduled run time
to be removed or interfered with for development purposes.

A significant amount of time has been spent deciding
how to modify the standard usage of the Vista software tosuit our needs and in moving to new versions. Now this has
been done, production of software should speed up.
The choice of processor platforms on which to mount thesystem is not obvious. It is driven by the need to maximise
perceived response time. We are not sure at this stage
whether workstations are more or less appropriate than apowerful multi-user VAX running several X-terminals. Increases in workstation power may overtake this problem.

There is a long shutdown period of 3 months every year
when it is expected that changes will take place.

There is a lack of flexibility in hardware calls routed
through the database, stemming from the inability to parameterize calls. One might wish to be able to retrieve the valueof a single status bit from a 16-bit status port. In the present
system, this is done by specifying the module, port and bit
number- a 0 or 1 is returned. In the new system, to be able torandomly access any single bit in this manner would require
database channels for every single bit, which would be very
wasteful. We have opted to assign an integer channel to each16-bit port, individual bit channels being set up on demand.
On the other hand, this rigidness leads to a strong "typing" of
database channels, minimising errors.

The original time scale was for a two year project, culminating in a long shutdown. This is not feasible given the current manpower levels, so April 1993 is now the target dateComplex control screens may be devised without any
programming effort, however the hierarchical control overwhich screens may be displayed at any one time seems lack-

Training of staff, given our limited resources, is difficult.
The operation of ISIS, although still to be further developed,
could be said to be stable, so a straightforward functional replacement would be an acceptable first stage.

S02SRU05
72

Status Reports: UpgradeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU05

achieved without a drop in perceived response time.

ing to us and we are devising our own software to handle
this.

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 suitability of Ethernet (or any general purpose network system) as the main i/o channel is unclear. On the one
hand emerging computer systems are frequently only supplied with an Ethernet port and moving away from this becomes expensive. It is truly distributed and configuring thesystem and expanding it become trivial. On the other hand,
the generality of the system means that it is slow. It is clearly
unsuitable for a fast data acquisition system but may be well
suited to a supervisory control system such as ours. It allows
the integration of PC's, CAMAC, VME, STEbus, and othersystems in a controlled manner. Together with distributed
software such as that described, it provides a system which iseasily reconfigurable should a processor fail. In the ECC
CAMAC controller itself there is also a large amount of untapped power although an easier way of accessing this would
be an advantage.

Quick turn round support is available from the vendors by
e-mail, phone or Fax.
On any physical Ethernet segment up to 256 CAMAC
crates (each driving up to three J\11PX branches with up to 16
J\11PX crates per branch) can be simultaneously available
from any processor with the ability to restrict access to individual modules to particular processors if required. The ECC
modules have been reliable in operation with excellent support from the manufacturers.
The major difficulty with the ECC controller is an overhead (on single operations) of lOmS per transfer. The lOmS
is a fixed feature of the VAX-Ethernet configuration and is
not affected by transfer size. In a data acquisition environment the problem starts to disappear as the blocks of datatransferred get larger. For a control system such as ours,
where accesses to the hardware are much more random andmulti-sourced, this is a large problem for which there is noclear solution as yet The advantages of the ECC solution are
the total flexibility and the overcoming of many of the limitations of CAMAC (to the extent of giving it a new lease oflife).

REFERENCES AND ACKNOWLEDGEMENTS
1.

Vista Controls Inc.
127 Eastgate Drive#30800Los Alamos, NM 87544
USA
Phone:(+1) 505 662 2484
Fax:(+l) 505 662 3956

2.

Hytec Electronics Ltd.
Ladbroke Close
WoodleyBerks
RG213YT

IV. CONCLUSIONSThe choice of commercially available software must be
correct for those establishments where lack of effort and staff
turnover are problems. Good local support and constant updating of the product are also essential, as is the ability tofeed requirements into the supplier's development plan. Evenso the effort involved in changing to a new system is always
under-estimated, both by the customer and by the supplier.

U.K.

Phone:
Fax:

No commercial product will allow the easy assimilationof an existing control system. Whatever practises and methods prevail in an operating machine are the "right" ones byvirtue of the fact that they are in use and familiar to those
who use them. Any new system must be modified to fit what
exists- not the best way to proceed. It is also clear that the
only timing information of any interest to the user are thetimes taken to (1) present the control window required on thescreen and (2) to operate a piece of hardware and see the effect on the screen, what happens underneath being irrelevant.

(+44) 734 697973(+44) 734 441068(These companies are reciprocal agents)
GEC Computers are now GPT Datasystems Ltd.

DEC, DECnet, VAXstation 3100, VT1300, VMS are registered trademarks of the Digital Equipment Corporation.
Ethernet is a registered trade mark of the Xerox Corporation.

We are happy that the new control system will meet all
our expectations with regard to extensibility, reconfigurationand communication and will perform as well as or better thanthe existing system. It seems to be an unwritten law of control systems that, as the power of the processors increases,
the complexity of the software rises until the perceived response time drops to the minimum acceptable. We would
hope that the extra complexity in the new system will be

S02SRU05
Status Reports: Upgrade

73

73

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-S02SRU05

Developmentarea, offices
GEC

SYSTEM DEVELOPMENT

4070

Injector control
Room

Main Control Room complex

Target Control
Room

GEC

GEC

GEC

GEC

4070

4085

4070

4070

CONTROLCOMPUTERSCAMAC(NETWORK,TERMINALS,ETC.)
NETWORK
CAMAC(OPERATORINTERFACE),

CAMAC(GPMPXDRIVER
MODULES)

1111 I
GENERAL PURPOSE MULTIPLEX BRANCHES, 1-3
BRANCHES PER CAMAC CRATE, 1-16 CRATES EACH

II

I

II I

INJECTOREPBSYNCHROTRONITARGET

FIGURE 1. General arrangement of present system

S02SRU05
74

Status Reports: UpgradeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU05

Main Control Room complex
4 Vaxstations + 4 X-terminals
Expandable as required.

REPEATER

Thick Ethernet

REPEATER
Thin wire
Ethernet

Injector Control
Room..-RE-P-EA_TE_R___, Target Control
Room

X-windows
terminal

X-windows
terminal

CAMAC(GPMPXDRNER
MODULES)

III

11

GENERAL PURPOSE MULTIPLEX BRANCHES, 1-3
BRANCHES PER CAMAC CRATE, 1-16 CRATES EACH

II

I

III

INJECTOREPBSYNCHROTRONITARGET

Ethernet CAMAC
crate controller
FIGURE 2. General arrangement of proposed system

S02SRU05
Status Reports: Upgrade

75

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-S02SRU05

S02SRU05
76

Figure 3: Example control screen-ISIS LINAC Low Energy Drift Space triple
Status Reports: UpgradeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU05

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

16-0CT-19911
Timer 1 - ion llOOI'Oll 11
Timer 2 - LEDS<>~Tlm<lr 3 - Beam Lon man
Tlm<lr 4 - Modulator 1
Tlmer.5- RFPhM<!tt!NI
Tlm<lr6 - MOOinlllltor2
Tl.m<lr 7 - Modulator 3
Tlm<lr I - Modulator 4
Tlm<lr Ii' - &mm Int. man

1

2

3

MS

@

0

GMS

0
0

•

FS

•

0
0

0

~

Tim..rn- toro&d~

-.J
-.J

Tlm<lr U- HEDS ehopp<W
Tlm<lr 13- Beam Int. man
Tlm<lr 14- Ten l!mer
Tlm<lr 15- ion """""9 12Tlm<lr 16- Tanlt 1 QWllll:!:Tlm<lr17- Modlin 111:212
Tlm<lr 18- Modlin 31l4 12
Tlm<lrlli'- LEDS~
Tlm<lr 20- BLM dlsptaxyTlm<lr 21- Ion toorC<> 13
Tlm<lr 22- HEDS ehopP41r
Tl.m<lr 23- HEDS chopp<1r
Tlm<lr 24- HEDS chopper

I!NORMAL I
IENAllLED

Sll&H
eontn:il0!ENABLEDI~!NORMAL

I

1181
10

S02SRU05
Status Reports: Upgrade

Figure 4: Example control screen-ISIS LINAC timers.

77

4

•
0
0

!NORMAL

1726
0

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3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

operator interface. The radiation levels are continually logged
to the PC disc. No distributed I/O (GI's) are used in thissystem, thus some 600 digital I/O signals and SO counters areconnected directly to the S99-systems, fig. 2.

consists of three parts: main control system (fig. 4), electron
cooler control (fig. S) and vacuum control.

Counters

Figure 2. The radiation protection subsystem.

In 1989 an external ECR ion source [2] was added to thecyclotron. A Siemens SS -HSU [3] PLC is used as front-end.
For operator communication a 386/PC is connected to the
PLC system by means of a Siemens CPS24 [3]communication processor, using an RS 232 channel to thePC. Most of the hardware is connected to the PLC but a few
devices are connected directly to the PC using RS232, fig. 3.

Figure 3. The ECR control subsystem.

MS-DOS was chosen as operating system for the PC,
mainly because of the large amount of inexpensive software
available for this environment and because the staff was
already familiar with this operating system. Anotheralternative would have been to use a real-time multitasking
operating system. This would probably have resulted in amore efficient system but at a higher cost. The present
solution was considered adequate since the ion source control
handles a relatively small number of parameters (<100).
The control program is written in Microsoft C. To
simplify programming, a library of process control routines
was written. This library allows creation of multiple threadsof execution within a program. Threads can communicate
through shared variables or message queues implemented in
the library. The threads are scheduled using a nonpreemptive
round robin algorithm. This eliminates the need for mutual
exclusion mechanisms when accessing shared data. Schedulingonly occurs when a thread makes a blocking call to the library(for example reading from an empty message queue). Driver
routines for the RS 232 channels are also included in thelibrary. This enables the driver to block a thread waiting for an
I/O operation to complete.

B. Storage ring
The control system of the CELSIUS ring covers allfunction generators (2S) and static power supplies (control
and/or acquisition) in the ring (about 100), a vacuum systemof the ring (4) (about 350 digital inputs/outputs plus 16
analog inputs) and the timing system. The whole system

Figure 4. Main control system of the ring.

T - terminal, C - console,
CAMAC PC, CAMAC S.C - parallel and serial crate
G64 - front-end controllers in G64 standard

Figure 5. Electrck cooler control.

The front-end level in both the main control system andthe cooler control system is based on the G64 standard. The
vacuum control is exeeuted by a programmable logic
controller (PLC). The PC in this case, connected to the PLC
via RS 232 serial line is used only as an operator console.
The PDP-11 is running under RSXll-M V4.2 operating
system and DECnet. The kernel of the control system andmany applications are written in MACR0-11 assembler.
Other application programs are written in FORTRAN andPascal. The PCs are running under MS DOS and the control
programs are coded in Turbo Pascal.. There are several databases and data base management programs. In the main
control system there is a database for static parameters, fordynamic parameters (vector tables) and for the timing system.
The cooler control system has its own data base. AU thesedata bases have different structure and contains various fields
needed for the control tasks. The operator interface is also
different for each system. The main control system have aconsole with a touch screen, numerical keypad, knobs and asemigraphical color display. The touch screen menus have atree structure with 16 buttons on one page. The buttons canbe used to pick up the parameter for control, to start anapplication program or to choose another page. A number ofapplication programs have a text oriented user interface and arerun directly from the terminal. The user interface of theelectron cooler is based entirely on the PC working in the text
mode. The operator can display up to 20 parameters on thescreen. The absolute and incremental control is possible fromthe keyboard. Commands to the control programs are invokedby the function keys. The vacuum control system has agraphical user interface. The status of the vacuum system is

S02SRU06
Status Reports: Upgrade

79

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

Digital 1/0

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU06

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

presented on the screen with dynamic symbols (changing color
or/and shape) on top of the static picture. The operator
communicates with the system with use of dialogue boxes,
buttons, text input fields etc.

electron cooler between injection energy and flat top energy.
The switching will be triggered by external pulses from thetiming system.
The changes in the hardware of the next level - local
process computers, will be more significant The S99 systems
in the cyclotron control will be replaced by a VME system. A
Force CPU-30 [5] will be used as local controller. Due to thelarge installation base of the GI-controllers they will be kept
in the upgraded system. A new version of the GIcommunication bus interface, adapted to the VME-bus, haveto be manufactured in-house. RS 232 and Ethernet interface
are included on the CPU-board. All PCs will be supportea
with the Ehternet controllers. An upgrade of some PCs basedon the 80286 processor to 80386 with at least 2 MB RAM is

3. UPGRADED CONTROL SYSTEM
A.Hardware
The hardware configuration of the upgraded control system
is presented in figure 6. All control computers will beconnected to a segment of the Ethernet which is isolated by a
LAN bridge from the university network. A repeater must be
used because of segment length limit. The front-end level ofthe control system will not be changed with an exception of alimited number of low level controllers which should enableswitching between several control values synchronously withthe ring acceleration cycle. This modification is going tosupport beam sharing between the storage ring and othercyclotron users as well as switching the settings of thenecessary.
The radiation protection system will keep the S99 system
as hardware interface since extensive rewiring will otherwise
be required.

Operating system on the PC's:
PC DOS.
Operating system on the work stations: UNIX & X-windows.

PC (386)

PC (386)

El.ECTA:N

CEl..SIUS

ccam

VACUUM

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU06

CAMAC

Spare 216 MB RAM
Swapping disk
1g• color screen

POP 11n3
OS: RSX-11M &DECns!

Thin Wire Ethernet
Protocols: DECnet & TCP/IP
Spare 232 MB RAM

•1GBDISK
Backup Tape19" color screen

Spare 216 MB RAM
Swapping disk
19" color screenprotection

Injection

Repeater

Ion aource"Public" Ethernet (Thin)

Figure 6. The layout of the upgraded control system.

An additional external polarized ion source [6] will be installedin the beginning of 1992. The ion source is bought as a "turnkey" system including control system from Balzers/Pfeiffer. It
uses a Siemens S5-135U [7] PLC as front-end and a 286/PC
for operator communication.
The top level (user interface) will be based on Sun Spare 2
workstations equipped with 19 inch color screens. We assume
that the mouse and the keyboard will support satisfactory
operator interface.

B. Software
The main effort in upgrading the control system lies in thesoftware. Our strategy is to preserve as much of existing
invesunent in the control software as possible. However, aconsiderable part of the programs will have to be rewritten or
moved to another platform. Most of the programs on theworkstation must be written from scratch. We have chosen
TCP/IP as a communication protocol between theworkstations, PCs and VME system. For communication
with the PDP-11 we will use DECnet

S02SRU06
80

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 VME system will run the VxWorksl real time
operating system. The data base will be similar to the ECR
ion source data base structure, with the addition of support for
multiple control values to a parameter to enable "beamsharing". VxWorks is a "UNIX like" operating system. Thismeans that program modules can be written and roughly
debugged on the UNIX workstation, then recompiled andloaded in the target system.
To minimize the use of the poor software development
environment in the S99 system, the radiation protection
control program will be moved from S99 to PC level. The
S99 will only be used for transfering the system I/O image
between the PC and the actual hardware. The I/O image
mapping server in the S99 will be unaware of the PC
application program structure , thus enabling changes in theapplication without modifying the S99 software.
The programs running on the PC will be modified in sucha way that they will be able to get requests from the networkand send replies to the callers. The socket interface will be
used. The network software we use (PC{fCP for DOS) can
support up to about 20 open TCP connections. Most of theconnections will be used by application programs and one isreserved for alarm and warning channel to the alarm server on
the workstation. The existing programs should still perform
all functions as without the network interface. This should
allow to gradually move control from the PC to theworkstations when the relevant programs on the workstation
will be ready and thoroughly tested. We plan to use the samecommunication procedures and algorithms on all PCs. The
programs written in Turbo Pascal will be rewritten to MS
Pascal to enable easy linking to the PC{fCP network library.
The polarized ion source uses Wizcon [8], a commercial
control system software package. This product have built insupport for remote control nodes, using the Netbios
communication protocol. This will present a problem since
the control system network uses only TCP/IP and DECnet.
The data-base in the workstation will contain only
information needed by the application program to access theparameter. All low level internal characteristics will be hidden
to the application. There will be no global "life" data basewith all parameters continually updated on the workstation.
The application programs will get this information from thelower levels on request. The alarm server will listen to theinformation coming from the different nodes and inform theuser of possible problems. This task should also check if allnodes are alive.
We will use SL-GMS [9] as a tool for creating the userinterface. The GMS is a software tool kit for building
dynamic graphical 2D man-machine interfaces. It was chosen
mainly because its flexibility and good compatibility with theX environment.

of the high level data base and communication protocols. The
first program which we plan to write is a synoptic program
which will show the status of any part of the accelerators andenable to control selected parameters. Next the application
programs from the PDP-11 running on the console will be
moved to the workstation. At the same time the work on
moving the main cyclotron control to the VME standard will
start. The programming and testing will be done on adevelopment system not connected to the cyclotron. After
positive tests the system will be installed on the target VME
system. The alarm server, the archive program must also be
written as soon as possible. As a last step ·we consider tomove most of the application programs running on the PDP
to the workstation. Most of them are terminal oriented, so in
the transition period we can run them in the terminal
emulation window.
The main problem we have to face in upgrading thecontrol system is the incompatibility of existing data bases.
This we plan to overcome by creating the new, high level database for the programs running on the workstation, common
for all parameters independently of their physical location.
Another problem we meet is the limited pool size in the
RSX-11 operating system. This limits the number of tasks
which can run on the PDP and special attention must be paid
to programming network servers, allowing only one instanceof the task. We expect some problems with the RAM size
limit imposed by the MS DOS, especially if we would like tokeep all the functionality of the existing programs running on
the PCs.

5. REFERENCES[l] S. Holm, Proc. Int. Conf. on Cyclotrons and their
Applications, West Berlin, May 8-12, 1989
[2] C. Ekstr6m et al. "Status of the ECR ion source at theUppsala cyclotron", 4th Int. Conf. on Ion Sources,
Bensheim, Germany, 1991. (To be published in Rev. Sci.
Instr.)[3] S5-115U Programmable Controllers, Siemens Catalogue ST
52.3.
[4] K. Gajewski, 'The Vacuum Interlock System for the
CELSIUS Ring", Nucl. lnstr. and Meth. in Phys. Res. A293,
1990, pp. 183-186[S] CPU-30, Force computer hardware data book 1991.
[6] C. Ekstr6m et al. "External Ion Sources at the Uppsala
cyclotron", Rev. Sci. Instr. 61 (1990), pp.628-630[7] SS-135U Programmable Controllers, Siemens Catalogue ST
54.1.
[8] Wizcon, PC Soft International, Wizcon User Manual 2.1[9] D.G. Shelef, "Developing Graphics in Realtime", SunTech
Journal, Vol. 3 No 3, pp. 64-74, July/August 1990

4. SUMMARY

The work on upgrading the control system has begun
about 6 month ago. During this time the requirements for the
new hardware and software were specified. We stressed thenecessity of using commercial, wide spread and well supported
hardware and software. Most of the hardware is already in placeor ordered. All computers have been connected to the Ethernet
and some tests with the network communication programs
have been performed. At the moment we work on the structure
1 VxWorl.G is a trademark of Wind River Systems, Inc.

S02SRU06
Status Reports: Upgrade

81

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-S02SRU06

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

ture is shown in figure 1. The new added VAX-II computer is used as a. intelligent node dedicated to the power
supply control. The current VAX-11/750 also is a. intelligent node which ma.inly is used for other subsystems, suchas BPM, RF, VACuum. In the first phase, we will still
use the current human-machine interface as the system
console. In the second phase, we will add another DECWS as upgrade system console which can utilise fully therich DECwindow's software functions and make the multidisplay for improving the environment of human-machineinterface. Some of the jobs involved a. lot of calculation
will be moved to the D EC-WS. These three nodes will be
networked into a. individual local network which is linked
to current IHEP DECnet via. a. network bridge.

collider operation can keep continuously due to the power
supply still be controlled by the VAX-II machine.

WORK

LATI1CESTATION

MODEL

4. The upgrade of BEPC control softwaresystemThe upgrade work of the control system is ma.inly focused on the software side, the block diagram of system
software upgrade is shown in figure 2, which can be divided into the following three parts:
1. Creating new control software system for power sup-ply control on the VAX-II.

2. Remoulding the current controlsoftwa.re on the V.AX11/750.
3. Coordinating the relations between VAX-II, VAX11/750 and DEC-WS for integrating whole distributed

control system.
PSRAMP r--~-..,PSCCTRL
QXJ922
SSCHDI .._,.----,..--'LDBSNDCURMON .-----'--~BPM
DPMSNDLOB PRRFSYS
VACUUM
ETCCTCSSOID2
XCAMAC

VAX-<il30
COMPUTERCENTER

Figure 1. The upgrade of BEPC control systemb. Adopting Q-bus CAMAC adaptor

In the current system, a.ll the datum are passing throughthe VCC, one QIO of VMS for VCC need about 20 ms at
lea.st and obviously reduce the processing speed of wholesystem. Beside the VCC adaptor is an old SLAC dedicated product, not a commercial module. Therefore, we
adopt the Kinetic Systems Corporation's KSC 2922 and3922 commercial modules a.s the VAX-II CAMAC adaptor. Under the support of KSC's, a. VAX QIO operation
only takes 3 ms in 1,000 words under the VMS, it would
overcome the bottle-neck of the VCC and a.lso increase thesystem reliability.
c. The compatibllty on new and old system

For keeping the compatiblity of CAMAC system, we are
not going to do any modification on the hardware below
the CAMAC system crates as far as possible. Thus after
the upgrade is completed, the current control system on
the VAX-11/750 can become the backup on Micro VAXII. Conversely, if VAX-11/750 computer is out of work, theFigure 2. The upgrade of BEPC control software systema. Upgrading proceduresFirst, we copy and modify a second set of BEPC control software system and its VMS opera.ting environmenton the VAX-II machine, and also modify and create thereal time database (DB) on the VAX-II a.nd DEC-WS a.s
like a.s on VAX-11/750. Under such arrangement, we ca.nreuse same panel files and all of the current application
programs, reduce the software work to minimum and keep
all the operator procedure as before.
We need to develope some communication programs forexchanging the necessary messages between three nodes on

S02SRU07
Status Reports: Upgrade

83

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

CONSOLEr - - - - - . ORBIT

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU07

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, Japanthe DECnet. These programs a.re: a.) The schedule communicating program - - used for transferring the schedule control and processing message (as position coordinateof touch panel or cursor on DEC-WS later, knob datumetc.) of console node (either VAX-11/750 or the DEC-WS
later) to other process nodes. b.) The power supply DB refreshing program - - the real time DB of power supply is
resided on VAX-II, this program is used to send and receive
all of the power supply DB parameters form VAX-II to theconsole computer for refreshing the DB on the console nodecontinuously in 1 time/second rate. c.) Other communicating programs - - used for transferring the control andthe relative information of BPM, RF and VAC subsystem
between VAX-11/750 to VAX-II and DEC-WS.
We prepare to use the DEC GKS graphic packets or
the UGS graphic system of SLAC to upgrade the current
graphic programs. In order to remain and keep the current operating environment for operator and reuse all of
the application programs, we want to save all the previous
subroutine names and only change the contents from oldgraphic program to new upgrading graphic program.
According to our current upgrading police, we still wantto keep and save all the current programs on each node.
Therefore, we introduce a "Pseudo-Subroutine Method"(PSM) in the programs, i.e., if one process is needed tobe activated, only the process resided on the active nodeis functioned, the same process on other nodes keep quiet
without any activity. This PSM can reduce the upgrade
work a.mount and short the upgrading time. Of course, itwill introduce some disadvantages, such a.s, occupy somememory resource etc, which will be considered to improve
it at later.
During the second step, when the DEC-WS will be usedas the system console, we will transfer some application
programs used for modelling-based control, such a.s Lattice, Modelling and Orbit correction processes to the DECWS later. Thus we can construct our minimum distributed
system architecture under our tight budget condition andestablish a basic distributed system environment for later
development.

and commands procedures concerned with BEPC application system resulting to optimize the environmentof the upgrading control software; We have created thereal time database and have debugged all of the DB utilities on VAX-II; Now, the process and subtask can besubmitted and activated by the schedule (SSCHD1) process through calling the panel files which is same a.s on
the VAX-11/750 while we touch the current touch-screen;
When the BPM process on the VAX-11/750 is once activated, the BPM buttons datum can be acquired individully
by CAMSAMRD program instead of the XCAMAC. The
BPM process also calls BPMSND program to active theremote process BPMRP on VAX-II and send the latest
BPM datum to it via the DECnet, thus the BPMRP refreshs the BPM area of DB; The status and para.meters
communicating process of power supply and the graphic
program substitution which is based on the work station
also got some progresses.

b. Some progresses at present

So far, we have got some progresses in the upgrade ofsoftware on the VAX-II during this summer shutdown of
BEPC. In order to run the BEPC control software on the
VAX-II, we have modified and changed some parameters

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU07

Acknowledgements
This upgrade project is based on the proposal which ispresented by prof. Shi-Yao Liu in 1988, and supported by
IHEP and I&C division. The collegues of the control groupmake their efforts for this upgrade now.

References[1] Shi-Yao Liu and BEPC control group, BEPC
computer Control System, presented at "Proceedingof the 14th International Conference High Energy
Accelerators", August 22-26, 1989, Tsukuba, Japan.
Page 899.
[2] Shi-Yao Liu, Accelerator Control for Beijing Electron
Ring and Its Experience, presented at "The 14th
HiSOR Meeting", Hiroshima. University, Japan,
March 5-6, 1990
[3] S.Howry etc. Portable data.base driven control system
for SPEAR, Report on 1985 particle accelerator
conference, Vancouver, B.C., Canada[4] R. Appa.laraju and Robert T. Cleary, VAX-Based
Realtime data. acquisition for Scientific Measurements
application, Report, NSS, Orlando, Florida, Nov 9-11,
1988

S02SRU07
84

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

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 Publishing

Accelerators are operated through six identical operator's
consoles which consists of two high-resolution color
graphic CRT tenninals and a pair of touch panels and a
VTlOO tenninal used for a program development
In the TRISTAN control system, the NODAL system
was chosen as an application environment of the system.
NODAL, a multi-computer language devised at CERi.7'l
SPS, has been implemented on HIDIC 80's withenhancements such as a fast execution speed, a dynamic
linkage scheme for external subroutines, etc. NODAL has
multi-computer commands which enable us to transmit
NODAL program from an operational computer to a
device-control computer through the network and execute
it on the device-control computer. All high levelapplication programs are coded in NODAL and low level
subroutines called as the data module are written by the
PCL language that is the FORTRAN like language on
HIDIC.

department wrote all application programs, and thenumber of programs has been increased.
Using this kind of relationship to the company, we
could build the high quality control system in the shortperiod with small number of staffs. The staff could
concentrate on the application program development.
But it results in the single vendor system and the low
degree of standardization, for example the system uses
special network and special PCL language so that it
causes a problem when we try to add the new technology
to the system.
The new system should have high reliability, highflexibility, high maintainability, high performance, highextendibility, real time response and at the same time it isimportant to use multi vendor computers and the standard
network protocol. In order to establish this system, thesystem should be simple and well modularized from thepoint of view of hardware and software.

doi:10.18429/JACoW-ICALEPCS1991-S02SRU08

The system ·architecture

3.The plans or rejuvenation of the control
systemThe basic design of current control system was madeby KEK and built by the company in the beginning of
1980's. Since there weren't any good standard products inthat time, the proprietary system was built using theirown network and process computers. And they developed
software tools under their special environment. For
example, NODAL is developed using PCL language.
This is one of the typical case to build the control systemin the industry.

The current system consists of two layers. One is thefront end layer which is composed of about three thousandof CAMAC modules. And the other is composed of
consoles and process computers.
The first step of the system rejuvenation does not touch
the front end layer at all, so that only the computing
environment will be replaced.
,
The distributed CPU's and the data base can provide /high flexibility and high extendibility.

lCon~! path

.

"'
"'

D--

Monioor path'

Unix workstation

0 - - VMS or Real Time unix workstation

Fig 2 (B) : The possible new control system for
TRISTAN using V:tvfE modules.

Fig 2 (A) : The possible new control system for
TRISTAN using the real time process computers

Some of the industries order the other company tomake full control system which includes their special
application programs. Once their system was established,
there is no change in the application program. People in
the industry only takes care of 'Tum Key Operation·.
The difference between our control system construction
and that of industry is that people in the accelerator

The discussion points are how to link these CPU's andhow to handle the real time processes. The systemarchitecture should be simple and the status of each CPU
can be seen easily from operator consoles. From thepoint of this view, the number of hierarchy in the depth
direction of the multi-computer system has to beminimized.

S02SRU08
86

Status Reports: Upgrade86

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The real time response

The monitor path can be separated from the path fordevice control. ( Fig 3 ) The real time response isnecessary for only the path of the device control. As
same as the current system, the accumulator ring and themain ring can be modularized. It is also possible tomodularize the system due to the function of each system,
such as vacuum control, RF control, magnet control.

In order to get high perfonnance in the reasonable price,
Unix workstations and VME modules are good candidates
as components of the system. Since a Unix workstation
does not have real time response, we have to prepare thereal ti.me system using VME modules or special real timeprocess computers that are not well standardized yet Two
examples of the real time system are described in Fig. 2(A) and Fig. 2 (B). Fig 2 (B)system uses VME
modules connected to the Unix workstation to proceed thereal time task. All processes that need real time response
should be taken care at the VME level, so that thecommunication between operational consoles andworkstations for the hardware equipment control is notnecessary to be a token ring which has a reai time
response.
On the other hand, Fig 2 (A) uses real time Unix orv.MS workstations to control real time processes. Since
real time Unix and VMS workstations are vendor
dependent, the system that deals with real time processes
has to be minimized for the 'future update of the system.
And these real time computers must be linked with atoken type network such as FDDI.

The modularization or the software system
The modularization of software is very important torejuvenate the system and also important for the object
oriented programing. The discussion in this context basedon the four levels of control process.

Level 0 : The interface against operator. It must be
possible to generalize the action of operators, such as'select menu', 'input number', 'display data'.
Level 1 : The programs of this level should be
written as the words of accelerator operation. For
example, 'Measure Closed Orbit Distortion'. 'Accelerate
the particles','Change tune'.
Level 2 : The programs of this level are discussed as
the protocol of the magnet or beam instrumentation
operation, etc [5]. The objects of this level are theequipment of an accelerator such as a magnet, a vacuum
pump, etc. And there should not depend on the sort of
hardware interface, i.e. CAMAC or VME.

The software development
The environment of software development is one of the
key of successful system. The language should beavailable in the standard workstation. And programs haveto be written easily. NODAL and Object oriented
programing are good candidates. We should think about
the usage of the commercial software package to save thetime.

Level 3 : For a while, CAMAC has to be used for
device control. All CAMAC actions should be defined inthis level. When we want to replace some of the
CAMAC modules to VME or other hardware modules,
the software modification should be done in this level
only. The codes should be put in a object library for eachhardware individually so that it can be possible to update
each hardware control system independently.

4.The modularization of the system
When we rejuvenate the control system, the key of the
rejuvenation is modularization, because they have to be
replaced step by step. In this section, the possible
modularization with respect to both the hardware and thesoftware is described.

Objecterator

The modularization of the hardware system

Level 0Menu Items

There are some possibilities in the hardware
modularization.

Level 1Thew°'dsof
beam oper11t!oo

Level 2an :u:celen!°'Level3

CAM AC

Hardware l\tiodularization
Monitoring

Control-f-f

Has to be written
as Word.sot
Accelerator

Component o(Call CA."dAC

FunctionsVacuum Monitor
Beam Monitor

Alarm Monitor
Fig 4 : The software modularization in the object
oriented programing for the accelerator control

Magnet Control

RF Control
Beam Transport

In each level, the object can be defined easily in theobject oriented programing. Since they are wellmodularized, if CAMAC is replaced by other front end
modules, such as VME, the software rejuvenation can bedone easily. There must be no effect in level 0 - 2. And
S02SRU08

TimingFig.3 Separation of monitor path and control path

Status Reports: Upgrade

87
87

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

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, Japanthe part of the programs in level 0 - 2 can be shared in the
different accelerators, for example B-factory and the main
ring synchrotron radiation project

the gate way. For a while, both old and new operational
consoles must be available. Then hardware processcomputers can be replaced one by one.
There are several options of this replacement. For
example, 1: replace monitoring path such as a vacuum
monitoring system, an alarm system first, then replace
control path such as a RF control system, a magnet
control system.
·
Actually there have already existed the independent RF
control system composed of VAX workstations for taking
care of aging of RF cavities. The system can be available
for the system replacement.
Another method is 2: replace process computers foraccumulator ring operation first, then replace that of main
ring operation.

S.The

transition

to

the

new

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU08

generation

control system

We have just started rejuvenating our control system.
Three Unix workstations are installed and we start
including them for our accelerator control. One
workstation is going to be used to communicate with thelinac control system. Since the current control system
can not control Iinac parameters, such as the beamenergy, the beam position of the injection line, it will be
used to monitor and control some of the linear acceierator
parameters and at the same time it sends some
informations of TRISTAN ring to their control system.
The other workstation will be used to do simulations foran accelerator control. The current control system has
used PETROK that is the program for the computation of
the closed orbit distortion correction (6]. And recently
associating with the implementation of thesuperconducting Q-magnet, the SAD (Strategic
Accelerator Design) which is the set of programs for
simulation and optics matching, started to be used veryfrequently for the TRISTAN accelerator control (7]. The
SAD programs are developed for accelerator design in
KEK accelerator department. All programs are developedin the main frame: Hitachi HITAC. But the recent drastic
improvement of the calculation speed of workstation
make it possible to run the simulation in the private
workstation. Since the current control system does notsupport standard network, the project to transfer the datafrom the current control system to the new installed
workstation through CAMAC has just been started.
Because the current process minicomputers are 16 bit
machine, the lack of memory causes some troubles.
The graphics has critical problems, so that it will be
replaced by the graphics on workstations. In order toremove the current graphic system, the current softwarecodes also must be available in the new workstations
until all graphic programs are rewritten. The current
graphic system "HIDIC 80-RS232-Graphics controllerCRT" , will be replaced by "HIDIC 80-RS232-Xwindow
in the workstation"
The new functions for the accelerator control, such as
the real time tune monitor, is going to be constructedwith the graphics in the workstations
The possible system in the transition stages

There are several possibilities of the systemrejuvenation. One possibility is to install another crate
controller into each CAMAC crate so that two
independent system can exist until the new system iscompleted. In any case, the replacement must be done
step by step. The biggest change will be network
support, unfortunatly at this point, the step by step
replacement is impossible. Since the number of programsfor man-machine interface are much more than that ofhardware control, one possibility is to replace operational
consoles with new network system in the early statge,
and connect the new system and the old system throughS02SRU08

88

These hardware replacement has to be done together
with the software emulations. But the software
replacement is more complicated. One of the approach is
to try to borrow NODAL program coded in C language
from CERN. But even in such a case, all data module
subroutines coded in PCL language have to be rewritten
in C.
6.Conclusions
The rejuvenation of the TRISTAN control system has
been just started to satisfy the increased requirements fromcomplex operation of the accelerator. The Unirworkstations and VME's are good candidates as acomponent of the new system, and some of them havealready been added in the current system. The several
R&D 's are underdevelopment in both hardware andsoftware. We are going to choose one of the bestsolutions, but the basic ideas are
1: Use standards and make the open system. 2:
Modularize the system and replace them step by step.
3:Use a commercial products to save a time andconcentrate on the application program development.
References(lJ S.Kurokawa et al., Nucl. Instr. and Meth. A247
(1986) 29(2J H.Ikeda et al., IEEE Trans. Nucl. Sci. NS-28 No.3
(1981) 2359
[3] S.Kamada et. al.. KEK Preprint 91-76 (1991)[4] E.Kikutani et. al., The 6th Symp. on Accelerator
Science and Technology. (1987] 236[5] R.Bailey et al., Nucl. Instr. and Meth. A293 (1990)
332(6] PETROK is KEK version of PETROS which isdeveloped at DESY.
[7] K.Oide, Nucl. Instr. and Meth. A276 (1989) 427

Status Reports: Upgrade88

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

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

have decided to use TCP/IP, even on VMS operating systems
where the DECnet protocol is available.
We have developed programs which test the basic
communication capabilities of TCP/IP, which proved capableof running on more thari 15 different computer/operating
system architectures without any modifications to the source
codes. Perfonnance measurements were also carried out withthese programs, and a part of the results is shown in (4). The
round-trip response time of the typical workstations over the
Ethernet is about a millisecond, which is appropriate for acontrol network.
For the network media we utilize Ethernet (IEEE 802.3)
since its components are commercially available and cheap.
We know that the CSMA/CD mechanism of Ethernet is lesseffective, compared with token passing. However, we canmake use of it up to 5 M bit/s, which is adequate for ourcurrent needs. It is possible to replace the main network partin the future, without any modifications to our software, with
FDDI network system, which provides a band width of 100 M
bit/s and token ring network access mechanism.

In order to communicate with local device controllers wecontinue to utilize fiber optic in-house local networks (Loop2,3) for some time, since there exists about 300
microcomputer-based device controllers (5). The VME
modules for the Loop-2,3 network system and its associatedsoftware are under development. Newly designed device
controllers may use VME systems and communicate directly
to the main network.

B. Unix Operating System
Unix is not presently a real-time computer operating
system. However, except for full priority scheduling, mostreal-time features have already been implemented into many
Unix operating systems. At least the current Unix systems canhave a better real-time response than the real-time computers
existing 10 years ago. Synchronization between processes canbe possible in a millisecond if the processes are locked on
memory; it took about 10 milliseconds to switch between
processes on the old minicomputers. It should be noted that
the POSIX (IEEE Pl003) for Unix standardization tries toinclude real-time capabilities.
The system call incompatibility between Unix systems
from many venders, especially between BSD-based andSystem-V-based Unix systems, could cause some troubles.
However, most of our software can be easily ported, since wetried not to use any unusual system calls. We currently
develop software mostly on DecStation 5000's in the control
system and SparcStation 1 on the laboratory network. We
also use the Mitsubishi's MX3000II for the gateway between
the old and new network systems, as described below.

C. VME Front End
In the old system one subcontrol station comprises a
minicomputer and a CAMAC crate. Since we have only a few
kinds of CAMAC modules and the VME bus standard (IEEE1014) is widely accepted, we will replace the subcontrol
stations with VME-bus-based systems.
The OS9 operating systems and MC 68030 processors
drive the VME systems. We have already finished examining
the TCP/IP communication capability. We made the same
network software to run on Unix and VME-based systems.
The results satisfied our purpose.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU09

III. ARCHITECTURE
A. General Network Service
We are using some general network services, which
includes: (a) time synchronization, (b) file sharing, (c) printersharing, (d) computer and network status monitoring, (e)relational database access, (f) logging message distribution,and (g) name services. These mechanisms are achieved
without any effort by using standard network protocols.
Currently, ntp (network time protocol) is employed on theUnix operating systems and VMS systems for timesynchronization (6). Modifications to the source codes wereneeded on the System-V-based Unix systems. With ntp, thetime difference between computers is regulated using astatistical method; under nonnal operation it remains at about
several milliseconds. This is very important under adistributed environment, where common resources are shared
between many processes on the network, in order to keep
consistent infonnation.
The NFS service provides a homogeneous disk file systemaccess over the network. The components of operating
systems are shared as well as the control system databases andsystem development environments. Recently, computerequipment has become very reliable. However, hard disks caneasily fail and data cannot be saved after crashing. It is thus
important to reduce the number of hard disks as well as tosave the contents frequently. We intend to run most VMEbased machines and some workstations using NFS without
local disks.

B. Message Exchange Controls
Since the old system runs based on control message
exchange (2), in the new control system it must be supported
in order to keep the old software running. The old control
messages depend on the physical structure of the network
connection and the characteristics of the associated equipment
or service. In order to adopt control messages to the newcontrol system we have also developed a suite of new control
messages with more realistic symbolic messages and objectoriented concepts (4). We have already developed a messageconversion process between old and new fonnats.

C. Servers
In the old system although many processes are loaded onto
the main console station., the number of processes running on

S02SRU09
90

Status Reports: Upgradethe station is limited. It is thus difficult to expand the control
system functionality. On the new system we should make thecontrol software independent of the number of control
workstations.
The response time measurement mentioned above suggeststhat the processes on a main console station can be distributed
among many workstations, since the response time between
the processes on the new network system is much faster thanthat on the same old main station.
In order to distribute the control processes, we should
develop several processing servers which would function as
an operating system on the control network. These servers
should include: (a) a static database server, which would
provide characteristics of equipment and services, and (b) adynamic database server, which would distribute live
accelerator status. These services need some cachingmechanism on each computer. We should also provide: (c) alocking server, which could carry out resource management,(d) an alarm server, and (e) a communication server, which
could manage communication to other accelerators or
facilities. With these server processes the network system
would act as one computer.

D. Surveillance and Diagnosis
We have realized that under normal accelerator operation
the status and fault surveillance system is important for
maintaining stable operation [7]. The purpose of the control
system is to operate the objects based on some physicalmodels. These models should be performed in the control
processes. However, it is always possible that the equipment
or software may fail. Surveillance processes should detect
any failure and alarm the operators. The database information
servers and alarm servers described above would help theseprocesses. Preferably, fault recovery should follow fault
detection with a diagnostic system.
Currently, most surveillance tasks depends on humanoperators. We thus need some simple method to describe theconditions. Otherwise, we must put complicated surveillance
description into the software. Object-oriented software
techniques will aid the in development to some extent. We
also intend to utilize rule-based real-time expert systems.

E. Remote Procedure Calls
Although we are now developing control software basedon message exchanges, we are also considering using themechanism of remote procedure calls (RPC) in order toimprove the efficiency of the system and application software
production. We implemented the NCJRPC system of CERN's[8] and RPC of Sun Micro System's into DecStations and a
SparcStation, which gives good results. With some
improvements for software development environment andasynchronous RPC, we will use the RPC in near future.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU09

A. Condition
The operation of the accelerator doesn't allow us long
shutdown periods of the control system. We must therefore
replace the system components gradually.
The original system comprised 6 components as alreadydescribed: (a) two minicomputers as the main console stations,(b) six minicomputers as the subcontrol stations, (c) a fiberoptic proprietary network between minicomputers, (d)hundreds of microcomputers for local device controllers, (e)about twenty fiber-optic in-house local networks, and (f) an
operator's console subsystem of personal computers [9}. We
will replace the first three components during the first stage.
Then others will be improved.

B. Gateway Between Old and New Systems
Since it's risky to completely replace the systemcomponents all at once, we have built a control message andstatus information gateway between the old and new systems[2}. The gateway comprises software on the old and newcomputers which transfer information through parallelinterconnections. Messages can be transmitted from the new
network system to the old system, and vice versa, withoutworrying about gateway software.
Several application programs, such as equipment statussurveillance which was limited in the old system, work fineover the gateway. The message-transfer scheme was also abasic concept in the old system; thus many old applications
can be moved to the new system.
We are currently developing software for the new systemusing this gateway. Although the response time on the old
network side is large, the new software should well simulate
the new system
We have no control computer networks to the TRISTAN
control system. However, we need to communicate with eachother for better operation. These systems will be connected
through the TCP/IP network during this year. Using TCP/IP
protocols, message-packet routing, as well as its limitation, ispossible without using any additional software.

C. Main Control Workstations, Subcontrol
Stations and Main Network
Since the original main network is a proprietary for old
minicomputers, we cannot install these three separately.
However it is not too difficult since the gateway systemdescribed above is already installed. We will first change theroute of messages to the Loop-3 networks into new system.
After that, the route to the Loop-2 networks will be switched.
The physical connection and message flow will switch as
shown in figure 1. The replacement is scheduled to take placeover a period of two years.

IV. SCHEDULE

S02SRU09
Status Reports: Upgrade

91

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, Japanthat may be the first case to have new local controllers which
are connected directly to the main network.
For the operator's console, a personal-computer-based
system which enables frequent modifications, is utilized.
However, the connection to its gateway personal computer is a
serial link, and the new functionality on the new control
system cannot be utilized from that system. We are thus
presently developing some console functions on X-Window.
The application development environment has improved muchusing various window toolkits and widgets. We will utilize
Motif widgets for application programs. Some simple
applications has been developed and an X display will be
installed into the operator's console room during the next year.

Workstation GroupNew Network
Gateway
Main Console Station
Old Main Network

[OLD]

[NEW]

Loop-2,3 Network

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU09

V. CONCLUSION

Device Controller

Figure 1. Transition of the system connection and thecontrol message flow from the old system to the new system.
Later, the network traffic will increase since we share it
also for software development. We will thus separate the
network into two parts: a network for subcontrol stations and a
network for main control stations. It is also possible toreplace the latter with an FDDI network, which is more
efficient, employing token ring network access mechanism.
111e total system is shown in figure 2.
Operation and Display

An upgrade scheme of the linac control system wasinvestigated and we have obtained good results so far. Using
international and de facto standards, the upgrade has becomemuch simple and we need not rely on any single company.
This is important in small accelerator control systems, as inour case.

VI. ACKNOWLEDGEMENT
The authors wish to thank Professor A. Asami for his
support during this work. They also would like to thank thestaff and operators of the linac for their valuable discussions
during the system design and development. One of theauthors (K.F) is grateful to Dr. K. Kostro who allowed him to
use the NC/RPC code of CERN.

Communication

File Server

Alarm Server
D/namic

Time ServerVII. REFERENCES

Database Server

Locking Server

StaticRelational[l] K. Nakahara, I. Abe, A. Enomoto, Y. Otake and T.
Urano, Nucl. Instr. and Meth. A247 (1986) 153.
[2] K. Furukawa, N. Karnikubota, K. Nakahara and I. Abe,
Nucl. Instr. and Meth. A293 (1990) 16.
[3) I. Abe,, M. Kitamura and K. Nakahara, "Network

Dal abase Server

Database Server

Network

communication libraries for the next control system of
the KEK e-/e+ linac", this conference.
[4] N. Kamikubota, K Furukawa, K Nakahara and I. Abe,
"A diagnostic expert system in PF linac control", thisconference.
[5] For example, T. Shidara, R. P. Bissonnette, K.
Nakahara and S. Asami, Nucl. Instr. and Meth. A245
(1986) 500.
[6] D. L. Mills, DARPA Network Working Group Report
RFC-1129 (1989).
(7] K. Furukawa, N. Kamikubota, T. Shidara, K Nakahara
and G. Horikoshi, Part. Accel., 29 (1990) 245.
[8] P. S. Anderssen, V. Frammery and R. Wilcke, Nucl.
Instr. and Meth. A293 (1990) 225.
K. Kostro, private communication.
[9] K. Nakahara, I. Abe, K Furukawa and N. Kamikubota,
Nucl. Instr. and Meth. A293 (1990) 446.

Control and Communication
Network
Message Protocol
Converter

RPC Server

Device Controller
Figure 2. Logical structure of the new 1inac control system.

D. Further Improvements
Although we continue to use the old microprocessor-based
local device controllers, for the new kinds of equipment wewill utilize VME-based local controllers. During the next year
we will obtain several pieces of new accelerator equipment,

S02SRU09
92

Status Reports: Upgrade

92

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, Japanis I inked with the loca I area neti;ork which is in the
TARN2 and eye l otron areas. Our network is a Iso I inked
with 'INS-Ethernet'. On the other hand. the large scalecomputer system INS·M780 is also available through theassociated I oca I area networJ.. if we need any I arge com·puting pwer. In this case. TCP/IP protocol is used andterminal server with LAT-TCP/IP protocol is avai !able in
the netvork system.
The log-in by the off·site users will be expected
through the network. ,To reject. such a problem. physicalcut off of the network 11i 11 be expected during the actual operation phase. but general prot.ection met.hod is
also employed.

is used in this system as the communication interface to
EXU.
The VAXstation 3100 is used as OPU with VAX
resources. The beam simulation program is available In
this system. for instance. COD correction can be performed by the comb Ina ti on of OPU and EXU. The EXU sends
measurement result of a beam orbit to OPU and receives
back the command to change the correction current. Thechange of current is carried out by EXU.
Monitoring of the operating condition is an lmpor·tant faci I ity. To discover the operating status. EXU periodically collects the operating status through the
CAMAC system. The collected data is saved into a fileand 11eriodical ly refreshed b~· a timer process. The OPU
assigned as a warning monitor refers the file in any
time and executes appropriate fai I ·safe procedures.

functionget device information
numberget interface
subroutine number

input

output

O:D<devn!lll!>

O:n

O:R<subrnam>

O:nget periodic control

0: K<subrnam>

O:n

O:n

O:<devnam>-··-t.......

..... i.. ........ t.•nn

get device information

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU10Control Computer
The control program. CSA90, has been developed to
execute the interface and periodic control process of
EXU. The logical image of CSA90 is shown in Fig. 3.

nameexamineinformation
modifyinformation

O:iCn

O:<strins>

O:@In(,m)

O:x
O:x
0:
0:
0:

O:@En\,mJ
0: ien=<str ins>
O:@In {, m) "X
O:@En (,ml =x

Global Data
Interlace process(CSA_Ml)

Interface subroutines() = optional

i = subroutine number

n = item number of device infonnationm = element number of arrayx = data

Fig.2 Format of Text. Message of OPU/EXU

Notify process
GSA)'ITFY)

Periodic control
I < " - - - - - - - < process (CSA_KNL)

Periodic contrnl
subroutines

Operator Console
The distributed operator consoles provide manykinds of operating functions. Up to 10 operator consoles
could be joined with EXU to execute task to task com·municatlons. The main aim of task to task communication
is to transfer the text message as described before. On
the other hand, operator consoles as workstations
provides us with the highest quality of visualization.
man-machine communication and calculation speed. wehave been considering several types of man-machine communications such as a touch panel, rotary encoder. mouseand so on.
The NEC-PC9801 with the resistive touch panel sheet
and rotary encoder is chosen. The mouse system is also
used in this OPU. The ON/Off control and value setting
are the main job of this system. The operating system
of MS·DOS 3.38 and MS-C. MASM and turbo-C have been used
to develop the application control program. DECnet-DOS

fig.3 Logical image of control program CSA90
The CSA90 provides us with a flexible and expandable control system. This program has a basic program.
device control programs, configuration definition files
and a data generator.
The device control programs area set of subroutines and have no direct relation to eachother. The basic program executes t.hose subroutines ac·
cording to a configuration program and requests from
OPU. To make the configuration definition file easily. adata generation program is also provided.
By using CSA90. addition of new functions ormodification of the control procedures are easily madeby addition or modif lcation of subroutines. Then thecontrol sequence or configuration of the control systemcou 1d be changed eas i Iy in according to the purpose of

S02SRU10
94

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 Publishingaccelerator studies and so on.
The 1/0 interfaces are comprised of CAMAC. GPIB and
RS232c. Presently the main CAMAC crate is alternative!~·
control led by either the Kinetic 3922 and EXU or Kinetic
3920 and an old existing microcomputers. The serial
CAMAC driver housed in the main CAMAC crate is used commonly by either EXU or existing microcomputers throughthe above mentioned crate control !er. Several kinds ofI oca I contro I devices with GP I B are I oca ted near the RI'
acceleration system. electron cooling and elsewhere.
They are control led by EXll through the fiber cahle. The
CMIAC control system also supports GPIB through the local CAMAC-GPIB converter.

the local area network. For instance, above mentioned
pattern generators will be changed to a \iME system withpattern memor~· system.
The local CAMAC computer housed
i n the CAMAC crate is a I so considered as the candidateof distributed intelligent local control device. We havealready been developed 8bit CAMAC module computer with afunction of pattern signal generator. parallel bit signal input and output for any purpose. In this s~·stem.
control program is stored as the ROM image and the RAM
image.
In Fig.4 the block diagram of proposed 32 bit
CAM AC; board computer is shown.

Conversion from present system to new one
Local intelligent Control Devices
The distributed control devices wit.h an intelligent
function have been used in the TARN2 control system. For
instance, pattern generator to regulate the magnetic
fie Id of the ring has Ileen used in the synchrotron magnet power supply system. Present pattern generator iscomposed of the microcomputers and is directory controlled by the terminal at the control room. To include
such an individual intel I igent controllers into the network system. we have been considered an up-grade of existing intel I igent one to new one.
Though the add-on board of Ethernet system can beused in the present intelligent local control system. it
is difficult to construct the network communication system because it is depend on the operating system of thecentral processor of local control s~·stem. For more any

The present microcomputer systems is written using
an interpreted language such as INSBASIC with CP/M-86.
To continue this approach with the present 1/0 control
and the new control system. especially for GPU. a
program converter has been developed from INSBASIC touuickBASIC. which is used as the programming language
for OPU. So the new control system will provide us withthe user functions and subroutines associated with thepresent INSBASIC. Thus transparent programming can be
performed in the new control system. especially for
PC9801 as GPU.
For the FORTRAN system. such as the mini computer
U-400 or HPIOOO. the programs developed for CAMAC systemwi 1I be implemented on the OPU and EXU. For instance. an
e~isting program indicating the beam envelope oftransport I ine wi 11 be reconstructed with MAGIC code in
IAXstat.ion 3100 and CAMAC handler in uvax 3400.

References

Fig.4 Proposed 32bi t CMIAC board computer

unknown conditions. we have al read~· considered that dis·tributed local intelligent devices should be tied with(l] $.Watanabe. The Computer Control System of TARN- I I.
Nuclear Instruments and Methods in Physics Research.\293(1990)50·53.
(2] F.Soga, K.Noda. K.Chida. T.Hattori. T.Honma.
T.Katayama. A.Mizobuchi. M.Nakai. A.Noda. F.Sakuta.
M.Sekiguchi. N.Ueda. $.Watanabe and M.voshizawa. BeamTransport and Injection System from the SF Cyclotron to
the TARN-I I Synchrotron Cooler Ring. INS-T·494. February
1990.
(3] T.Tanabe. K.Chida. T.Honma. T.Hattori. M.Kanazawa.
A.Mizohuchi, M.Nakai. A.Noda. K.Noda. M.Sekiguchi,
F.Soga, N.Ueda. S.Watanahe, T.Watanabe. M.Voshizawa and
A.Ando. Initial Electron Cooling Studies in the TARN I I.
Proc. of the 7th Symposium on Accelerator Science andTechnology. Dec. 1989, Osaka, Japan. p201.
(4] S.\Jatanabe. T.Kohno. S.Vamada and T.~atayama, Power
Supply Control System for TARN·ll Main Ring Magnet System. Proc. of the 6th Symposium on Accelerator Scienceand Technology. Oct. 1987. Tokyo. Japan. p242.
[5] S.\.iatanabe. A.Noda. T.Watanahe and T.Kohno. Computer
Contro I of TARN· 11 Main Ring Power Supp I~" Proe. of the
7th Symposium on Accelerator Science and Technology.
Oec.1989. Osaka. ,lapan. p2'19.
(6] K. ~oki. S. Watanabe. The Design of the New Control
Program (CSA90) for the TARN2. INS-T-505. 1991.

S02SRU10
Status Reports: Upgrade

95

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-S02SRU10

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU11

network thereby allowing a variety of logical
topologi~. Cmrently, a Fermilab designed protocol
layer called "Virtual JJO Bus" (VIOB)S , manages
communications between the execution processors
and the I/O subsystems. VIOB enables thesubsystems to appear as extensions of the execution
processor's local buses. The current topology for asingle sector is illustrated in Figure 2.
ACCEL DMSIONTOKEN·RINGSERVICE
BUILDING
BLOOt'
MULTIBUS II CRA1l
FIGURE 1

3

Subsystem communications
2

Control for each of the satellite refrigerators i sfurther divided into two JJO subsystems: Cryogenic
Thermometty and Device J/O. (Compressors do not
require thermometty .) The subsystems are located at
the source of their respective signals and areconnected to the execution processors by Arcnet,
which functions as a small area network.
Arcnet is a low cost, highly reliable network that
supports up to 255 nodes and can be implemented
over a variety of media including coax, twisted pairand fiber4 • It utilizes a deterministic "modified token
passing" access scheme with a data rate of 2.5
megabits/second and a packet size of S12 bytes. It
has a very simple protocol and all of the net~ork
services are provided at the silicon level by a vanetyof commercially available controller chips. The
controller interfaces to a system through a page ofdual ported RAM, and a single command/status
register. To initiate a network transmission the hostprocessor simply loads a message packet into theRAM buffer and issues a "transmit request".
Message packets consist of a source ID, a destination
ID the message byte count, and up to 508 bytes ofus~ defined data. All messages are accompanied by
a 16 bit CRC character which the receiving node uses
to verify the integrity of the transmission.
Additionally, all error free transmissions are
positively acknowledged.

THERMOMETRiCHASSIS
111111...
•...
•lilllll

1111•

MULTIBUS IICRATE
386 CPU/BLDGo•~

PRIMARY
TOKEN-RING-EQUIPMENTBUILDING

I

~

J/O

CRATE

I
I

THERMO'A.f'IM'l)i
CHASSISTHERMOMETRiCHASSIS

I

rrI
I
I

~

J/O

CRATE

I/O

CRATE

I
I

THERMOMETR'l ~CHASSIS

ARCNETREPEATERCHASSIS

I
I
I

~

J/O

CRATE

J/O

CR.ATEISECONDARYARCNE'I . .

COMMUNICATIONS TOPOLOG1
FIGURE 2

The 110 subsystems

The basis for each of our subsystems is a 16 Mhz
Intel 80C186EB functioning as an JJO processor.
The "EB" is a low power, CMOS version of Intel's
80186 embedded microprocessor. It is based on a
modular CPU core that integrates most essential
system services onto a single 80 pin package. The
object code of the 186 is directly compatible with the"real mode" of the 80386 microprocessor. Henc~, asubset of the tasks developed for the execution
processors could, in the future, be ported to the J/O
There are no hardware imposed restrictions on processors as a way to further improve softwarecommunications within a sector. Each node is performance.
permitted equal access to all the other nodes on the

S02SRU11
Status Reports: Upgrade

97

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

Transducer interfacing is accommodated by two,
9U size AID converter modules. Each module
supports 64 differential input channels with a 10 volt
The Device J/O subsystem includes support for 128 range. The analog front end consists of two stages oftransducer inputs, 38 actuator valves, 32 helium input multiplexing, an instrumentation amplifier, andrelief valves, 12 vacuum gauges and 6 "wet" or a 12 bit, self calibrating ADC. To facilitate fast data"dry" expansion engines. The subsystem is housed logging all 64 channels are digitized within a one
in a Euro-chassis located within the cryogenic millisecond period. The results are stored in a double
equipment building. The current configuration is banked, dual ported RAM. The arrangement allows
the J/O processor fast access to the digitized data with
illustrated in Figure 3.
a minimum of arbitration conflicts.

The Device 110 subsystem.c . .. . .... . .. . . .. . .. . . .. . •c"..
. ..., .. . . . • . .. .. .. . .. . .. •• " " " .. • . • • " .. " " " " "
c

T

c c
T T
u v v

T
0

T

I

I

u

T

T
0

T
0

c

c

c

c

c

c

Cl

c

Cl

u

T

v

T

T

T

u

T

u

T

u

T

u

T

u

T

T

II

T

T
0

T
0

T

T
0

T

T

0

T
0

T

0

T
0

T

0

0

0

T

0

u

• • • • • • ... n..c . ..c .. c.
. .. . . ..
Cl

T

v

T

u

. ..
T

.."

u

T
0

T

c

Cl

c

u

T
II

T

T

T

T

II

II

II

II

u

T

T

T

T

T

0

T
0

T
0

T

0

u

T

T
0

" • "

• . • ..

'~· ". ..a .

T
0.. .. .. . ..

v

T

v

0

u

Actuator Control cards provide a comprehensive
interface to the Barber-Coleman electromechanicalvalve actuators used throughout the cryogenic
system. Each 3U size card incorporates all of thefunctionality necessary to interface a single device
including: 24 volt DC drive control, Linear Variable
Differential Transformer instrumentation, and AID
conversion circuitry. A local front panel control
mode is also provided.

u. . . . .. . ..c .
". . . .. . . .. ..
. .,. . • ..

Cl

T

u

0

T

T

T
0

Cl

c

c

T

.. .. .. .. • • • ".
" •" "" "Wet engines, dry engines and cold compressors1 all
interface to the control system via Engine Control
cards. 6 Each 3U card provides momentary relay
contacts to implement "start", "stop" and "reset"commands. Also included are two independent
channels of analog J/O (one for engine speed and one
spare), and 16 optically coupled status bits. A front
panel display reflects the state of both command andstatus bits.

... ... • •.. •@.. .. ..
. .. ""• •." "" •"•
•
I

0

T

u

~ \1

T

0

T

u
T
0

T

T

v

T
0

T

0

T

v

u

T
0

T

0

0
I

0

I

ff

I

•,

0

" • • • " • ••EQUIPMENT BULDING 1/0 CRATEFIGURE 3

Activity within the subsystem is orchestrated by a
9U size processor module which hosts the 80186EB.
In addition to those system services provided by the80186, the processor module also provides fast data
logging facilities, Tevatron clock decoding, theArcnet interface, and distribution of various clock
signals.
The J/0 processor interfaces to the rest of thesystem via three identical backplane buses referred toas the "F2" bus. The F2 bus was developed in houseto overcome the difficulties associated with cabling
an average number of process I/0 signals to a 3U
size Eurocard while simultaneously supporting ahigh performance 16 bit bus interface on a single 96
pin DIN connector. It provides 32 pins of user
defined J/O at each slot along with addressing spacefor up to 512 sixteen bit memory mapped registers.
The individual slots are mapped to the J/Oprocessor's memory and are individually selected ina fashion similar to the CAMAC standard.

The variety of solenoid valves used throughout thecryogenic system are interfaced by Kautzky7 Control
cards. Also implemented in the 3U format, each card
provides control and status readback for up to eightsolenoids. A front panel display reflects both theactual state and the requested state of each valve.

Pirani (vacuum) gauges are interfaced by a 9U size
Vacuum card. The card supports 12 transducer
circuits. A free running, multiplexed AID converter
continuously scans the transducer voltages, storing
the digitized results in a dual ported RAM buffer.
Miscellaneous status bits are monitored by a Digital
Input card. The 3U size card supports 30 bits of
optically coupled status with input voltages ranging
from 5 to 24 volts D.C.

The thermometry subsystem
The thermometry subsystem supports 96 channelsof pulsed current, resistance thermometry. Unlike
the Device J/O subsystem, it is implemented as an

S02SRU11
98

Status Reports: Upgrade98

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S02SRU11

application specific single board computer. It resides Conclusion
in a NEMA-12 enclosure mounted along the backThe use of a hierarohical, networked architecture iswall of the Tevatron Service building.
ideal for this application. The higher cost, 32 bit
The free running measurement scheme uses a microprocessors have been de-coupled from theprecision current source (along with six stages of cryogenic system, thereby protecting the investment
multiplexing) to deliver a 50 microsecond current from premature obsolescence. The distributed
pulse to each resistor module. The voltages subsystems can be incrementally upgraded - or even·developed by the resistors are scaled by a replaced - with a minimum of impact to the rest of
programmable gain instrumentation amplifier before the system. Additionally, the maximum limit of 2~5being digitized by a 12 bit, self calibrating AID nodes per sector permits almost unlimited expansion
converter. Here too, a dual ported RAM is of the system.
arrangement is used to store the digitized results.

Acknowledgements
The subsystem also maintains a hard-wired 16 bit
bi-directional data link with the Tevatron Quench
Protection system (QPM). In the event of a magnet
quench, the QPM provides the refrigeration control
system with specific cell information to assist
automatic recovery schemes. The refrigeration
system provides the QPM with a permit allowing themagnets to be turned on.

We wish to acknowledge the contributions of thoseindividuals whose efforts were responsible forturning ideas into functioning components for thissystem, especially: Loren Anderson, Ryan Hagler,
Joe Gomilar, Timothy Gierhart, Rich Klecka, Rich
Koldenhoven, Robert Marquardt and Thomas
Zuchnik.

Reliability and system diagnostics
1Fuerst,J.D. "Trial Operation of Cold
Compressors in Fermilab Satellite
Refrigerators", Advances in Cryogenic
Engineering, Vol. 35B, Plenum Press, NewYork (1990) .
2 Zagel,J. et al., "Tevatron Satellite
Refrigeration Control Subsystem" ,IEEE
Transactions on Nuclear Science, Vol NS28 , p2153-2154.
3Gtass,M., et al., "The Upgraded Tevatron Front
End"' NIM A, 1990, Vol 293, p.87-92.
4GJass,Brett; "The Return of Arcnet", BYTE,
February 1991, pll9.
5 Chapman,L. et al., "Microcomputer Software
Architecture for Cryogenic Controls", (Thisconference).
6Rode,C.H., "Tevatron Cryogenic System", 12th
International Conference on High Energy
Upon completion of confidence testing the Accelerators, 1983. p 529-535.
operating system and refrigeration specific 7"The Kautzky Valve", Fermilab Repons, June,application software are down-loaded via the iPSB. 1982.
At that time the execution processors are started andthe PC16 relinquishes control of the system The
PC16 is now free to be utilized as a local information
data base or console emulator by technical personnel.
System schematics, diagnostic flowcharts and related
maintenance histories can be displayed, as well as
any other useful DOS based application.

One of the notable benefits of using the Multibus II
architecture is the emphasis that the platform placeson confidence testing and system diagnostics. Every
module in the system supports a standardized set of"built in" self tests (BIST). During the initialization
phase following a power-on reset, each module
executes a subset of these routines to test its ownfunctionality. The results are posted in "interconnect
space" and are globally available to the rest of thesystem. Upon the coordinated completion of a reset,
one module (in our case the PC16) assumes atemporary role as the systems' "boot master". The
master can subsequently invoke, or download
additional tests for each subsystem on an individual
basis. This can be accomplished locally via an
RS232 port or from a remote facility with the use ofamodemS02SRU11
Status Reports: Upgrade

99

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-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

puter cards to provide parallel transmission of data with nosoftware protocol overhead. The power converters and beam
monitors will use the latest digital signal processors and microprocessors, so no problem is envisaged at this level provided
they can all operate in parallel.

C. Pilot Procedures.
It will be necessary to automate the procedures ofmachine preparation, pilot injection tests, and full beam injection and acceleration, in part to keep the persistent current
effects under control, in part to avoid human error. Much workof this kind was done for the Antiproton Accumulator after
initial commissioning, but for LHC this will have to be done
beforehand, so placing an early load on the applications programming effort. Of course the modelling programs in theservers will also have to be ready and tested before injection tests
can start. High quality work in these areas will greatly reduce thetime needed to get the machine into proper working order.

Ill. QUENCH PROTECTION
The first line of quench protection will be assured by
24 quench protection stations distributed around the ring. They
will constantly analyse the voltage transducers connected ateach coil access point in order to determine if a quench has takenplace. The quench station will then take a series of time criticalactions including firing the beam dump and firing the magnet
heaters to spread the quench evenly over the magnet. This forces
the current to flow through the cold diode protection shunts toavoid local damage to the coil at the quench position. Heliumpressure relief valves are then opened to avoid reaching emergency over pressure. A 5 second pre-quench record will be held
for "post-mortem" analysis.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD01

IV. BEAM MONITORING
The two main subsystems are the orbit measurement
and the beam loss monitors. The monitors will be wired to 24
concentrators round the ring for local processing and connection
to the network. Each local unit will have a direct connection to
the beam dump which will be activated if conditions which willlead to a quench are detected. In the case of some critical beamloss monitors, like those near the collimators, the dump will
have to be activated in 1 or 2 revolutions, ie. 90 to 180
microseconds.
The closed orbit measurement will be systematicallyacquired by the modelling server to aid in its 2-10 second updateof the power supply currents. In addition to helping compensate
for the persistent currents, this will provide a continuous on-line
correction of the orbit.
The orbit and beam loss monitors will also be acquired
on a regular basis by the central alarm server to help in thedetection and avoidance of quench provoking situations.
Other instrumentation is foreseen to measure tune,
chromaticity, profile, and dynamic aperture and will also becontrolled by local sub-systems. These measurements will be
used along with the orbit and loss monitors by the programs
which set up the machine for injection, acceleration, andcollision. A particularly important role for all the instrumentation will be the pilot injection tests first with a bunch of 109
protons, then with a 1011 bunch to prepare for the full batch.
The beam monitoring stations will be connected by thefast acquisition system to a beam data server and hence to themodelling server. A first trial of the fast acquisition is plannedin the near future using some of the LEP beam instrumentation
as a prototype.
V. CRYOGENICS

The magnet control computer will then take over,switching in series resistors in appropriate places to run thecurrent down as quickly and safely as possible. Constant surveillance of the quench protection stations will of course benecessary as no malfunction can be permitted. Also the state ofeach magnet will have to be monitored for abnormalities intemperatures and voltage drops to detect deviations whichmight indicate variations in performance from the model, or
incipient trouble. Before each injection extensive automatic
checks will have to be done on all magnets, cryogenics andquench protection stations to ensure a fully normal situation.
All of this software will have to be ready and well tested
before any significant number of magnets can be put into
operation. For this reason the controls effort will liase closelywith the magnet test strings and test stands right from the
beginning.

The number of pieces of cryogenic equipment to becontrolled is very large. However, the equipment involved iswell known to industry, and an industrial control system will bepurchased for this purpose. This must communicate effectively
with the main control system, as any magnet whose cryogenic
state or pre-history is inadequate may be prone to a quench
before full field is reached. Thus the state of each magnet must
be checked by the control system before each cycle and continuously monitored thereafter. Also access to the cryogenics
systems should be the same for normal operator use as the accessto any other system.
VI. OTHER SYSTEMSAt present it is assumed that most other LHC subsystems will be controlled by extensions of the LEP control
system. If after further study it is found that some other system,
for example the collimators, needs special fast control, they can

S03SRD01
Status Reports: Design/Construction

101

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, Japanbe dealt with using the fast techniques used for the beam
monitors and power supplies.
AtfirstLEPandLHCwillnotfunctionatthesametimeand therefore much of the standard LEP controls may be re-used
for LHC. In any upgrade ofLEP this will be borne in mind andspare capacity will be provided where appropriate.

achieved. Alternatively, applications programs which mustrun
fast or which need a lot of data, can interrogate the database atstart up time and store the data in RAM structures for immediate
and fast use, as is done at Isolde[4]. This also protects the
programs from inconsistent updates. For any updates to become
effective, the program has to be stopped and restarted.

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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD01

VII. LHC DATABASE
VIII. ARCHITECTURE
A database (ORACLE) will be used to store thecharacteristics of the LHC machine and to help with theplanning and installation. Such a facility proved invaluable for
LEP. For LHC there will be even more high technology equipment to be installed in the tunnel in a shorter time and withlimited staff. A maximum amount of easy to use informatics
must be provided to ease and control this installation.
All controls information will also be stored in a database. The use of an on-line database was pioneered at the PS on
the original IBM 1800, followed by the data-module concept at
the SPS. The usefulness of having cabling and installation dataon-line was illustrated in the '70's with the SPS experimental
area system[3]. For LEP it was necessary to copy the data to
local files for use in the control system. We hope to avoid thisin LHC and use direct on-line data-base access. Not only will
this save work and additional software, but it will reduce thepossibilities of errors and inconsistencies. Two approaches areenvisaged. For interactive use the database can be interrogatedas required by SQL commands during the course of the applications programs. Tests at the PS have shown that response
times consistent with human operator interaction can now beControls technology sees major revolutions on something like a five year time cycle. As LHC completion is morethan 5 years away it is premature to make final decisions on thearchitecture, even more premature for the detailed components
to be used. Nevertheless, since this is a controls conference, anarchitecture is presented for discussion which illustrates muchof the current thinking[?]. This is shown in figure 1.
A. Equipment Connection Policy

A major feature is the equipment connection. An
important change in equipment connection policy and technology took place in LEP. The responsibility of the equipment layerof the controls was transferred to the groups responsible for theequipment, and a "thin" connection made to the control system.
This policy will be continued and reinforced for LHC • The
controls group will provide the hardware connection for data
and timing, and together with the equipment group it will definea control protocol which will define the characteristics of theequipment to the control system. This policy has several impor-

OfficeWork Station

CentralServers

ConsolesSite-wide LAN

Control LAN

Modelling
Equipment
ServerDeviceStub

Industrial
ControlInterface

Field Bus
TOM

I
uipment

uipmen@uipme~Links to Industrial Controls .

Figure 1. Schematic diagram of architecture

S03SRD01
102

Status Reports: Design/Construction

102

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

ICALEPCS1991, Tsukuba, Japantant advantages. Firstly it clearly defines the budget separation
between the control and equipment groups. Secondly it clearlydelineates the responsibility for design, performance and maintenance of the control equipment. Thirdly it decouples theevolution of the control system from the evolution of the specificequipment controls. This is becoming an ever more importantconsideration as the park of control equipment increases and wehave not the resources to change everything at the same time.

D. Industrial Equipment Connection
The third mode of equipment connection, shown diagrammatically on the bottom right of figure I, is connection
through industrial control equipment[6]. For the cryogenics
equipment, and perhaps others, it makes sense to buy thecontrols from the equipment manufacturer or an industrial
process control manufacturer as he has solved the problems, has
all the components in house, and can take charge of theinstallation and maintenance. The controls thus purchased maystop at the level of the Programmable Logic Controller (PLC)
for the equipment concerned, or even a complete system may bebought with the manufacturer's network system and consoles sothat he can take full responsibility. In both cases an interface tothis manufacturer's equipment has to be provided to achieve two
way communication and control, and to integrate the industrial
controls into the protocols and methods of the rest of thecontrols.

The bottom left of Figure 1 shows the LEP equipment
connection[5]. The specific equipment is connected to a field
bus, MIL 1553, which is connected to a "Device Stub Controller" consisting of an Olivetti PC running the SCO UNIX
operating system (replacement by LynxOS, a real time PO SIX
compliant operating system is planned in the near future. This
operating system can also run in a VME crate). These PCs arelocated in the field, and are linked to the rest of the control
system by the control LAN. Much of the LHC equipment will E. The Central Servers
be in common with that ofLEP. This includes, of course, all thetunnel management services. Some of the new equipment of
In addition to the modelling server connected to the
LHC may also be connected to the MIL 1553 to save money and power supplies, there will be other central equipment servers
development cost. AsLEP andLHC will not operate at the same connected by TDM to subsystems requiring fast response suchtime, economies can be made in sharing equipment and re- as beam monitors, quench protection stations, collimator subsources.
system controls, dump, etc. Other central utility servers, as
shown on the top right of figure 1 will be required for alarms, a
C. Fast Equipment Connection
file server, an on-line database engine, etc.
The equipment connection shown in the centre bottom F. The Consolesof figure I is a new development for LHC, being done inconjunction with the SSC[2]. The driving force for this is a fast
These will be standard large screen workstations. The
connection to allow the rapid measurements and power con- PS and SPS c0nsole facilities are being upgraded to matchverter updates required for control of the magnetic field. Other LEP[7]. A considerable effort is being put into this and we canadvantages of low cost and simplicity are also claimed for this assume that the resulting facilities will be entirely adequate fornew method, however, which may make it a contender for LHC. There is a strong desire to have a single controlcentre withapplications which do not need its speed. The basis of this standardized facilities for the whole of CERN on the LHC time
method is to use Time Division Multiplexing (TDM) techniques scale.
to provide an individual channel from each equipment to acentral server, all connections working in parallel with no G. The Office Workstations
software protocol overhead. This TDM technology is in comLHC will involve a large fraction of CERN's acceleramercial use for telephone and higher speed data-link requirements by the communications industry, mostly running on tor community over the construction and commissioning peoptical fibre. It will also be used in LHC for dedicated connec- riod. These people will be spread over a large geographical area.
tions, telephone and video links, interlocks, and many other To permit them to work without too much travel to the central
applications which are traditionally implemented using hard control room, access will be provided from the office workstawired copper. Between the equipment and server, the TDM tions connected to the site wide LAN. A gateway will be usedchannel will link "reflective memory" cards in which part of the to authenticate access permissions, and to cut off access at
equipment memory containing the control protocol is reflected critical times.
into the central equipment modelling server. Thus the modelling
server can read its input, do its calculations, and write its output H. The Control LAN
with no degradation in performance due to software protocol
A single LAN is shown diagrammatically in figure l.
overheads and long transmission delays. Several servers may be
used, eg separate ones for beam monitors, power converters and The present system uses both Ethernet and Token Ring in amagnet monitoring. The TDM may be used to link these servers bridged configuration. It is reasonable to expect the use of FD DI
among themselves using reflective memory, or to link the in the LHC time scale.
equipment to several servers.

S03SRD01
Status Reports: Design/Construction

103

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

B. LEP Equipment Connection

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD01

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

IX. PROTECTION

In the consoles a wide range of software will be
required. Automated injection procedures will be needed forspeed and reliability. These programs and the server software
will have to be ready before commissioning, unlike the cut andtry approach which could be used with earlier less sensitive
accelerators. Extensive software for beam measurements anddiagnostics will be required.

LHC will have severe requirements concerning theauthorization of actions through the computer system. In situations where a quench is possible, equipment changes must be
restricted not only to authorized persons but also to authorized
programs which have been vetted to perform adequate checks
for quench avoidance.
There will be a large number of access points to thesystem for testing, maintenance and commissioning including,as mentioned above, the office workstations. These numbers
will aggravate the protection problem. Network management
will have to provide access permission or denial facilities, as
now being added to LEP, and the alarm and surveillance system
will have to detect and locate abnormal access attempts. The
protection will have to be closely linked to the machine operational state. Widespread access will be needed to speed installation, testing and repairs, moving swiftly to a closely controlled
situation when quenching becomes possible.

Surveillance and alarm programs will be particularly
important to avoid quenches and warn of quench provoking
situations. A variant of this software will be required to checkout the machine before injection, or before any action whichmight result in a quench.
Some of this software will have to be professionally
written, installed and tested, especially in the servers. Other
parts will be better written by the machine physicists andhardware specialists themselves. All will have to be carefully
specified beforehand. Tools will include professional development facilities for compiled programs, the old tried and tested
NODAL[8], mass market packages such as spreadsheets linked
to the machine variables as used at Berkely[9] and in Isolde[4],and other commercial synoptic packages for control as used in
LEP.

X. TIMING

In addition to data transfer, many types of equipment
need special timing signals and events. General purpose timing
systems have been developed for PS and SPS from different
historical backgrounds. Currently work is progressing on new
designs which will cover both areas and which will take into
account LHC requirements. Thus the timing distribution for
LHC should be part of a new overall system for all CERN
accelerators. There is a hope that the timing information may
even be combined with the data stream so reducing the numberof cables, connectors, and chips, so reducing cost and increasing
reliability.
XI. APPLICATIONS PROGRAMS

The maxim "a control system is only as good as its
application software" is as true now as ever it was. In the '60s
the term "software barrier" was coined to express the difficulties
in achieving good applications. In the '70s a determined effort
using NODAL in the SPS,PS, PETRA and 1RISTAN achieved
a good measure of success. In the '80s the problem re-appearedwith more complex systems and higher demands. For LHC a
serious effort will be made to put together a team of machine
physicists and programmers who will ensure that the applications programs will be available, not only to run the machine but
also to make a positive contribution to a fast, smooth and safe
commissioning.

ForLHC,applicationssoftwarewillberequiredontwo
levels, at the server level, and at the console level. In the servers
sophisticated software will be required for the modelling andreal time closed loop control of the high intensity beam in the
superconducting magnets. High reliability will be required inthis software, and in the quench protection and magnet surveillance programs. All changes and machine settings will have tobe verified through a model before being applied so as to avoid
quenches.

XII. REFERENCES[I] Design Study of the Large Hadron Collider (LHC),CERN91-03.
[2] C.R.C.B. Parker, M.E. Allen, H.C. Lue andC.G. Saltmarsh, A New Data Communications Strategy
for Accelerator Control Systems, Nuclear Instruments
and Methods in Physics Research, 1990 (Proceedings of
Vancouver Controls Conference, 1989).
[3] H.W. Atherton, M. Rabany and R. Saban, A databaseas a bridge between hardware and software, Proceedingsof the 5th International IASTED Symposium,
Tunis 1982
[4] R. Billinge, I. Deloose, A. Pace and G. Shering,
A PC Based Control system for the CERN ISOLDE
Separators, Proceedings of this conference.
[5] P.G. Innocenti, The LEP Control System, Nuclear
Instruments and Methods in Physics Research, 1990
(Proceedings ofVancouver Controls Conference, 1989).
[6] M. Rabany, Interfacing Industrial Process Control
Systems to LEP/LHC, Proceedings of this conference[7] R. Rausch and C. Serre, Common Control System for
the CERN PS and SPS accelerators,
Proceedings of this conference.
[8] M.C. Crowley-Milling and G. Shering,
The NODAL system for the SPS, CERN 78-07.
[9] S. Magyary, M. Chin, C. Cork, M. Fahmie,
H. Lancaster, P. Molinari, A. Ritchie, A. Robb,
C. Timossi and J. Young, The Advanced Light Source,
Nuclear Instruments and Methods in Physics Research,
A293, 1990.

S03SRD01
104

Status Reports: Design/Construction

104

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

Table 1. Throughput and response time requirements
SystemLocations

Bytes

Rate

Bandwidth

6
1
6
6
6

108
2,125
432
288
22

50,000
20
720
20
20

32,400,000
42,5001,866,240
34,5602640

RAMPS
VACUUM
ENV

8
1
8
8
8

150
2,125
600
400
22

6,600
20
720
20
20

79,200,000
42,5003,456,000
64,000
3,520

HEB
BPM
RF
QPM
CRYO
RAMPS
VACUUM
ENV

24
1
24
24
24
24
24

70
2,125
60
326
280
187
22

24,000
20
720
20
720
20
20

40,320,000
42,5001,036,800
156,480
4,838,400
89,76010,560

200
200
200
1
200
200
200

58
60
135
1062
332
155
22

3000
720
20
20
720
20
20

34,800,000
8,640,000
540,000
21,24047,808,000
620,000
88,000256,123,700

LEB
BPM

RF
RAMPS
VACUUM
ENV
MEB
BPM

RF

COLLIDER
BPM
QPM
CRYO
RF
RAMPS
VACUUMENV
TOTAL

Control loops will be implemented at the Local (Niche),
Regional (Sector) a.nd Global (Control room) levels[4].
However, in order to debug the systems it will be necessary to open some of the local and regional loops fromthe control room, and move some of the loops from local
to regional to control room and vice versa. For instance a.
control room algorithm might be tested a.t the global level
and then installed as a local loop for reasons of security,
because it ma.y need to continue to operate when the global
system is in a maintenance mode.
This leads to a. requirement that all raw data. that might
be needed at any level of the control system, even local
loops, must be available in the control room. Furthermore this has the important advantage that application
programs will have access to all of the data. associated withthe sensors that might otherwise be hidden. For example
if a beam monitor system provided only the result of acalculation, for instance the beam tune, it would not be

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD02

a simple matter to add another capability, for instance a
calculation of the beam lifetime. More importantly new
algorithms could not be tested without affecting the operation of existing systems. In addition, as new capabilities
a.re added to systems, the control system should not limit
the raw data that is acquired to some arbitrary fraction of
the total. All data should be available at all levels.

B. Traffic Patterns
As bas been stated earlier, data generated at equipment
locations (niches and buildings) should be available simultaneously at more than one location, for instance at theregional level and at the control room to be consumed byconsole applications. It is not anticipated that there will
be significant Niche to Niche communications. This must
not however be excluded. Although a number of computers must be able to read the data from equipment locations, only one should be able to write commands to fieldequipment at any given time. An arbitration mechanism togive permissions to access equipment for commands will benecessary. When command messages are sent to an equipment location it may be necessary to queue the messages
for processing. This can be achieved by use of a high levelcommunications protocol such as TCP /IP, but this introduces a large overhead for data transmission of up to 50%.
It might be more efficient to queue the requests to the arbitration mechanism that allows commands to be sent to
the equipment.

C:. IJete'f"lninisrn
Application programs typically periodically request current readings and settings from field sensors. It will benecessary to quantify the rate of such requests and guarantee the timely transport of data through the communications systems. The performance of the system must
be predictable, that is deterministic. Furthermore because
the system will be designed to worst case scenarios, noadvantage would be gained by trying to achieve best caseperformance better than worst case. Thus data. transportshould be load-independent.

IJ. System SoftwareThis predictability in the control system should extend
to computer operating systems as well as communications
equipment. This ma.y mandate the use of real-time opera.ting systems. This would be true for embeded systems
using, perhaps, real-time kernels and also for the computers in which run application programs. For these therefore
opera.ting systems such as UNIX would be discarded infavour of, for instance, a. real-time UNIX.

E. IJata Stores
It will be necessary to provide a mechanism to store any
data that is acquired to equipment locations or applications programs. This data storage might be for temporary
use in shared memory, in a data.base or a system. As someof this data may be archived for many years it is important

S03SRD02
106

Status Reports: Design/Construction

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

ICALEPCS1991, Tsukuba, Japanthat it be stored in a format that does not become obsoletewith new versions of the storage utilities. There should be
one coherent set of library routines and utilities that canhandle these functions. These utilities and library routinesmust be able to access the structure of the data, not justhandle the data set as a whole. The ability to access thedata should not depend on the availability of header files
that were written at the time with the original application
program, and may now be out of date. And they must
not need prior knowledge of the structure of the data. The
description of the data should therefore be in a standard
format, embedded in the data or in a database.

all transmission frames or the token times out. The station relinquishes monopoly of the ring by generating a new
token which other stations may then acquire. The timingout mechanism ensures that other stations on the ring havea chance to transmit.
Token passing protocols can be made to be deterministic, but many of the higher level protocols do not take advantage of this feature. Token rings transmission rates canonly go as high as 4 or 16 Mbps, meaning that many rings
would be needed to achieve the bandwidth requirements of
the SSCL. Also, response time is slow due to delays introduced by each station. It is more suited to larger transfers
such as file transfers.

ARCHITECTURES

A. SERIAL CAMAC HIGHWAY
Serial Camac meets many of the requirements of a controls communications architecture, all the data is available
from a global level, with no data-hiding, but it is difficult to control access to the equipment. Response times
and throughput values using present systems are below thelevel of performance that we require.

B. CSMA/CDIEEE Standard 802.3 is a "listen while transmitting"
LAN access technique, commonly referred to as CSMA
CD (carrier sense multiple access collision detection). It
closely resembles Ethernet with some minor changes inpacket structure together with an expanded set of physical layer options. Bit rates supported are between 1 Mbps
and 20 Mbps. Collision detection means that collisions
i.e. simultaneous bids for access to the medium can be detected early in the transmission period and aborted, thus
saving channel time and improving overall channel utilization. When a collision is detected, the user backs off andcontinues to attempt access until a maximum number ofunsuccessful attempts has been reached before generating
an error. A contention-based protocol like Standard 802.3
is unsuitable for a number of reasons. It is not deterministic. It can be totally blocked with no critical data able
to get through from a critical system. It is not easy, using
standard protocols, to arrange that many stations be able
to receive the data, and the data producer has to know theaddress of the recipient. The access protocol works only
for short segments of network, requiring bridges between
physical networks. Typically, networks which are lightly
loaded with random traffic requests are especially suited
for CSMA/CD schemes.

C. Token Rings
The token ring protocol specified by IEEE Standard
802.5 is a polling-based controlled LAN access technique.
A station gains the right to transmit on the ring when itd~tects and subsequently captures the circulating token.
This station continues to transmit until it either exhausts

D. FDDIThe fiber distributed data interface has the advantagesof the token passing protocol and is much faster (100Mbps). It can operate over the distances covered by the
SSCL.
The delay introduced per station is much lower than for
token ring as it does not capture all of a packet before retransmitting it, but captures the token while at the sametime retransmitting it to the next station on the ring. If thestation is the intended destination, determined by examining the first bytes of the token, the outgoing transmission
is aborted and this invalid packet is stripped off of the ringby the station that originated it.
However the use of only a single token on the ring at any
time means that for large rings such as at the SSCL, whentransmitting small amounts of data, most of the time iswasted transmitting the tokens.

E. TDMTime Division Multiplexing (TDM) is widely used in
the Telecommunications industry. It is the method used
for passing voice and data channels over common copperand fiber optic media. The system consists of a network inwhich a channel that is a multiple of 64 Kbps or 1.544 Mbps
is assigned between two geographical locations [5]. Theremay be many channels between these two locations, eachchannel carrying specific information with all the channels
sharing the same fiber media.
The TDM system with its established industry standards of supported transmission rates will be able to address our requirements as outlined below.

V. TDM PERFORMANCE
A. Response TimeThe equipment employed has very low overhead, typically 10 µs per node which is less than the speed of lightdelay imposed by the distance around the Collider. Since
it is a point to point network and not a ring, the time totransmit a message is halved as the message does not haveto return to its source.

B. Throughput

S03SRD02
Status Reports: Design/Construction

107

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

IV. POSSIBLE COMMUNICATIONS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD02

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 PublishingThroughput is determined by the number of channels
assigned to any link. Standards exist for TDM equipment
at a number of data rates. Low speed systems use asynchronous transport at (for example) 1.544 Mbps (called Tl
or DSl) and 45 Mbps{ called DS3).
At higher rates, synchronous systems often based onfiber optic technology are available. These are defined in
the Synchronous Optical NETwork (Sonet) standard. This
standard specifies rates that are defined at 55 Mbps (calledOCl) which can transport 28 DSl signals and multiples ofthat rate. The rates are not exact multiples as some overhead information passed for network management whichuses the same number of bits regardless of the link speed.
OC3 for example can handle 84 Tl signals and runs at 155
Mbps. Commercial equipment available now is capableof transporting 2.5 Gbps (OC48) over a single fiber optic
cable.
Work is continuing with multiplexors at OC192 thatshould be commercially available in a few years, but additional fibers can always be utilized for increased bandwidth. Standard fiber optic cables consist of up to 250
fibers in a 3/4,, diameter cable, giving present total capacity of 625 Gbps.

is needed, it would be a multiple of 64 Kbps or a full Tlinterface at 1.544 Mbps {24 individual 64 Kbps channels).

C. Reliability

Some systems also have an interface to a message broadcast system[6]. This uses a Tl interface to distribute, fromthe control room, medium speed synchronization signals(called events). These signals are characterized by being
repetitive such as the 720 Hz clock event or signals thatare needed in many locations such as an injection warning
event.

doi:10.18429/JACoW-ICALEPCS1991-S03SRD02

This type of equipment is used throughout the commercial telephone system where an interruption of service
could be disastrous. As this equipment is (as in our case)installed in remote locations, many network managementand diagnostic features are built in.
Redundancy is an important feature in these systems.
Dual redundant optics and power supplies, and the possibility of building redundant rin_g networks, are standard
features. The use of redundant rings affords network integrity. Data is automatically rerouted the opposite way
round the network should the fiber break or otherwise fail.

D. Data Accessibility
As each data channel is independent of all other datachannels, there can be no contention in the network. Data
from embedded systems or regional computers can be madeglobally available as the network will have the capacity tohandle all data.

VI. TDM IMPLEMENTATION
A. Interface to front end equipment
In each of the equipment locations, for instance Collider
niches [Fig. 2], a number of different systems have to beinterfaced to the TDM communications system. These include beam monitors, quench protection, ramp generation,
vacuum and cryogenics.
These systems will use VXI, VME, STD or CAMAC bus
standards or may in some cases be acquisition and control
interface cards directly connected to the TDM network.
Each of these systems would normally have a 64 Kbps interface to the TDM network. Where a higher interface rate

NICHE DATA COMMUNICATIONS
OC3

OC3SONETRING
N>M

Tl 1.6 t.111&19

I

lnX64Kbil!W

VME
MESSAGE BRCW:lCAST

T1

I

I

I

STO

CAAIACI
I

VME

Figure 2: Collider niche data communications

B. Message broadcast system

C. Long distance links
At each equipment location, the low speed Tl signals are
multiplexed using an add-drop multiplexor (ADM) onto ahigh speed OC3 Sonet link [Fig. l]. This link will connect
all equipment locations in a region. A region would be a
Collider or HEB sector (the Collider has 10 sectors, theHEB 2), the Linac, LEB or the MEB. At one location ineach region the OC3 link will interface to a global OC48
(2.5 Gbps) Sonet link. This will be a Sonet ring that willconnect together all the regions and the control room.

D. Interface to regional computers
The regional computer would also be interfaced to theregional OC3 link. This is to allow it to control regional
control loops if necessary. Data arriving from equipment
locations would be available to the regional computer aswell as transported to the central control room via the
OC48 link.

E. Interface to Functional computers
In the control room functional computers running accelerator applications programs will need to have accessto data arriving from the equipment locations over the
Sonet links. The physical attachment to the TDM networks will be from VME-based Sonet interfaces running

S03SRD02
108

Status Reports: Design/Construction

108

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD02

SSC CONTROLS ARCHITECTURE
F

F

F

F

Funotlonal
Computers

COMMON MEMORYMEB

OC48 - 2Gbit
SONET RING

R

A
Regional
Computer'-...,.NICHE
T1 - 1,6 Mblt

Figure 1: SSC Controls Architecture
at OC3. These OC3 signals will be obtained from an adddrop multiplexor on the OC48 ring. Each functional computer will have access to the data, not only from the OC3
to which it is directly connected but also from all otherfunctional computers. The data arriving will be memory
mapped into the virtual address space of all of the functional computers.

Operational Requirements of the Accelerators," International Conference on Accelerator and Large Experimental Physics Controls Systems, 1989, Vancouver,
Canada.
[31 K. T. Dixon and J. Franciscovich, "SSC Accelerator
Availability Allocation", 1991 International Industrial
Symposium on the Super Collider, Atlanta, Georgia.

VII. CONCLUSIONS[41 M. Allen, S.M. Hunt, H. Lue and C.G. Saltmarsh, "AHigh Performance Architecture for Accelerator Controls" , 1991 International Industrial Symposium on
the Super Collider, Atlanta, Georgia.

The SSCL performance requirements appear to be attainable with today's technology. Furthermore, the communications network will be largely commercial, thus
meeting the reliability and inevitable future capacity upgrades. TDM technology is well-understood and wellestablished and would not become obsolete during the lifetime of the project.

VIII. ACKNOWLEDGMENTS
The choice of implementation using parallel communication and memory mapping was influenced by the control
system of the Advanced Light Source at Lawrence Berkeley Laboratory[7]. Many of the original concepts were
proposed by C. Saltmarsh {SSCL) and C.R.C.B. Parker(CERN) who is pursuing some of these ideas for use in the
LHC control system at CERN.

[5] ANSI Tl.102, "DSl, DSlC, DS2 and DS3 Levels ofDigital Hierachy."[6] K. Low and R. Skegg, "The Prototype Message
Broadcast System for the SSC", IEEE Transactions
on Nuclear Science vol. 38, No. 2, pp325-328, April
1991.
[7J S. Magyary et al, "The Advanced Light Source Control System ", Nuclear Instruments and Methods inPhysics Research, A293{1990) 36-43, North Holland.

References[1] Site Specific Conceptual Design, SSCL-1056[21 M.E. Allen, C.G. Saltmarsh, S.G. Peggs, D.A. Dohan, and V.E. Paxson, "Demands Placed on the SSC
Laboratory Control System by the Engineering and

S03SRD02
Status Reports: Design/Construction

109

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

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

ICALEPCS1991, Tsukuba, JapanI-

SYSTEM

CD<TROLl.ER

r .
ETI-E:RNET

f'1F'OHI GH·LEVEI. ca.P.
INTERFAa::
HIGH•LEVEL ca.P.

INTERFIJ:£
GRAl't-UC DISl'V.Y
SYSTEMllUS CXl'ITROL co.tP

INTERf"ACEllUS COllTROL CQ.IP!NTEl'IF ACE

BUS CXl'ITROL CQ.IP

lN'TERF Ao::

Figure 1. Control System Schematic

We are planning to monitor a great deal more than wecurrently do. This will help minimize downtime either byindicating when a problem is developing or pointing to thecorrect area when a malfunction occurs. With the increased
monitoring and the additional equipment, we are assuming
about five times as many input control points.
There will be several instrumentations systems which
require local processors. These systems will need a control
system interface for passing processed data. They will alsoneed a connection for downloading and debugging.
C. Strengths of the Existing CESR Control System
Perfonnance is a critical issue. When the operator turns
a knob, there should not be a noticeable lag in the response.
We run the CONSOLE program at 10 Hz. This is the
program that accepts input from the operators and displays
results to them. Each time this program runs, it scans theoperator input devices, updates the controlled device, andupdates the operator's display. It rakes about 7 milli-seconds
for each pass through this program.
The CESR control system makes very efficient use of thehigh-level computers. We currently use two VAXstation 3200
computers. The nonnal application load, consisting of 14

programs, uses 50% of one computer and 30% of the other.
This allows special applications (orbit measurements, energychanges) to run in a timely fashion. The efficiency is achievedby minimizing the layers of function calls required to communicate with the hardware and by having processes hibernate
when they have requested that the BCCs move a lot of data.
The system is simple and easily extended. We makeminimal use of operating system and network functions. This
allows us to avoid 'black boxes'; pieces of software overwhich we have no control. When we added a SUN computerfor beam dynamics studies, it was trivial to move the subroutines that are provided to the application programmers.
There is a single database. This allows us to avoid theprograms and overhead which would be needed to maintain theconsistency of a distributed database.
The database and the interface hardware are memory
mapped into the address space of the BCCs. Simple 'move'
instructions are used to access the database and the hardware.
The control bus can complete a data transfer to the farthest
interface crate in less than 15 µsec. Database accesses
typically rake less than 1 psec.
Several BCCs can work in parallel on a given transfer
request For example, when reading magnet currents twocomputers are moving data, one for the east half of the ring

S03SRD03
Status Reports: Design/Construction

111

111

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-

IA.I.TI •PO:U IEl«lRY
SYSTEMTO 'fU\oNEI.

r

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD03

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
and the other for the west half. Three computers control theoperator interface.
The graphics display system provides fast and efficient
access to many graphics screens, both color and monochrome.
It is ai.:cessable to all of the high-level computers. Data is sent
to it through a FIFO, so the high-level computers simply senddata when they have it available.
Geographical addressing is used in the interface crates.
Technicians do not need to set address switches on each card.
We a1so insert and remove cards with the power on.
In the tunnel, the entire control system is contained witha metallic exoskeleton for shielding. Feedthroughs are used
for connections to the controlled equipment. We are expecting
the electrical environment to be more severe in CESR-B.

D. Limitations of the Existing System
The CESR control system has worked extremely well forover a decade. However, it does have limitations, most ofwhich stem from design decisions which were appropriate in
the late 1970s.
The address space on the control bus, which connects theinterface crates in the tunnel to the bus control computers, is
too small. Each control bus has an address space of 65
kwords. This is divided between 16 interface crates, with 16
slots per crate, yielding only 256 addresses per card slot
We do not have a simple local extension of the control
bus. We need to allow designers to build control systeminterfaces into their equipment and have an easy way toconnect to the control bus. Our current system requires twobus operations with a delay of 20 µsec between each operation.
A protocol similar to MIL-STD-1553 running in the 5-10 Mhz
range would be useful. The length of these extensions would
be less than 15 meters.
·
The interface crates were designed and built by us in thelate 1970s. The backplane uses a byte-wide multiplexed
protocol on which we transfer one address byte and two databytes. Since it is a non-standard bus, there is no way to use
commercial circuit boards. Producing more crates is very
expensive and labor intensive.
There are no facilities for connecting a terminal or acomputer in the tunnel. This makes testing and troubleshooting very difficult We either walk back and forth to thenearest terminal or use the building public address system tocommunicate with someone at a computer.
The interface from the VAX computers to the MPM isrelatively slow. This is due to the fact that the VAX does nothave the ability to directly map the entire address space of theMPM. The system uses a set of address and data registers
which are located in the Qbus I/O space. To access the MPM,
one must first load the desired address into the address
register, then transfer the data by reading from or writing to
the data register. Since the Qbus has only a 16 bit data path,four Qbus operations are required for each MPM operation.
An MPM access requires 12 µsec.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD03

ill. HARDWARE
A. High-Level Computers
CESR-B will probably use VAX computers for the major
high-level functions. The features of the VAX are that they
provide a reasonable development environment, they support
priority scheduling of processes, and we are very familiar withthem. We have shown that the control system operates
comfortably on a VAX, and we expect that the heavier
demands of CESR-B can be met by the newer generation
VAXes.
As VAX performance improves, the inability to make amemory-mapped interface to the MPM becomes more of abottle-neck. There is a two-stage plan to address this. First.
we will make a 32 bit interface so that setting up the address
register and moving the data becomes two operations, insteadof four. If even more performance is needed, we will copy theread-only portion of the database into the VAX memory. The
VAXes will be clustered to facilitate disk sharing.
There may be other types of high-level computers for
special functions. Any computer that we can plug circuitboards into can be interfaced to the control system.

B. Multi-Port Me1Tl()ry System
The multi-port memory (MPM) will most likely be a
VMEbus based system, although the Futurebus and any othercontenders will be investigated. The MPM contains the RAM
used for the database and for message passing. It also contains
special hardware which is used to enhance the multi-processor
aspects of the system. It can support up to 16 interfaces tohigh-level or bus control computers.
The system controller in the MPM is supposed toguarantee that under normal conditions no processor has to
wait more than 4 µsec for a transfer to complete. This is tosatisfy the bus-timeout requirements of the high-level computers, but it means that if the full complement of 16 processors
are connected to the MPM, each bus operation must finish in
250 nsec. Several things are done to achieve this. No
processor can own the bus for more than one operation. Thereis neither read-modify-write nor block-mode capability. The
system controller contains a special 16-way round-robin arbiter.
This uses wiring added to the backplane which provides
individual bus request and bus grant lines for each processor
interface. The timeout circuit is adjusted according to theneeds of the slowest slave device, which is the memory, andmust account for the actual access time plus any dead-timefrom error correction or memory refresh. In CESR, it is set fora 2 µsec period.
CESR uses about 3 Mbytes of a 4 Mbyte RAM board. It
is error-correcting memory with a cycle time of 400 nsec. We
discovered that the cycle time is more important than theaccess time in a multi-processor system. One memory boardthat was supposed to be fast malfunctioned if consecutive
accesses occurred too close together. We expect to use

S03SRD03
112

Status Reports: Design/ConstructionICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD03

The control bus interface communicates with the interface
between 16 to 32 Mbytes of RAM for CESR-B. The perforcrates around the lab. The details of this interface will depend
mance of most modem RAM boards will be adequate.
Semaphores are provided for controlling access to shared on the design of the control bus itself.
data areas. The semaphore is a hardware test-and-set register.
If the semaphore is not owned, a read operation returns a rero D. Imerface Crates
and sets the semaphore to one. If the semaphore is owned, aInterface crates will be distnbuted throughout the tunnel
read operation returns a one. Writing resets the semaphore to
zero. There is one semaphore for each longword (4 bytes) of and in the control room. In the tunnel, there will be 4 control
RAM. This simplifies assigning semaphores. One just adds busses, each with 16 crates. The crates will be configured so
a fixed offset to a RAM address to access the semaphore as to maximire the effect of the parallel operation of theassociated with that address. The semaphores are implemented BCCs. This will involve two busses in each half of the tunnel,
with a PAL and static RAMs. A 1 Mbit SRAM can make with crates alternating between the two busses.
The interface crates will use commercial VMEbus
enough semaphores to cover 4 Mbytes of RAM, so it is easy
to provide a sufficient number. Semaphore cycle time is 100 backplanes running the standard VMEbus protocol. At aminimum, they will support short (16 bit) and standard (24 bit)nsec.
The FIFO board is provided for passing messages addressing with 1 Mbyte of address space per crate. Databetween processors. A single operation can send a message to width will be 16 bits. We may choose to support long (32 bit)any number of processors. The FIFO also provides a queue to addressing and 32 bit data.
The interface crates contain 1/0 devices which we would
manage multiple messages to the same processor. The message
passing protocol is defined so that the FIFO cannot overflow. like to map into the address space of the bus control computSpecial wiring is provided so that an interrupt can be generated ers. The crate controller, which interfaces to the control bus,when a processor's FIFO contains a message. A processor can should be a simple design. We do not plan to have a generalalso poll a status register to detennine if there is a message. pwpose processor board in each crate.
By using a commercial bus we will be able to buy circuit
FIFO cycle time is 150 nsec.
boards for many functions. However, we will most likely
design and build our own interfaces for the more common
C. Bus Control Computers
functions. This will allow us to get exactly what we need,
The BCCs transfer data between the MPM and the without too few or too many features. Maintenance will be
accelerator hardware over the control bus, performing a variety simplified since we will use a consistent design for the busof operations on the way. They are supposed to complete each interface logic.
transfer request as quickly as possible, then wait for anotherWe want to support geographical addressing, but thisrequest. The computers contain interfaces to the MPM, the requires an extension to the VMEbus specification. Our plan
control bus, and, in some cases, the CESR Xbus. CESR uses is to divide the short address space between 16 backplane slots,
68020 CPUs and CESR-B will probably use the same family. yielding 4 kBytes of address space per slot We will use four
Each computer runs a single common program; there is not pins on the VMEbus P2 connector. On the boards that weeven an operating system on them. The program is written on design, these pins will be used to match address bits
the VAX in 'C'. compiled by a cross-compiler, and down- [A15 ..A12]. Commercial boards and designs that require more
loaded into the MPM. Bootstrap code in the BCCs moves the than 4 Kbytes of address space will use the standard (24 bit)addressing mode, with switches or jumpers on the board.
code from the MPM to local RAM and starts execution.
Under normal load, the CESR bus control computers are
We will also investigate the issues involved with live
idle 85% of the time, which means requests are usually insertion.
handled immediately. CESR-B will add two more.computers
to handle the additional equipment, for a total of seven. E. Control Bus
Boards with 68040 processors should be able to provide the
CESR-B control system with enhanced perfonnance appropriThe control bus is a data highway between the interface
ate to the heavier load.
crates and the bus control computers. We have not decided
The MPM interface passes memory references that fall how to implement this connection. The speed and performancewithin a particular address range on to the MPM. The BCCs should be as good as or better than the Xbus used in CESR.
are in the same physical location as the MPM. In CESR, we This bus has about 4 µsec of protocol overhead plus a rounduse a 32 bit, multiplexed, single ended connection between the trip propagation delay of about 3.5 nsec per foot It uses
BCCs and the MPM. It has an overhead of 300 nsec. For differential data transmission for noise control and parity for
CESR-B, we will provide the same functionality, probably with error detection. At a minimum, we need to transfer 24 bits ofthe same type of interface.
address, 16 bits of data, plus some control signals. The three
The Xbus interface drives the control bus used in CESR. options under consideration are a fully parallel system, an
There are some places where CESR-B might use the same address/data multiplexed system, and a serial system.
hardware as CESR, for instance in the LINAC or the Control
The parallel system is logically the simplest. We would
Room, so an Xbus interface is required.
just need to buffer the address and data lines of the BCC.

S03SRD03
Status Reports: Design/Construction

113

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 Publishing

Protocol time could be less than a µsecond and throughput
would be limited by propagation delays. The drawbacks are
the amount of cabling and the number of connectors and bus
receivers. Forty wire pairs are required just for the addressand data signals.
The multiplexed system, where the address and data
signals share the cable, is almost as simple as the parallel one.
The receiving boards would need an address latch, but fewer
receiven. Another µsecond would be added to the protocol
time for the address transmission phase. It still needs inexcess of 30 wire pairs, so the cabling is not trivial, but it isa one.time process. There are commercial products that could
satisfy our needs.
A serial system requires only a single conductor. It could
be a fibre which would provide noise immunity. Cabling
would be simple. The disadvantages are speed and electronics
complexity. Moving more than forty bits of data in 4 µsec
indicates that the data rate would need to be in excess of 10
Mhz. Serial-to-parallel conversion would be needed at bothends. We are looking at some FDDI chipsets which would
simplify this type design.

update rates (> lOHz) than can be handled by the bus control
computers. These include beam position monitoring, beam
lifetime monitoring, the collision assurance system, andfeedback control equipment. These systems interface to thecontrol system via a shared memory and only transfer data thatis needed by the high-level computers. An ethemet will be
provided in the tunnel for maintenance functions, such as
downloading and debugging.
The GPIB is supported by an interface in one of the
BCCs. We do not have any CAMAC plans, but if needed, it
too can be driven by a bus control computer.

doi:10.18429/JACoW-ICALEPCS1991-S03SRD03

F. Control Bus Extension
The control bus extension allows designers to build acontrol system interface into their systems and eliminates theneed to bring many analog and digital signals to the interface
crate. The extension will provide up to a 4 kbyte address
space, which may be shared between several remote devices.
The choices for a bus extension are the same as for themain control bus. Minimizing congestion in the tunnel byminimizing the number and size of the cables and connectors
makes a serial protocol highly desirable. We are looking at
implementations using MIL-STD-1553, 16 Mbit per second
token ring, high-speed UARTS, and TAXI chips.

G. Graphic Display System

IV. DATABASE
The database contains all of the infonnation required todefine the accelerator hardware and to communicate with it.
The heart of the database is the Name Table. It contains
an entry for each node in the control system, where a node isa grouping of related hardware or software entities. The nametable entry for each node contains a 12 character mnemonic
name, infonnation about how many elements and properties thenode has, and pointers into the data area for each property.
Properties include control bus addresses, scale factors, and raw
and processed data. There is also infonnation about which
BCCs are used for a given node and the type of processing thatis perfonned on the data.
Additional data structures are the hash table, the linktable, the request packet area, the request packet address table,
and the data area. These structures will be described by wayof looking at a typical operation.

V. TYPICAL OPERATION
An example of a common operation is reading thequadrupole magnet currents. The application program requests
data by making the subroutine call:

call vxgetn('CSR QUAD CUR' ,numl,num2,readout_vec)
The graphics display system will provide each high-levelcomputer with direct access to video displays. There will be where 'CSR QUAD CUR' is the mnemonic name for theat least 4 color display channels and 16 monochrome channels. CESR quadrupole magnet current node, 'num l' and 'num2' are
The channels will be distributed throughout the lab through our the first and last elements of this node that the user wants tovideo distribution system.
read out, and 'readout_vec' is an array where the data will be
There is a large FIFO connected to each computer. When returned. This subroutine, like most of the control systema program needs to update a display, it allocates the FIFO and routines, will not make any subroutine calls. It will directlysends its data. Aside from the appearance of the graphics, communicate with the MPM. · We will go through the sethere is no acknowledgement that the data has been transferred. quence of operations perfonned by this subroutine and show
The high-level computer doesn't have to wait.
how the hardware, software, and database function together.
We will be investigating X-tenninals. In particular, we Perfonnance measurements based on CESR will be provided.
will look at their response time (can we tum a knob and havea reading on the screen track the changes?) and the amount of A. Initialization
computer resources that they use.

H. Special Function Hardware
Some applications require a dedicated processor. Thesesystems either handle large amounts of data or need higher

The VAX computers cannot directly map the MPM, butinstead use interface registers. The VAX to MPM interface
provides 32 sets of registers. When the VAX is booted, theVMS program 'SYSGEN' is used to create 32 dummy devices,

S03SRD03
114

Status Reports: Design/Construction

114

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

ICALEPCS1991, Tsukuba, Japan

one for each register set. With this technique, the operating
system handles allocation and cleanup. A program allocatesa set of registers and owns them for the duration of its
execution.
The SUN computer can directly address the entire MPM
address space, so its programs simply use pointers. The
mapping registers must be initialized at boot time.
The program also needs to allocate a Request Packet. It. does this by reading the semaphores associated with theRequest Packet Address Table. When an unowned semaphoreis encountered, the program records the number and address of
the Request Packet.

Table. The Hash Table entry, which is a pointer into theName Table, is retrieved. The requested name is comparedwith the name found in the name table. If they match, thenthe search has been successful. If they do not match, then the
Link Table, at the same offset, has the index of a new Hash
Table entry. The name comparison is repeated.
In CESR, with over 900 nodes in the Name Table, thenames will match on the frrst try 90% of the time. No lookups
require more than three tries. A name table lookup requires
100 µsec.

in the 'start' entry. Since there may be several bits set, asemaphore must be used to guarantee that only one computerat a time is changing a bit.
From the Request Packet, the computer gets the nametable pointer, the element numbers, and the operation mode.
It verifies that all database pointers required for the operation
are valid. It uses an entry in the database which specifies thefirst and last elements that this computer handles to modify theelement numbers from the request Packet This keeps thecomputer from spending time trying to transfer data related toelements controlled by another computer.
Once all of the checking is complete, data movement
begins. The control bus address of the next element isretrieved from the database. If the address indicates that theelement is controlled by this computer, the raw value ofcWTent is read over the control bus from the magnet and stored
in the database. If the element is controlled by another BCC,
then this computer goes on to the next element.
Using parameters from the database, the raw value is thenscaled and offset. The final result is written to the database.
The time and status of the operation are also stored. Error
information, if any, is saved. The process continues until thelast element is done. Notice that other BCCs may be working
on this request at the same time.
After all of the elements have been processed, thecomputer clears its bit in the 'done' entry of the Request
Packet and in the 'error' entry (if there were no errors).
Again, semaphores are used when changing bits.

C. Set Up and Deliver Request

E. Retrieve Status and Data

The Request Packet owned by this process is filled in.
The program inserts the Name Table pointer, the number ofthe fust and last elements desired, and the type of operationthat the BCC should perform. It also inserts 'BCCs used' bitfield, which identifies which BCCs may be involved. This
piece of data is inserted in four entries of the Request Packet;
the 'used', 'start', 'done', and 'error' entries.
The 'BCCs used' bit field is combined (ORed) with thenumber of the Request Packet. The result is written to the
FIFO board, which signals the appropriate BCCs that there iswork for them. The logic on the FIFO board causes thenumber of the request packet to be written into all of the
FlFOs which have a bit set in the bit field.
At this point, the program waits for the bus control
computers to move the data. Programs can either go into a
wait loop or they can hibernate. The choice depends upon the
programmer and how many elements are involved. Most
programs hibernate, which contributes to the efficiency of thehigh-level computers.

The high-level computer reads the 'done' entry in therequest packet. When all' of the bits are zero, then all of thebus control computers have finished. If the 'error' entry is all
zeroes, then there were no errors. The data is read from thedatabase and moved into the user's array.
In CESR, elements I through 49 of the 'CSR QUAD
CUR' node are on one control bus and elements 50 through 98
are on another. The execution time of the 'vxgetn' subroutine
to read the current from one magnet takes 700 µsec. Reading
49 currents requires 4780 µsec, or 80 µsec per element. The
bus control computers use 50 µsec and the high-level computeruses 30 µsec. When reading all 98 elements, the advantage ofthe parallel operation of the BCCs becomes obvious. It takes
6200 µsec. The extra 1420 µsec is just the time that the highlevel computer needs to move the data for the additional
elements into the user's array.

The mnemonic name is hashed by exclusive ORing thethree longwords of the name and dividing the results by thesize of the Hash Table. This produces an index into the Hash

VI. REFERENCES(11

D. Bus Control Computer Operation[21

The BCCs are normally executing in a loop, checking
their FIFO to see if there is a message. When there is one, theBCC reads the Request Packet number from the FIFO. In the
Request Packet, the computer clears the bit which identifies it

CESR/CLEO Staff,"Conceptual Design for a B Factory Base~on CESR," Cl.NS 91-1050, 1991.
C. R. Strohman and S. B. Peck, "Architecture and Performanceof the New CESR Control' System," in !he Proc. of the 1989
IEEE Particle Accelerator Conference, Chicago, IL, March

1989. pp. 1687-1689.

S03SRD03
Status Reports: Design/Construction

115

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

B. Search the Name Table

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD03

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, Japanthat the control system would use workstations for the operator
interface, single-board computers to control the front-end
electronics, and a network consisting of either Ethernet or
Token-Ring. The APS control system today is remarkably close
to the initial design concepts due to rapid performance gains incomputing workstations, low cost network connections, both
Ethernet and Fiber Distributed Data Interface (FDDI), andavailability of real-time operating systems for the front-end
computers.
Figure 1 shows in schematic form all major components andtheir relationships. The current design includes about 45
distributed microprocessors and five console systems, which
may consist of one or more workstations. An additional 70
Input-Output Controllers (IOC's) will be used to control theinsertion devices, front ends, and beam lines.
The operator interface (OPI) is implemented with a highperformance graphic workstation and uses an X-Windows based
Gill. Standards play a large role in the selection of the OPI since
the hardware, operating system Gill, and network must becompatible. The ideal control system design would be vendor
independent in all of these areas. To make the APS control
system vendor independent we chose to use standards whenselecting these components.

B. Operating Systems/Workstations
At the Europhysics Conference on Control Systems forExperimental Physics [4] in October of 1987, discussion panels
ran late into the night with the "religious" arguments for the
choice of UNIX or VMS as the operating system of choice forcontrol systems. There where convincing arguments presented
by advocates of both sides of the discussion. Four years later theargument has been settled, not because either of the opposing
sides was won over by a technical argument but because of
market forces. The development of the the Reduced Instruction
Set Computer (RISC) processor has resulted in UNIX
dominating the workstation market.
RISC is a recent innovation in computer architecture(although some people claim that the PDP-8 was a RISC
machine). The study of computer instructions and their relative
frequency of usage revealed that most of a computer's time isspent in the execution of a small subset of its repertoire. RISC
architecture takes advantage of this fact by streamlining theexecution of this subset and by implementing the less used andmore complex instructions with combinations of the (now fast)small set of instructions. Since there is now a small set of simple
instructions, parallel "pipelining" can be used to increase
execution speed. In this method more than one instruction can be
executed simultaneously by staggering in time the various
suboperations. Some processors can even average more than one
instruction per clock cycle.
The converse to RISC architecture is Complex Instruction
Set Computer (CISC) architecture. Most computer architecturesdeveloped prior to 1980 are of the the CISC type, a typicalexample being the VAX. Today there is a five-to-one advantage
in raw MIPS (millions of instructions per second) for RISC
devices. This should be discounted to some degree since RISC
requires more instructions to perform some types of operations,but an advantage of even two-to-one on reasonable benchmarks
is obtainable.
The UNIX operating system itself was originally developedby Bell Telephone Laboratories as a word processing tool, but it
was soon modified to support software development tools andfmally grew into a full-featured operating system. UNIX waswritten in the "C" language, also developed at Bell Telephone
Laboratories. The keys to UNIX's success are that it is extensible
and it is written in a portable language. These attributes allow
the user to make enhancements, remove features, and tailor
UNIX to specific needs. One indication of this is the fact that theUNIX operating system is available for microprocessors as wellas supercomputers. Thus, if a start-up company chose UNIX as
its operating system and made the changes necessary to support
its chosen computer architecture, any existing software that ran
under UNIX could be recompiled to run on their computer. In
this way new computer architectures can be introduced withready-made operating system software and trained users.

S03SRD04
Status Reports: Design/Construction

117

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

A. Standards
The definition of the word "standard" used for the purposesof this paper is as follows: "Something established by authority,
custom or general consent as a model or example'' [2]. Past
practice at large laboratories has been to invent almost
everything that was needed to build a control system.
Accelerator control system groups have built computer systems
and designed networking schemes. Of course there were goodreasons for this - the laboratories were often pushing the leadingedge of electronic and computer technology and the required
devices and techniques were not available on the open market.
This picture has greatly changed. Computer technology has now
spread into every comer of our lives. There are literally tens of
thousands of companies inventing new uses for computers andpushing the limits of technology. This has had a very positiveeffect on control system design as the effort required to build acontrol system can now be redirected towards control andaccelerator details rather than details associated with building acomputer or computer network. In the Proceedings of the Second
International Workshop on Accelerator Control Systems [3] heldin October of 1985, no discernible trend can be observed incontrol system design. This contrasts with the sense one receives
from reading the titles of the the papers presented at the 1991
Particle Accelerator Conference. These titles show a groundswell towards what could be called a generic control system. The
generic system consists of workstations running UNIX, a
network, and front end processors running a real time operating
system. We now find standards being followed at all levels ofcontrol system design.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD04

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

Because of the development of RISC processors and theexistence of UNIX, nearly all computer manufacturers aredeveloping and marketing RISC-based computers andworkstations which use - the UNIX operating system.
Competition is driving perfonnance up while keeping prices low
and this trend is likely to continue. There is still a market for
CISC architecture computers and operating systems such as
VAXNMS, principally due to the installed base of application
software and the steady iinprovements made to the hardware byvendors.

system: Allen Bradley, GPIB, and BITBUS. The Allen Bradley
YO subnet uses the 1771 series YO modules to provide basic
binary and analog I/O support for the APS control system. Allen
Bradley is a inexpensive and rugged standard for industrial
control systems. Copper and fiber optic basedmultidrop subnets
are available for this eqnipment
Laboratory test and measurement equipment often use the
GPIB standard as an interface to an external control system. This
multidrop standard presents some serious challenges andpotential problems to the system designer. GPIB has a distancelimitation of 20m which requires the instruments connected tothe bus to be in close proximity to the IOC. In addition, thesignals within the GPIB cable are not balanced and thus
susceptible to EMIIRFI noise and ground spikes. Signal transfer
and isolation techniques are not part of the GPIB standard andalthough commercial equipment is available to extend the
distance of a GPIB interface, it is prohibitively expensive.
BITBUS provides a method of high speed transfer of shortcontrol messages over a multidrop network. The BITBUS
subnet can be used as a method for remote, single point I/O aswell as a gateway for remote GPIB and RS232 signals [5]. A
differential, opto--isolated, wired subnet is the BITBUS
standard; however, a multidrop fiber optic network has beendeveloped for BITBUS at the APS.
D. Networks and Protocols
Argonne uses Ethernet as the intra-laboratory network.
There are backbone cables in the individual buildings with
communication between buildings presently done via theLanmark PBX system. Intra-building FDDI will be available
within 6 months. The control system development computers arepresently sharing the APS Ethernet backbone with all other APS
computing needs (55 Sun Workstations, a VAX Cluster with six
members, 18 terminal servers, 40 PC's using Pathworks, and 40
Macintosh systems). Two test stands and six developmentIOC's
are running in this environment without experiencing networkinduced problems. A Network General Sniffer is on line at all
times should the need arise to diagnose an apparent problem. In
the APS facility, however, we plan to use FDDI with Ethernet
branches as performance needs dictate.
The central feature of both the OPI and IOC software designs
is the protocol for connections between software modules for the
purpose of exchanging information. This protocol is called
channel access [6] and is built on the TCP/IP Standard. TCP/IP
is an integral part of every UNIX-based workstation well as
being built in to VxWorks, the real-time operating system. Whenan OPI application program needs to connect to a process
variable located in an IOC, it issues a broadcast over the networkand the IOC in whose database the requested process variable
resides provides a response. A socket-to-socket connection isestablished and thereafter efficient two-way communication
takes place. IOC-to--IOC channel access can take place toexchange inter-IOC information. It should be noted that the OPI

These reasons seem to make it obvious that the operating
system ofchoice for any control system to be delivered in themid
1990s will be UNIX. The bottom line for APS is the fact that theUNIX operating system provides the control system a large
measure of vendor independence. We have the OPI software
running on SUN 4 and Digital EquipmentDSSOOO workstations
and expect to port the system to other vendors' workstations.
The GUI "wars" now being fought in the press and on
workstations provide a very good reason to conform to standards
when writing the OPI software. APS is developing applications
using the Open Software Foundation's Motif toolkit We areextensively testing the software against the two major window
managers Motif and Openlook.
C. Front End Systems
The IOC, or front-end electronics, is implemented withsingle-board computers of the Motorola 680XO family,
packaged along with signal interface cards in VME and VXIform factor crates. Motorola 68020 processors are used in initialconfigurations with 68040 processors planned for most future
configurations. A real-time operating system, VxWorks fromWind River Systems Inc., is used to provide multitasking, highperformance front-end software. More than fifteen VME
input-output modules are currently supported. These modules
include binary input and output, analog input and output, motor
drivers, counter timers, and subnet controllers. More modules
will be supported as they become available and are required.
Most information preprocessing is perfoimed at this level with
only engineering units sent to the OPI for display. Signal
monitoring can be set up to communicate only on signal change
or limit-breaching or at some preselected rate. Local sequential
and control-loop operations can also be performed. In this way,
maximum benefit is gained from the many IOC processors
operating in parallel. This is one area where APS is vulnerable tocomplications which would arise if the vendor of the real-time
software failed. When the posix standard for real-time systems
becomes a reality and most real-time vendors conform to thestandard, our estimate is that it would take about two months of avery knowledgeable programmer's effort to change real-timekernels.

In addition to local IOC I/0, subnets are utilized to interface
remote points where an IOC may not be present to a distant IOC.
There are currently three supported subnets in the APS control

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD04

as

S03SRD04
118

Status Reports: Design/Construction

needs no knowledge of the location of the desired process
variable, only its name. Figure 2 shows the relationship of thechannel access software in both the OPI and IOC systems. It also
illustrates bow a mouse and screen "slider'' are used tocommunicate, through channel access software at both ends,
with aD-A convertor. Similarly, A-D convertor output finds its
way to a screen.
The database which defmes all IOC channel connections andproperties is distributed over the many IOC's and downloaded at
IOC boot time along with the operating system and the particulardevice driver software modules required by each IOC. The entire
database is centrally maintained and configured with a UNIX
workstation which, of course, can be any OPI. Figure 2 shows
the downloaded location of the IOC database in the overall data
flow.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD04

Operatol' Interface (OPI) Workstation~
I. . _:r_~_~y__. .~ -

i

x

I

I

:

Mouse

·
I

. .... i o I

I

t

•

I

•

E. X-Windows

I

In the X-Windows client-server paradigm, an application
program is divided into the "client" (which provides thecomputation and logic of the program) and the "server" (which
provides the interaction facilities for the human operator oruser).
In the APS control system, both client and server are
implemented in processors at theOPI level. The client and serverneed not reside in the same processor so that, for example, a
specialized parallel processor may provide client services for amore common workstation server or X-Window terminal. In
this way, the OPI's will be able to have windows open to clients
operating both locally and on other processors on the network.
F. Application Software

Application software comprise those programs which theoperator or physicist invokes to provide a feature or service notprovided by the equipment operation level of the control system.
An example would be the software required to provide a local
bump in the orbit These programs can be of two general forms.
Tue first is a control panel which is created during a session witha display editor (see Figure 2, upper left). Graphic tools such as
buttons, sliders, indicator lights and meters, and graph paper are
selected and located on the panel. Static entities which can beused to depict the physical system, such as piping diagrams, areadded where appropriate. Connections to IOC channels are
specified at this time and the proper drawing list and action code
are automatically generated. When complete, the panel is called
up for execution, the channel access calls are made, and thecontrol panel is now "live." No actual code is written orcompilation made, aside from that originally involved in thetools themselves. The software provides calculation records andallows cascading of physical inputs and outputs with thesecalculations. This allows very complex operations to be
designed. The second form of application program is that of
employing classic in-line code generation. In this case standard
entry points are provided to the same graphic and channel accesstools. Using this approach, an existing code can be adapted to ourIr•••••••••••, ....... ..

..•NETWORK

Cllannel Access Soft\\'areI: Database

ADC

Input-Output
Controlle.. (IOC)DAC

Figure 2. APS Control Environment

system by calling the channel access code and displaying theresults using either traditional line.-by-line or graphical output.
All software is being de.veloped under UNIX, including thatfor the IOC's. In this way, windows can be opened
simnltaneously at an OPI for software development. actual
run-time applications, database configuration, electronic mail,etc. This streamlines software development. database servicing,and system troubleshooting.

ill. INTERLABORATORY COOPERATIONAt the Accelerator Control Toolkit Workshop [7] in 1988 agroup of people responsible for accelerator control systems atlaboratories throughout the world spent a week discussing
various aspects of control systems. One of the topics discussed
was the development of "tools" which could be used at morethan one laboratory. Subsequent to this meeting we decided that
the APS would pursue the idea of looking at existing control
systems with the aim of determining if they could be usedatAPS.
After much discussion we decided to pursue collaboration with
Los Alamos National Laboratory (LANL). Discussions were
held with the developers from LANL and it was decided thatAPS
would send a representative to LANL who would use the system
to develop an application which would be useful to LANL. One
of us (Kraimer) spent a summer at LANL developing thesoftware to control a magnet measuring facility. Upon bis return
be imparted bis positive impressions of the system. We then

S03SRD04
Status Reports: Design/Construction

119

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 Publishingdecided to complete an in-depth study of the software. He
sequestered himself in bis office with the software listings. As he
gained understanding of the system he gave tutorials to the APS
contro!s group staff on the internal design of the software.
Further group discussions led to the decision to try to form acooperative development team with LANL. M. Knott (ANL) and
M. Thout (LANL) proceeded to develop an agreement that has
led to the co-development of the Experimental Physics andIndustrial Control System (EPICS). The paper entitled" EPICS
Architecture" [8] by L. R Dalesio, et al. presented at thisconference provides a detailed look at the features of EPICS.

and process ICC-generated errors. We are developing low cost
IOC's based on single-height VME modules as well as Gespac
G64 modules. VXI crates using the standard VME processors
and network boards are currently operating. On the OPI side weare running on both the SUN 4 and DEC 5000 platforms and wewill soon port the system to Hewlett Packard 700 Series
workstations.

doi:10.18429/JACoW-ICALEPCS1991-S03SRD04

V. REFERENCES[1]

M. Knott, G. R. Gunderson, F. R. Lenskzus, W. P.
McDowell, "Control System Features of the Argonne
6GeV Synchrotron Light Source," IEEE Transactions on
Nuclear Science, Vol. NS-32, No. 5, October, 1985.

IV. CONSTRUCTION STATUS OF APS AND THE APS[2] Webster's New Collegiate Dictionary, Merriam, 1977.

CONTROL SYSTEM

Construction is proceeding rapidly on the physical structureof the APS. As of this date (late October 1991) the linac andinjector buildings have steel erected, the concrete for the linac
tunnel and positron accumulator ring vault is in place, the control
center has reached the first floor level, and the foundations are inforthe first section of the storage ring building which will be used
as an early assembly area and magnet measuring facility. Barring
unforeseen construction delays, the linac and control center arescheduled for occupancy in April of 1992.
The APS control system is now actively supporting two test
stands, rf and linac. Work on these test stands started in 1989. In
their first implementation they used a predecessor version of the
OPI running on a VAXStation under the VMS operating system
and a predecessor of EPICS called GTACS (Ground Test
Accelerator Control System) for the IOC. As work on a UNIXbased OPI and EPICS progressed, both test stands converted to
the UNIX OPI software and EPICS. The APS rf test stand wasreported at the Real TlDle '91 Conference [9]. Two IOC's arebeing used to implement the linac functions: one for beamdiagnostics and the other for control. The test stands have proved
to be highly beneficial to both the controls group staff and thelinac and rf systems development team members. The controls
group has gained experience in using the control system as well
as received suggestions for changes and improvements. The test
stand staff has been able to concentrate on linac and rf design
details without developing their own control system. The only
way provided to remotely run the test stands is via the control
system.

Progress in the development of EPICS software iscontinuing. An alarm handler [10) has been developed and isbeing optimized. We are continuing to add device and driver
supportfornew hardware modules as well as develop new record
types such as pulseTmin, pulseDelay, etc. A graphical dat.abaselink display tool is being developed as a way to document
databases and requirements are being developed for asystem-wide database and a system-wide errorhandler to accept[3) Accelerator Control Systems, Proceedings of the Second
International Workshop on Accelerator Control Systems,
NuclearlnstrumentsandMethods, Vol.A247,No.1, 1985.
[4] Proceedings, Europhysics Conference on Control Systems
for Experimental Physics, CERN Report 90--08, 1990.
[5] N.D.Amold,G.J.Nawrocki,R. T.Daly,M.R.Kraimer, W.
P. McDowell, "J/O Subnets for the APS Control System,"
to be published in the Proceedings of the 1991 Particle
Accelerator Conference, San Francisco, California, May
6-9, 1991.
[6]

J. 0. Hill, "Channel Access: A Software Bus for the
LAACS," in Accelerator and Large Experimental Physics
Control Systems, D. P. Gurd and M. Crowley-Milling,Eds., ICLAEPCS, Vancouver, British Columbia, Canada,
pp. 288-291, 1989.

[7] Accelerator Automation Application Toolkit Workshop,
Sponsored by AT Division and MP Division, Los Alamos
National Laboratory and CERN, Geneva, 31 October - 4
November, 1988.
[8] L. R. Dalesio, M. R. Kraimer, A. J. Kozubal, "EPICS
Architecture," to be presented at ICALEPCS '91,
Tsukuba-shi, Ibaraki, Japan, November, 1991.
[9] R. T. Daly, F. C. Vong, M. R Kraimer, "The APS Radio
Frequency Test Stand Control System," presented at Real
TlDle '91, Computer Applications in Nuclear Particle andPlasma Physics, Julich, Germany, 25-28 June, 1991.
[10] M. R Kraimer, B. K. Cha, M. D. Anderson, "Alarm
Handler for the Advanced Photon Source Control System,"
to be published in the Proceedings of the 1991 Particle
Accelerator Conference, San Francisco, California, May
6-9, 1991.

S03SRD04
120

Status Reports: Design/Construction120

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-S03SRD05

each Ethernet segment to approx. 4.5 kilometers.
The wiring HUB is the central point for passive network
components, i.e. the backbone optical fibres that link all the
HUBs together in a circular structure around the storage
ring tunnel. It also acts as the termination point for all
star wired fibres that are attached to the LOBES.
When installing the circular backbone, provision for 10
independent rings has been made, out of which four will
be used initially. One ring functions as the main control
segment, to which all upper layer processors are connected.
There are three dedicated process servers that operate as
network gateways to the other three rings. The latter areused as process segments to which all middle layer VME
systems are connected. Devices in the field are either connected directly to them or accessed through the multidrop
highway.
Response times on a heavily loaded Ethernet become
quasi stochastic. Having this in mind, the whole system
was designed in a way to provide maximum flexibility in
distributing sinks and sources of network traffic. This isaccomplished by fiber optic patch panels situated by the
HUBs. By simply crosspatching between panels, any processor can immediately be connected to any of the independent rings comprising the backbone. Upgrading the
backbone to FDDI would be another, although much moreelaborate, remedy against network congestion.

Figure 1: Overall Layout of Control System and Networks

LAN standard and the TCP /IP protocol suite. The network is constructed using 50/125µm multimode graded index optic fibres4 for cabling, that will allow a later migration to FDDI.
. Four networking centers are located around the storage
rmg tunnel, a center comprising a "NODE" and a wiring"HUB". A NODE is the location that acts as the convergent point for IEEE 802.3 compliant active devices e.g. anactive star. To the NODE are attached "LOBES" which
are configured on a star wired topology. A LOBE is the
remote system connected to a NODE, and in this case it isa remote "transceiver" attached by a standard AUis cable
to a VME crate, process computer, graphics workstation
or fanout unit.
For the active stars at the NODES, the "Lannet Multinet II" system was chosen for its ability to operate in a single chassis and support up to four independent backbone
bus's. In addition all backbone fibre optic links are run ina synchronous Ethernet mode. By using this mode it ispossible to install more than the "four'' repeaters that restricts standard asynchronous Ethernet systems, with therestraining factor being, the round trip delay that limits•Bandwidth specified at 850nm
1300nm> 700MHz•km& Attachment Unit Interface> 500M Hz * km and at

4

Computers

4.1

ConsolesThe standard console in the control room will be an HP
Apollo 9000 Model 720 workstation with local disk to holdthe bootable image of the operating system and to provide
local swap space. File systems containing control systemand physics applications software are remotely mounted 6
from the process servers. Currently we are running 5 consoles in the main control room.
In addition to that, RISC based X Window graphics
terminals, like the HP 700/X familiy, that are served by
the process servers, will be used as console devices. Theirideal usage will be that of "remote" consoles. They will beoutside of the control room but plugging to the backbone's
contr_ol segment. Their main purpose is to give scientists,
workmg on an experiment, the possibility to control the
movements of their "insertion device" by themselves.

4.2

Process Servers

As process servers the HP 9000 Series 800 Model 842 and857 midrange super-mini computers were selected. Thereare currently three of these machines in the system. System features are:• high relia.bility;
6
currently we a.re using SUN's NFS that we hope to replace by
OSF's DCE

S03SRD05
122

Status Reports: Design/Construction

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

ICALEPCS1991, Tsukuba, Japan• 29 Mips; 6.9 DP 7 Mflops; CMOS RISC technology;• internal disk storage: <2.68 Gbytes;• I/O bandwidth 21 Mbytes/sec;• integrated DAT8 unit: 1.3 Gbytes capacity;

VME Systems

All VME systems have an identical base configuration.
This comprises a CPU with Motorola 68030@ 20 MHz,
4 Mbyte RAM, on board Ethernet adapter, and additional
512Kbyte battery backed up RAM on a separate board.
On these systems we run Microware's OS9 realtime
kernel/operating system. In addition the systems areequipped with a TCP /IP Internet Support Package providing Berkely sockets, and SUN's Network File System.
All systems are running in a diskless configuration forease of maintenance and reliability. The battery backed
512Kbyte RAM holds the OS9 real time kernel and a minimal TCP /IP configuration. When the system boots, itloads additional OS9 modules, applications, and the NFS
modules from a process server. Using NFS, it then copies
configuration files from the process server into its RAM
disc and initialises the applications. 9 Cold start-up still has
to be done manually by toggling a switch on the board's
front panel, but we are working on a remote facility.

5

Interfacing

Many of the VME systems drive fast multidrop highways.
This FBUS is not a general purpose network but implements a low cost remote input/ouput facility. It relies ona master-slave relationship, where a controller (VME based
module) drives a large number 10 of slave nodes. The nodes
comply with the G64 standard, so that full advantage canbe taken of existing interface boards from industry. The
FBUS multidrop highway is based on a synchronous serial protocol. Physical implementation uses an extremly
noise resistant Manchester encoding with transformer isolation, i.e. each node being galvanically isolated from the
7With floating-point processor, Double Precision
80igital Audio Tape
9Microware has recently started to ship the BOOTP Port Packs
for OS9. BOOTP is used to make a boot PROM with the possibility
to boot 089 directly over Ethernet, thus avoiding the battery backed
up RAM
lOup to 64 on one highway• video multiplexor11 (VME)• delay unit12 (VME)• ADC with on-boa.rd memory (G64)• FBUS master (VME and PC/ATbus)• FBUS slave (G64)• clock divider13

Unavoidably some other dedicated electronics had to be
designed to adapt some exotic devices to the standards
chosen.
Table 1 gives an overview of interfacing.

6

Software

6.1

Equipment Access

The low level system software for the distributed control
system is based on a "Client/Server" architecture. The
Client/Server technology is a simple mechanism to distribute software tasks across any number of processors.
This approach is open and object oriented, can be implemented on existing systems (eg. OS9 and UNIX), and will
be discussed in detail by a contribution to this conference
from A.Gotz.
Objects are sets of hidden data on which well defined
operations may be performed by authorized users. Associated which each object is a "Server" process that manages
the object and exports its functionality as a service. This
server-based model is implemented using "Remote Procedure Calls" 14 [5, 6). When a user process wants to perform
an operation on an object, it sends a request message to
the Server in charge of it. The message contains accesskeys, a specification of the operation to be performed, andany parameters the operation requires. The user process,11 15:1

126 channels, 32MHz resolution, 0-524 ms range

l3for RF-synchrono\18 triggers, 352MHz:32MHz
1'RPC; in our implementation we use SUN's RPO and XOR

S03SRD05
Status Reports: Design/Construction

123

123

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

highway. The data rate is up to 2 Mbits per second on
a 200m-300m long highway. FBUS can still be safely operated at a speed of 1 Mbits per second on distances of
up to 1 km and 30 nodes without repeater. The transmission medium is a flexible shielded twisted-pair cable witha characteristic impedance of 78 Ohms.
G64 and FBUS interfacing has been used for controlof main magnet power supplies, beam position monitors,
magnet interlocks, corrector magnet power supplies, andinjection/extraction elements. Other significant subsystems that include G64 crates are the system to distributethe slow timing pulses, the video cross point switch, andthe video multiplexors for fluorescent screen monitors. The
rest of devices is directly interfaced to the VME systems;
either by asynchronous serial lines or digital I/Os.
As a result of an early taken policy, to stick to industry
standards, only a few boards had to be designed by the
ESRF Digital Electronics team:

These machines are configured as network gateways between the control segment and one of the corresponding
process segments. To accomplish this, each of them isequipped with two high speed LAN adapters.
The process servers and the console workstations run
HP-UX; an AT&T System V Rel 3.0, and BSD 4.3 compliant implementation of the UNIX operating system. All
machines run MIT's X Window System, which allows applications to run as X-clients on the process servers and to
perform interactive I/O through X-servers running on the
consoles.

4.3

JACoW Publishingdoi: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

VMEI VME
crate

dig 1/0

1

20

l

48

ICALEPCS1991, Tsukuba, Japan

VME

VME

serial 1/0
8

special I/O

G64
crate

G64
analog in

6
6
2
16

15
4
3
5

84

G64
analog out
84

3

3

15

9

36
37

8
33

224

1
1
2

6

3
1
1

56
34

1

21

1

36

36

16
1
14

448
1
48

34
5
14
68
14

32
51

2050
576

2
2
4
51

3

34

41
53

75

36

9

9

17

816

82
2

102

719

254

I 224 I

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD05

3946

132

Where
Transfer Line 1
Transfer Line 2
InJect1on/Extraction
Synchr. Diagnostic
1:iynchr. Magnet
Power Supplies
Synchr. Vacuum
SY/SR slow timmg
Storage Ring
Diagnostics
Storage Ring Magnet
Power Supplies
Storage Ring Vacuum
Geodesy & Mag. Interlocks
Insertion Devices
Front Ends
X-ray BPMs
Radiation & Safety
misc. Monitoring
RF & LINAC (subcontr.)
I TOTAL

Table 1: Overview of Hardware Interfacing for the ESRF accelerator plant
known as the "Client", then blocks. After the Server has
performed the operation, it sends back a reply message
that unblocks the Client. The combination of sending arequest message, blocking, and accepting a reply message
forms a Remote Procedure Call, which can be encapsulated to make the entire remote operation look like a local
procedure call.
The lowest level of objects in the accelerator plant are
the actors and sensors (or physical devices). These objects
are "terminator objects"; they are easy to identify, andtheir behaviour can be modelled and documented.
"Device Servers" are terminator objects that operate on
physical devices. The more general term "Server" or "Virtual Device Server" covers objects on a higher level of abstraction. Objects on a higher level of abstraction can use
terminator objects to offer a given service15 .
The Device Server is an intermediary between application programs and the physical resources of the accelerator
system. It contains all device-specific code, and insulates
applications from differences between hardware. It performs the following tasks:• Allows access to the device by multiple clients. To
implement security, the server, depending on its state,
may deny access from certain clients.
• Interprets network messages from clients and acts onthem. Messages are generated by clients through
RPCs.

• Maintains complex data structures, including device
state information. Server maintained information reduce the amount of data that has to he maintainedby each client and the amount of data that has to hepassed over the network.
At ESRF the Device Servers follow the OOP 16 paradigm
and have to he implemented in a certain, fixed style. The
OOP paradigm is based on the "widget" model from theXll Intrinsics Toolkit[7) of MIT and is implemented in
ANSI C.
The control system designers have decided to implement
all important functions necessary to run the distributed

system in Servers. This includes the processes to bootand manage the system, to access the database, to handle graphics objects, as well as Device Servers to accessequipments.
According to our current state of knowledge about 53
Device Servers have to be written for the complete system.
About 50% of them are currently released. The average
size of a Device Server ranges typically between 2000-2500
lines of C code.

H>The encapsulation of lower level services into higher level services
can continue until a very high abstraction like physical machine parameters, i.e. energy, chromaticity, tune, emittance,. .. , is achieved.

l 6 0bject oriented progranuning

S03SRD05
124

Status Reports: Design/Construction

124

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

ICALEPCS1991, Tsukuba, Japan

6.2

The implementation of the resource database uses ORACLE and its powerful set of development tools. Modifications on the resource database cause automatic update ofruntime data sets, that are redundant copies of the parent
data set in the resource database.
The runtime database is a central warehouse for all sortsof temporary or transient data. It is not a medium for permanent storage. It is simply a front for permanent storage.
Only memory resident database systems can meet the demands for sufficiently short transaction times. A prototypeof the runtime database is operational and uses a Rea/Time Database Base Management System22 available on
HPs.
The runtime database can be used to alleviate congestion problems. Multiple processes can update dataasynchronously in the database. Other processes can retrieve this information aynchronously without blocking theprocess doing the updating. Since the memory resident
database profits from a much higher than normal I/O
throughput, this mechanism is used to resolve information
traffic jams that may occur.
The runtime database's prime source is a so-called Update Daemon that updates the current machine status if
a particular client requests this. The database contains
ring buffered tables to store brief histories of the results ofrequests issued to a device. Although physically the runtime database is distributed over all process servers, accessto it is transparent to database clients. On-line data canbe archived continously. Only a time window of some fiveminutes is kept in memory by RTDB, the rest of the data isdumped into the disk-based ORACLE database. An index
to these data is constructed to allow queries in accelerator
physics terms on archived data. Data can be stamped withtime or accelerator status information.
The same runtime database can also be used by applications as a mean for interprocess communication. Applications dynamically allocate "tables" of formatted data, that
can then be piped or multiplexed to other applications.
The volume of data that will be managed by the resource
database is estimated to be some lOMbytes. The wholecontrol system comprises more than 3000 devices and morethan 50000 static resources. The throughput of on-line
data at its worst is estimated to be some 40kbytes/sec. If
all data coming from the machine is stored at an intervalof a second, it would mean 12Mbytes every 5 minutes.

Database

The control system data are stored in relational databases
which manage two logical parts:• Resource da.ta.;

6.4• Runtime data.
The resource database keeps permanent data. Examples
are: start-up resources, calibrations, equipment definitions, installation- & maintenance data, etc ...
11ui
18 API

uun,

20UIMS
21 standa £or Programmer's Hierarchical Graphics System and is an
ISO standard

Applications

Application program development at ESRF has been takencare of at an early stage of the project. Usually this classof software tends to be too little and too late. To give
accelerator physicists the possibility to develop their applications in parallel with the control system software, anapplications programmer interface23 has been defined very
early and kept stable until then.
~~called RTDB

23API

S03SRD05
Status Reports: Design/Construction

125

125

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 DOIGraphics User Interface

This field of technology is in a state of tremendous innovations. Fortunately some standards exist now: Xll, andMotif. The XU-window system, or Xll, is a networktransparent window system. With XU, multiple applications can run simultaneously in windows, generating text
and graphics. Network transparency means that application programs that are running on other machines scattered throughout the network, can be used as if they wererunning on a local machine.
The core components of the OSF/Motif technology include an extensible user interface 17 , an applications programming interfaee 1s, a user interface metalanguage 19 ,and a window manager. Motif is based on the X Intrinsics, a toolkit framework provided with Xll. The Intrinsics
use an object oriented model to create a class hierarchy ofgraphical objects known as "widgets".
Both Xll and Motif, are extremely helpful but theirlibraries are complex to learn and to use for programming. Coding of applications started initially with thoselibraries, and demanded substantial efforts in becoming fa..
miliar with this new technology.
User Interface Management Systems20 (sometimes
called interface builders) are the tools which help the application programmer to design the user interface part of
the application interactively. A UIMS is generally composed of a graphic oriented editor and a code generator,and sometimes other complementary tools. There are several Motif compliant UIMS available. A few of them havebeen tested at ESRF. At present one of them has been
selected for use[S].
This UIMS drastically eases now the design of Motif. .
based user interfaces. It generates stand-alone C code
and/or a combination of Motif-compliant C and UIL code.
Synoptic drawings with selectable objects are scarcely
supported by the above mentioned tools. We therefore
work on. an implementation of a Motif compliant widgetthat uses vectorial drawings generated by PHIGS 21 • Synoptics will be generated by CAE systems like AUTOCAD
or EUCLID.

6.3

JACoW Publishingdoi: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

open connection
close connection
RPC with lOObytes
RPC with 8kbytes
RPC with 40kbytes

NFS/RPCUDP
I TCP
20-25ms
35-45msO.l-0.2ms 0.3-0.5ms
10-15ms
15-20ms
25-35ms
55-65ms
220-250ms

I

ICALEPCS1991, Tsukuba, JapanAPI
UDP
55-65ms
10-20ms
15-20ms
30-40ms

Table 2: Performance figures for RPC and API

Measurements of RPC and API performance that weachieve between a. process server and a. VME node a.re given
in table 2.
Using strictly this device access interface and the Xll
and Motif standards for interactive graphical I/O, an impressive number of physics applications have been developed in parallel with the basic control system software, andhave considerably helped to commission the booster in duetime. An enumeration of applications presently available
follows:

Access to the Device Servers is provided by a small set
of C calls. These calls allow the users to develop their applications in peace without being affected by what goes onin the Device Server software. Initially very simple Device
Servers have been written, that ran on the local host, andthat only simulated devices. These API-calls hide the complexity of Device Servers and their implementation fromusers by offering them a set of high level commands as access method. How and where the Device Server executes
the high level command is hidden. In the distributed environment this workload is spread over a number of machines.
The following functions form the basis of the Device
Server API:

Transfer line 1 & 2: These programs execute specificprocedures for step by step alignment, emittance measurement, and modelling of beam envelopes.
Closed orbit: The program performs basic control ofsteerers and bumps, beam position readout, orbit
plots, fourier analysis of orbit and steerers, and automatic orbit correction.
Booster vacuum: This program controls the vacuum
system. It allows individual device control, display of
periodically updated status, and display of pressure
profile.
Booster injection/extraction: This program allows
control of current- and timing settings of pulsed injection/ extraction elements.

• int dev_import(nallle, access, ds_ptr, error)
char *name;I• Device Server Hame •/long int access;/• Access Type •/devserver •ds_ptr; /• DevServer Handle •/long •error;/• Error Code •/Is called by the application to establish a connection to a.
Device of the specified name.
• int dev_putget(ds, cmd, argin_ptr, typein
argout_ptr, typeout, error)
devserver ds;/• DevServer Handle •/DevCmd ad;I• Device Command •/DevArgPtr argin_ptr; /• Call Parameter •/DevType typein;/• Parameter Type •I
DevArgPtr argout_ptr;/• Return Parameter •/DevType typeout;I• Parameter Type •/long •error;
Is called by the application to execute a command on thedevice. This is a "blocking" call which doesn't return until
the command requested has been executed.
• int dev_put(ds, cmd, argin_ptr, typein,error)
l$ called by the application to execute a. command on thedevice. This is an "asynchronous" call which will return
as soon as the command has been delivered to the server
or an error occurred. This call can only be used to starta. command, no knowledge is returned a.bout its execution
and/or success. It is up to the application to interrogate
the Device Server to determine its status.
• int dev_free(ds, error)
DevServer ds; I• DevServer Handle •/long •error;
Is called by an application to release a. device properly.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD05

Booster optics: Different options in this application allow tune measurement/setting, chromaticity
measurement/setting, measurement of .fl-functions at
quadrupole locations, and measurement of dispersion(7J-function).
Storage ring injection: Used for tuning of the injection kicker/septa to maintain an injection bump andcontrol injected beam position and angle.

7

Conclusion

The ESRF control system is operational since August 1991.
It played an important role during commissioning of thebooster synchrotron. The system has been designed frombottom up, using object oriented programming techniques,
and is based on proven industry standards. Its design has
been guided by a clear preference for mature commercial
systems over custom-or home-made ones, without formally
excluding the latter.
The system is not finished yet, but it is easily extendable and adaptable to future needs. It is through thestandards that have been selected for the control system,that ESRF will be able to migrate together with industry to new technologies while preserving considerable investments in ha.rd- and software. The choices of UNIX,
Xll/Motif, VME/089, Ethernet, and TCP /IP have been
fundamental in this sense.

S03SRD05
126

Status Reports: Design/Construction
126

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

Aknowledgements

NFS is a trademark of SUN Microsystems, Inc.

The author is grateful to all contributing members of the
ESRF controls group; in particular to C.Herve, head of theDigital Design Group, and A.Gotz, head of the Control
Software Group, for their competent and efficient leadership of the project. He takes the opportunity to thankalso A.Ropert, L.Farvacque, and all members of the machine division Theory Group, for their ongoing engagement in the production of control- and physics applications, and the smooth collaboration with them. Thanks
also to J.Altaber, and F.Perriollat (both CERN), as wellas collaborating groups from CERN, Trieste, and J lilich,
who initially helped us to get the project going.

9

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD05

XDR is a trademark of SUN Microsystems, Inc.
Ethernet is a trademark of Xerox Corp.
The X Window System is a trademark of the M.I.T.
HP-UX is a trademark of Hewlett Packard, Corp.
ORACLE is a trademark of Oracle Corp.

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

8

ICALEPCS1991, Tsukuba, Japan

RTDB is a trademark of Automated Technology Associates, Indianapolis, USA
AUTOCAD is a trademark of Autodesk, Inc.
EUCLID is a trademark of Matra Datavision, S.A.

All other trademarks or registered trademarks are of their respective companies. ESRF disclaims any responsability for specifying
which marks a.re owned by which companies or organizations.

References

References[l] J.L. Laclare, "Overview of the European SynchrotronLight Source" in IEEE Particle Accelerator Conference, Washington, D.C., March 1987, pp. 417-421.
[2] W.D. Klotz and C.Herve, "The Conceptual design of
the ESRF Control System" in European Particle Accelerator Conference, Rome, June 1988, pp. 1196-1198.

(3] Proceedings of Europhysics Conference on Control
Systems for Experimental Physics, Villars-sur-Ollon,
Switzerland, Sept.28 - Oct.2, 1987.
[4] Proceedings of the International Conference on Accelerator and Large Physics Control Systems, Vancouver,
BC, October 30 - November 3, 1989.
[5] Pal S. Andersen, V. Frammery, and R. Wilcke, "Tools
for Remote Computing in Accelerator control" in Proceedings of the International Conference on Accelerator
and Large Physics Control Systems, Vancouver, BC,

October 30 - November 3, 1989, pp. 225-230.
[6] Network Programming Guide, SUN microsystems, Part
Number: 800-3850-10, Revision A of 27 March, 1990.

[7] A. Nye and T. O'Reilly, X Toolkit Intrinsics Programming Manual, O'Reilly & Associates, Inc., 1990.

[8] The Builder Xcessory User Guide, Cambridge, MA: Integrated Computer Solutions, Inc. 1990

Trademarks
UNIX is a trademark of AT&T in the USA and other cowttries.
OS9/68000 is a trademark of Microware Systems Corp., USA.
OSF/Motifis a trademark of the Open Software Fowtdation, Inc.
OSF /DCE is a trademark of the Open Software Foundation, Inc.
Builder Xcessory is a trademark of Integrated Computer Solutions,Inc.

S03SRD05
Status Reports: Design/Construction

127

127

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

conttoller of communications instead of the usual network forreliability and perfonnance.
A system with a central CPU controlling all the others
through high speed point to point links and a pollingmechanism is much easier to implement and to maintain thana network.
Data integrity is easily achieved through a write-readback
mechanism and the failure of a peripheral unit can be
diagnosed and isolated very efficiently.
Perfonnances are much better than usual networks, due tolink speed and protocol simplicity: in a previous paper[3] wemeasured:1700 messages/s from Paradise to Hell
10 µs polling time for Purgatory to check out a Hell CPU
450 KByte/s data transfer from Hell to Paradise.
In this architecture the link between the consoles and thecentral coordinator (Purgatory) is easily implemented throughhigh speed DMA busses. The same is not true for the links
between Purgatory and Hell, since the peripheral CPUs are
spread over a wide geographic area, well above the standard
70m allowed by DMA busses. The best solution for theselinks is to use fiber optic connections, with their highbandwidth and noise immunity.

number of required boards. For each section a Xilinx
programmable gate array will implement the control of datatransmission and the receive logic. A single gate array will
implements the interface toward VME.
The AMD Taxi chips are used to implement the interface
toward the optical fiber, due to their ease of connection andhigh integration.
Af.IJ TAXIAMO TAXI

III. OPLA' (OPTICAL LINK ADAPTER)
The OPLA' (OPtical Link Adapte.r) project fa' an interface
between a standard third level VME crate, and an optical fiberhas been developed. This project aims at realizing a
multipurpose system for fast data transfer over long distance.
Use of the AMD Taxi chips allows data rates of up to 160
Mbit/s, which is more than a standard CPU can transmit on a
VME bus.
A simple architecture will be implemented: a 16 bit word
presented to the transmitter will be stored on the other side ofthe link in a 2048 word FIFO. FIFO overflow will be
automatically prevented by back transmission of a FIFO-fullstatus message.
A first prototype board has been developed and tested. The
board can be divided into two sections:i) Tx/Rx toward the optical fiber;ii) VME interface.
Software for conttolling and testing the board has beendeveloped on a Macintosh Ilfx using LabVIEW®[6].
LabVIEW® allows to create a front panel that specifies inputs
and outputs providing the user interface for interactive
operations. Behind the front panel there is a block diagram,which is the executable program.
A panel for the preliminary tests on the OPLA' prototype
boards has been built This panel allows access to two VME
boards cormected through optical fibers.
To access to VMEbus a MICRON (Mac Vee Interface
Card Resident On Nubus)[2], developed at CERN and a
MacVee (Microcomputer Applied to the Control of VME
Electronic Equipment) are used.
The next step of the project will be to implement four
complete Tx/Rx sections on a single board. In fig.3 theschematic design of the board is reported. Gate arrays will be
used to reduce component count and therefore design time andFig. 3 : OPLA' schematic diagram

IV. CONSOLES
Macintosh personal computers have been chosen for thesystem consoles. In the last few years we have seen an
impressive effort by personal computer firms and third parties
to supply large quantities of very high quality software at very
low prices. The situation is now, as far as software isconcerned, definitely in favour of the use of large diffusion
machines as opposed to high cost, "high" power, lowdiffusion workstations. Hardware prices keep getting lower,
while the cost of software development has reached about 80%of the total cost of an installation, with all the reliability risks
of in-house software development. The Macintosh family ofcomputers is at the moment the best candidate for a humaninterface development, since the effort expanded on softwaredevelopment on this machine has been the most striking on
the market
Previous experience with Hypercard [4,5], on the other
hand, has shown that high level software packages cande.crease software development times by strong factors. Fasterand more powerful human interface packages are coming out
everyday.
We already mentioned LabVIEW®: it is the first large
diffusion software package specifically designed for data

S03SRD06
Status Reports: Design/Construction

129

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-S03SRD06

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

acquisition and controls. Its main features are:
• Very easy creation of "virtual instruments", i.e. humaninterface panels containing controls and displays, acting on theappropriate hardware interface;• Graphic development of programs through an "icon"
language.
• Large scientific library containing frequently used tools(histograms, Courier transforms, etc.).
We are convinced that the use of this kind of large
diffusion packages wi!I allow us to save a very large amountof time and effort, not only in program development, butmainly in debugging and maintenance.

Remote Consoles
A good example of the above is the problem of remoteconsoles. Using an Ethernet or LocalTalk link and acommercial program, Timbuktu® [7] it is possible to gain
complete control of a remote Macintosh, under the protectionof a system of passwords. This was a specific request for the
DA<l>NE control system. How long would it have taken tobuild and debug such a facility?

V. VME OPERATING SYSTEM
In our previous experience with a similarly structured
control system we used no operating system for the lower
level CPUs. Simple FORTRAN or C programs took care of
the relatively easy tasks of a small and dedicated CPU that
only has to perform a few simple tasks. The general idea isstill:"A CPU for each task". While this is a rather extreme
statement, we think that the software environment for the
lower level CPUs must be kept as simple as possible, at theexpense of increasing their number. On the other hand, theadvantages of using a standard environment are obvious as far
as bookkeeping and standardization are concerned. At the
moment we are evaluating several Real Time Kernels and weplan to reach a decision by the middle of next year.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD06

VI. FIELD TESTSWe are testing out these ideas on small accelerators in
Frascati. A first implementation on a set of steering coils at
ADONE showed the feasibility of Hypercard as a humaninterface tool, at least for small systems•
Later, on a small machine, LISA, we have tried out thethree level system and we have started migrating the humaninterface, originally written in Hypercard, to LabVIEW (seefig. 4). We have shown that a progressive migration is
feasible, and these tests will allow us to measure the real
performance of these software packages in the field. At the
moment we believe that LabVIEW will prove adequate evenfor the large DA<l>NE control system.

VII.SUMMARY
The control system we are building is based on highly
distributed hardware and software capabilities, with a strong
accent on openness to other environments. We believe that thehuman interface will be the most arduous problem to solve,
and that the use of high diffusion software packages can be a
big help in that direction.
A high speed fiber optic link adapted to the accelerator
control environment is being developed.

VIII. ACKNOWLEDGEMENTS
We would like to thank the Accelerator Group of the LNF
for continuing discussions and encouragement The work with
the LISA group helped us develop a set of techniques that will
be very useful in the future.

IX. REFERENCES(1]

G. Vignola et al., talk presented at the San
Francisco Particle Accelerator Conference, May
1991.

[2]

B.G. Taylor, "The MacVEE Hardware User
Manual"; Rev.4.1, CERN EP Division, 1987.

[3}

L. Catani, G. Di Pirro, C. Milardi, L. Trasatti, F.
Giacco, F. Serlini ''The High Speed Bus System for
USA" Presented at the International Conference on"Accelerator and Large Experimental Physics
Control System" Vancouver, Canada, Nov 3,(1989) In Press to Nuclear Instruments andMethods.

Fig. 4 : Field tests showing progressive migration from
Hypercard to LabVIEW[4]

L. Catani, G. Di Pino, C. Milardi, A. Stecchi, L.
Trasatti.:MARCO • Models of Accelerators andRings to Conunission and Operate. presented at the
San Francisco Particle Accelerator Conference, May
1991.

[5]

HyperCard v2.1, Apple Computer Inc, e 1987-90.

[6]

LabVIEW, National Instruments Corp., @ 1990.

[7]

Timbuktu, Farallon Computing Inc, @ 1987-91.

S03SRD06
130

Status Reports: Design/Construction

130

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-S03SRD07

iaYax U

Fig. 1 Tll• bardware arcbitecture of tll• ooatrol system.

ID. HARDWARE ARCHITECTURE
The main console has been designed as an Ethernet
segment with a distnbuted software running on the resources
which are connected to it. The Ethernet segment is physicallythe same which interconnects the process stations but wehave superimposed on it the LAVC. This software is quite
reliable and is well tested in a lot of installations all aroundthe world. The structure resulting is easy to mantain as itrecalls centralized architectures but it is really flexible andable to suit growing requirements. The intrinsic problem tohave a central machine which will paralize the whole system
in case of failure has been considered but our experience
gained in similar architecture used for computer rooms
reports a very low failure rate.
The boot member is dedicated to the management ofCluster operations and of print and tape resources. Historical
logging of all the accelerator parameters acquired or calculatedby the control system is provided by the µ.Vax II, which is asatellite in the LAVC. Powerfull 3100 Vax.Stations with 16"
Trinitron colour monitor have been chosen as the hardware
platform for the operator interaction tools. All theworkstations, whose number is completely unrelated to thearchitecture of the console, share the same programs and areable to work on every acces point to the coaxial Ethernet
cable. This is the true sense of statement that: "the console isa network". A workstation will be dedicated to the beam
dynamic simulation either in accelerator or in the beamtransport lines. This machine, working on a complete
accelerator or beam lines setting, will calculate the necessary
corrections for the beam optimization.
Two particular nodes on the control room Ethernet are two
80386 based PCs, chosen because of their high performance,
low cost, easy programming and full integration in the
Digital network architecture (DECNE1). The first is dedicatedto run a database application (INFORMIX) used for the
storage of all relevant parameters of each sensor and actuatorof the cyclotron, like its name and software position in thecontrol system, the different alann thresholds and the range ofpossible setting value. Data are organized according todifferent query schemes to provide an interactive tool foreveryone needs a particular information. A particular u8t'.. ofthis application is the console itself. Infact. the data sectionof the applicative programs refers to this database and eachvariation is immediately available to the operator
workstations taking advantage by the possibility in a
DECNET environment to share disk between DOS and VMS

S03SRD07
132

Status Reports: Design/Construction

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

ICALEPCS1991, Tsukuba, Japanmachines. The second PC provides a lot of tools to help theoperator during alarm handling and troubleshooting
operations. This computer was conceived like an hypermedia
machine, with enhanced graphic capabilities for the disPlay of
pictures or drawings related to particular event and with thepossibility to play back defined speeches as an auxiliary
tools. Fig. 1 showes the hardware architecture of the control
room Ethernet so far described.

control networks. In this way we can send by a workstation
up to 35 commands for second, receiving any time by thecontrol station all the data acquired at that moment
The interaction tools in GIULIA are based on the defintionof three different classes: rappresentation, interaction and
BPM. Main attributes of these classes are "true" resizing andiconic interface. Rappresentation has three subclasses (table,
bar chan and graphic) that identify the different ways todisplay every parameter of the cyclotron. Interaction has threesubclasses (button, slider and knob) that identify the different
ways to operate on each parameter of the cyclotron. A
particular class is BPM which is realized to display thereconstructed beam shape acquired by the beam diagnostic
devices, with a low frequency. The environment provided tothe operator for its job is like that one of a writing desk:
foils, particular rappresentations, are distributed on the screen
and the parameters to be displayed or actuated have beenchosen during a shon navigation inside the program by theoperator itself according to its preference. Foils may be
opened, iconified, deleted and reconfigured. Graphic attn'butesof the subclasses may be easily changed by interactive setup
utilities or modifmg the UIL description file.
A process in GIULIA checks all variables for allarms orsafety limits, and when a threshold is exceeded all the related
informations are transferred to the second PC for further
dedicated analysis. GIULIA provides an extensive on-line
context sensitive help explaining how it works and all thedetails concerning the objects classes which it implements.
Some choices, which may be dangerous as the modificationof an a1larm limit by the operator, are always recorded in thedisplay of the workstation and are effective only for that
related disPlay.

The most relevant challenge in the development of a new,flexible and portable console is in the software design. The
whole hardware architecture described in the previous section
would be meaningless if it would not be provided an adequate
software suppon.
The main choice in the software architecture has been to
use X-Window as basic development environment Taking asa reference the software model proposed by X-Window, amodular object oriented code has been developed: GIULIA(Graphical Interactive Unit Level for Improved Automation).
It is based on DEC-Windows, an extension of X-Window
developed by DEC, which pennits to use a powerfull toolkit
and a User Interface Language (UIL) able to define thestructure of the graphical interface. The Object description isstored in a separate file where the methods to which theobjects will respond are outlined. The necessary code for the
implementation of every method described in the UIL file iscontained in a second file. Such a structure enhances theseperation between form and content of an application. The
possibility to use low level Xlib functions together withDEC calls in the same code is guaranteed. We chosed to work
under VMS and to use the "C" language to develop our code.
GIULIA is composed by two main parts running on atleast two different computers: the first provides man-machineinteraction tools while the second is ·dedicated to the
management of the accelerator data received from the control
stations and guarantees the operations on an accelerator
subsytem by only a workstation at a time. GIULIA creates aremote task on the µVAX II devoted to the data exchangewith the control system, in order to realize a trasparent task
to task communication scheme. Data exchange has been
optimi7.ed to reduce the traffic on the network and to semplify
the handling of the shared memory. For each control station
devoted to a particular accelerator subsystem according to afunctional scheme of intelligence distribution, we have on
the µVAX Il two different VMS global sections where are
written respectively the accelerator data received and thecommand to be sent. The access to these sections iscontrolled by means of flags. Tasks running on remote
workstations look and actuate on the control hardware in an
indirect way by means of this sections, malting the software
really device independent Full operations on each accelerator
subsystem are possible by each workstation asking to theµVAX II the allocation of this resource. At the end theoperator must deallocate the resource to pennit the operation
by an other machine. The bandwidth measured on the
network channel is of nearly 1.1 Mbit/sec for 2.5 Kbytes
packets quite in agreement with the performance of other

V. CONCLUSION
The goal to develop the software so far discussed has beenreached. Preliminary test has been carried out in order toverify the overall architecture and its performance that seems
to be quite in agreement with the accelerator requirements.
In order to implement a real time picture of the beam a
dedicated system is under development based on a CCD
camera and a VME frame grabber board. A dedicated monitor
will display the images so acquired at a high rate (about 30
Hz) with the possibilty to show up to 4 different images atthe same time.

VI. REFERENCES[1] E.Acerbi et al. "Progress Report on the Heavy Ion Facility at
I.NS" in EPAC Proceedings, Nice, France, June 1990, pp.
425-427.
[2] L.Calabretta et al. " The Tandem Injector for theSuperconducting Cyclotron at I.NS" in EPAC Proceedings,
Nice, France, Jwie 1990, pp. 491499[3] F. Aghion et al. "The Operator Interface in the Control
System for the Milan Superconducting Cyclotron" in 11th
Int. Conf. on Cylotrons and their Appl. Proceedings,
Tokyo, Japan, 1987, pp. 432435

S03SRD07
Status Reports: Design/Construction

133

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

IV. SOFIWARE ARCHITECTURE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD07

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ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD08

equipment may follow closely the principles of the accelerator controls.
The upgrade of U-70, for meeting UNK injector specifications, requires intensive machine studies which in tum
make a controls upgrade mandatory. Since this must precede
UNK, the principles and equipment may differ somewhat
from UNK controls proper.

OPERATOR CONSOLE
5 ·llN MCAPROGRAM DEVELOPMENTNETWORKCONSOL! WORKSTATIONS
3 - 5 PER CONSOLE .

. 2. HARDWARE ARCHITECTURE
The size and complexity of UNK, together with realtime and other requirements, dictate a multilevel multiprocessor controls architecture (see figure 2).
Various components of the accelerator equipment are
driven by more than 4000 equipment controllers (EC) which
perform low level control and data acquisition tasks in bard
real time and provide a uniform equipment representation for
the upper levels of the control system.
A typical EC is Euromechanics crate with Multibus I
compatible baclc:plane bus, contains a single board microcomputer, a fieldbus interface and a number of equipment
The standard EC microcomputer is based
specific 1/0
on microprocessors similar to the Intel 8086/8087. In the
UNK-I control system about 800 of such ECs will be used
for beam instrumentation, power suplies, RF and vacuum
system controls.
Similar technology will be used in the UNK-11 and cryogenics complex equipment interface. The main difference isin the EC microcomputer type which in this case is based on
the LSl-11 compatible microprocessors (see chapter 4).
There will be about 1300 of such ECs in the UNK-11 andcryogenics complex controls.
About 1500 of the UNK-1 correction magnet power supplies will be controlled by embedded ECs based on the Intel8051 microcootrollers. The EC is implemented on two standard Eurocarm and performs all the power supply control
functions, including timing and function generation. It bas
direct interfaces to the MIL-1553 fieldbus, timing and fast
alarm systems.
A general timing system distributes reference events andclock trains to all ECs. A separate aiarm and interlock netwodt collects signals from all ECs monitoring vital accelerator subsystems. These signals may be used to trigger the
beam abort system and inhibit beam injection.
The next higher level of control is represented by thefront end computers (FEC) spread around the main UNK
ring and beam transfer lines and interconnected with the upper level computers by the UNK controls netwodt. The FECs
will drive EC clusters through the 1 Mbit/s MIL-STD-1553
serial multidrop bus, which provides a cheap solution on astandard chip, noise immunity and galvanic insulation.
Physically, the FEC is a modular board assembly in a standard VMEbus crate. The basic FEC configuration will consist of a 32-bit processor board, a netwodt interface and anumber ofMIL-1553 bus controllers. It may also include 1/0
modules for direct interfacing to equipment needing full netwodt functionality or/and bandwidth to handle high data
rates (e.g. for sophisticated beam diagnostic devices).

CONTROL NETWORK BACKBONE

EQUIPMENT BUILDING NETWORK-vMEbus-carm.

BUS CONTROLLER
MIL-1553 FIELD BUS

1S10(8086)
EC PROCESSOR l80I (LSI-I l)

EC
UP TO 30 PER BRANCHUP TO 400 PER BUILDINGREMOTE TERMINAL-FAST ALARM & INTERLOCK-TIMING;----EQUIPMENT

Figure 2 General Hardware Architecture
The FEC's main purpose is providing access for the upper level control software via netwodt to the ECs. It may
thus be considered as a gateway linking the MIL-1553 field
bus to the UNK controls netwodt and as a specific kind of
netwodt server, providing a set of equipment access services
for application tasks running in the networked computers.
Io addition to this general task, a number of FECs may
be dedicated to certain functions through their own set of
1/0 modules. For example, one presently considers dedicating certain FECs to a task of UNK-11 superconducting magnet main power supplies control and quench protection. Finally, a FEC may run some application tasks, in particular
for local closed loop control and local equipment access, test
and diagnostics. It will also perform ECs downloading andsurveillance via the MIL-1553 field bus.
The netwodt will be layered: a so-called backbone willinterconnect the buildings and a number of LANs will interconnect equipment at the MCR and inside other buildings.
The development infrastructure forms a sub-netwodt which
will be attached to the backbone. LANs will mostly be Ethernet The backbone will be fiber optics FDDI or 16Mb fiber
optics Token Ring. The LANs and backbone will be connected by bridges/routers. Most networking hardware will
be standard commercial products.

S03SRD08
Status Reports: Design/Construction

135

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, JapanThe UNK operator's consoles, 5-8 in total, will each beequipped with 3-5 graphics workstations and one server. The
latter will provide common services (file, print, plot, etc.)
and can also be used to execute certain run-time application
softWare.
1bere will be a dedicated UNK control system's database management server CDB and a general purpose server
GPS for number crunching, modelling. The latter also caters
for general user program development, thus supporting numerous workstations and terminals spread around the buildings.

Application Software

3. SOFTWARE ARCHITECTURE

USER

3. Routine surveillance of the technological accelerator subsystems (like electricity, vacuum, etc.) Alarm signal generation and processing, fault recovery.
4. Data logging and archiving services which allow to keep
worldng track and history of the accelerator operation.

'Ibis analysis, design and data structure development
will be pursued using a modem integrated CASE tool package. The latter should also provide project management anddocumentation support, which are important when numerous
programmers of different level must cooperate.

The application environment is built on the basis of elementary functions provided by the system software. The
general UNIX operating environment bas been chosen for
the UNK control system.
The UNIX (Ultrix) will be used in the operator workstations and servers while a Unix-like real-time sytem will bechosen for FECs. For this part the LynxOS from the Lynx
Real-Time Systems Inc. is in the process of evaluation.
The TCP/IP, RPC, NFS packages, now a standard features of most Unix and real-time systems, will be used in thegeneral network.
For the 8086 based ECs, two operating systems are considered now: the MTOS-UX from Industrial Programming
Inc. and Intel RMX compatible DOS-86 which is available
on the USSR software market. A final choice will be madeby the end of this year. The LSI-11 based ECs will use an
operating system similar to the DEC RSX-11.

UIDS I UIMS- SUPEACYCLE PAOClRAMMING- MAIN PDWeA SUPPLIES- AF6V8TEM- OABIT MEASUAEMENT- OABIT COAAECTION- BETATAON TUNE ME>.8UAEMENT- CHllOMATICITV ME>.8UAEMENT- BETATAON TUNE COAAECTION- CHllOMATICITV COAAECTION- OCTUPOL COAAECTION- INJECTION CONTAOL- AF av8TEM CONTAOL- VACUUM SYSTEM CONTROL- CAYClENIC COMPLEK CONTAOL- BEAM ABORT SYSTEM CONTROL- PEASONNEL ACCESS CONTAOL- UTILmES CONTROL

1. Process modeling and preparation of data sets which detennine the operation of accelerator devices. Advanced
modeling programs can simulate a particle behavior forthe different modes of operation of the accelerator and insuch a way test a validity of the data set prepared.

System Softwareg·

A first analysis of the UNK control system functionality
bas been made using the SASD methodology. Thus the mainprocedures, data flows and data stores were identified. The
application software functionality can be represented by thefollowing broad groups of tasks.

2. Data down-loading, acquisition and trimming.

Experience in development of accelerator control system software packages world wide shows that certain functionalities are existing in one form or another in the majorityof them. The general trend, which we try to follow, is therefore to extract these common parts and provide them as standard facilities which may be used by each specific application task:. This would allow to eliminate multiple code andimprove system reliability and maintainability. The software
implementation of those common functionalities may becalled the application elfVironment (Figure 3).

SPEOFIC APPLICATIONS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD08SESSION
MANAGER
MODELLING
PROGRAMSDATA BASE
ACCESSREAL- TIME DATAMANAGEMENT
FILE SERVICESDATA LOGGER
ARCHIVE
ALARM
PROCESSOR

User Interface

EQUIPMENTACCESSThe user interface is based on graphical workstations
and windowing techniques. Commercially available
UIDS/UIMS (User Interface Development/ Management
Systems) built on the basis of the X-Windows and
OSF/Motif standards are considered now for the user interface creation and management (XFaceMaker, TAB+, Teleuse, VUIT). Such systems allow easy interface design andquick prototyping.
Much recent work in this field is concerned with specific extension of commercial productS to a standard set ofcontrol tools and screen layouts which would allow to unify

EQUIPMENT

Figure 3 Specific Applications and Application
Environment

In contrast with a general purpose application independent system software the application envirooment is problem(controls) oriented. It is supposed to be relatively stable andonly evolve slowly during a control system's life cycle.

S03SRD08
136

Status Reports: Design/Construction

136

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishinghuman interaction procedures for a wide range of applications. Early specification, prototyping and demonstartion ofsuch a tools would allow to start application software development and meet user's requirements.

DBMS and Real-Time Data Management
Off-line data preparation, including descriptiom of machine and control system objects and relations, will be doneusing the Oracle DBMS and related tools.
One presently considers organizing all data inside of thecontrol system in a specialized home-made real time DBMS.
It should contain both static read-only data, derived from
Oracle and dynamic data of the current machine state, somenumber of pre-defined UNK states for pulse-to-pulse modulation (PPM) and accelerator development, etc. This realtime DBMS will support access to read/write data for fixedand off-line prepared data structures. It will serve a numberof distributed data bases. Each DB is a standard file, containing data in the form of three-dimensional tables, some ofwhich may be duplicated in the memory of specified computers•.

Equipment Access
The dive.tSity and multiplicity of process devices, requires some uniformisation, i.e. biding the device specifics
from the operational applications. For doing so, the device
specifics shall be encapsulated in software envelopes having
a standardized access protocol
This concept leads naturally to the object-oriented approach to logical equipment representation. An equipment
object can model a real, physical unit of the equipment or
abstract entity, like a feedback: loop or a data buffer.
The applications' vision of equipment is strictly limited
to a relatively small number of logical device classes. Eachlogical device con:esponds to a physical component or groupof components of the accelerator equipment able to perform
a complete task and considered as a single entity in context
of the accelerator operation. A device object class can represent, for example, an ion pump with all its attribures (e.g.,
status, voltage, pressure, etc.) and services, which it provides
for an application task (switch on, set voltage, read pressure,etc.). Each particular ion pump in the system will be an instance of the ion pump class.
A logical device is a complex object that encapsulates acollection of cooperating component objects. Each component object class represents a stable partial functionality inside of a logical device ( input/output, local data bufferingand processing, surveillance, timing, etc.). The set of thecomponent object classes fonns a toolkit for logical device
construction. The set of component objects constituting a device, with their relationships and dependencies, fonnally represent logical device model.
A logical device undergoes the following main phMes
during its ''life cycle" in the control system.

1. Device class creation: positioning of the class in deviceclass hierarchy, definition of new logical device attrib-

utes and services using the component objects class library.
2. Implementation: integration of standard software modules, coaesponding to the library classes, and, possibly,
writing of a code reflecting a new device specific features. It should be noted that the same logical device canbe implemented in several veISions on different hardware
platforms.
3. Instantiation: creation of a particular device object which
is an imtance of the device class. The object identifier,implementation version and equipment networlt address
are specified at this plwe.

4. Initialization: downloading of the device software into
the specified platform, initial test and device setting in a
predifined initial state.

Commercial Control Software Packages
Standardization trends result in the appearance of "generic" integrated commercial controls software packages
which can be configured to realize a wide range of functionalities. Examples are V-System from VISTA, 02 from Gensym Cotp., GENESIS from lconics, etc.
For the pwpose of thorough evaluation the V-System
software will be used as a kemel of a relatively small prototype control system . The system will support commissioning of the U-70 to UNK-1 beam transfer line, planned for the
middle of 1992. The V-System will run in the VAX/VMS
wodc:station connected via Ethernet to front-end computeIS(MS-DOS WM/PC). Each of these front-ends will control acertain number of technological subsystems (including all
types of power supplies, beam instrumentation, vacuum andutilities subsystems like electricity, ventilation etc.) by using
equipment controllers connected via RS-232 interface. These
PCs will be used as local comoles for equipment tests at the
begining and thereafter they will worlt as a "data pumps" tosupply data for the V-System data base.

4. CRYOGENICS ASPECTS
The cryogenics and related equipment is a substantial
part of the UNK project and falls into three broad groupings.
1. The cryogenics complex that provides cooling of the superconducting magnets placed in the UNK ring tunnel.
2. The quench protection system.
3. The superconducting magnet main power supplies with
their ramping and de programs.
By their nature these systems have a close internal binding and require only a weak coupling with the main UNK
control system. A fair degree of autonomy and stand alone
capability is therefore foreseen, which is helpful in commissioning and later servicing.

S03SRD08
Status Reports: Design/Construction

137

137

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-S03SRD08

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

Acconling to the functionality and geographical distribution of the equipment, the cryogenics complex control is
subdivided among four relatively independent subsystems.

in the accelerator area. These utilities are the general electricity and water distribution netwodcs, tunnel ventilation andgas analysis system, radiation protection, fire safety and personnel access control to restricted access areas.
The utilities controls shall be supported by relatively
slow, but very reliable and uninterruptable control system .
A special highly reliable service network will interconnect anumber of regional control nodes with central utilities control room. The service network will be linked to the main
control network and access to the utilities can be provided
also from the MCR consoles.
The market study, evaluation of commercially available
components and prototyping have been started. A part of thiswork is design and implementation of utilities control system for the beam transfer line from U-70 to UNK-I (BTL).
The system is based on the standard industrial programmable
logic controllers (PLC). The PLCs perfonn low level control
and monitoring functions and are linked via RS-232 lines tothe IBM PC compatible console computer in the temporary
beam treansfer line control room. The IBM PC collects datafrom the PLCs, performs data analysis and generates alann
messages and interlock signals in case of faults. It makes
also. periodic data logging and keeps a log of the system operation.

1. The gueous helium storage, compression and purification control The corresponding equipment is located inthree compressor station buildings placed around the
UNKring.
2. The helium liquefiers control There are 6 helium liquefiers located in the central helium liquefier building.
3. The satellite refrigerators and magnet cooling control.
There are 24 refrigerators located in 12 buildings regubu:y distributed around the UNK ring. Bach refrigerator
supports operation of one superconducting magnet string.
4. The Nitrogen Storage and distribution control.
. L~ access to the ~ryogenics equipment will be provided via local consoles m each cryogenics complex equipment building. The local consoles will be used in the equipment commissioning, autonomous tests and troubleshooting.
The nonnal operation will be perfonned from the Cryogenics
complex Control Room (CCR) located in the central heliumliquefier building. The CCR will be equiped with the same
sort of tools as the UNK MCR and provide 5-7 operator's
workplaces.
Cryogenics complex controls will, like the main UNK
control system but with some special flavours, use theMultibus-I based ECs with 16 bit processors connected by
Mll..-STD-1553 to the standard UNK FBCs.
A specialized Multibus-I programmable controller module (SPC) has been developed and will be used at the lowest
control level in the cryogenic system. The module consists ofthe general pwpose 16-bit Multibus-I processor card and afunctional card which is connected to the processor via a private bus. There are few types of the functional cards developed for interfacing to various kinds of transducers and actuators used in the cryogenics equipment. The SPC will
autonomously realize closed loop control and relay logic algorithms acconling to the program stored in its PROM. A
Multibus-I crate may house a number of SPCs woddng inparallel under supervision of the main EC processor. The total number of SPCs in the cryogenics complex control will
be more then 2000.
In collaboration with CEA, Saclay, a first version of a
FNAL-like quench protection system will be tested on an experimental sector of 8 protection units, each consisting of 12
dipoles and 2 quadmpoles. The front-end electronics andemergency heating power supplies are located in shieldedcavities in the ring tunnel.
The main power supply controls will fonn a closed subsystem, loosely coupled to the main controls and interlockedwith the quench protection system.

5. UTILITIES AND SERVICE NETWORKThe UNK complex includes a number of various utilities providing, as a whole, the safe and reliable environment
for the main accelerator subsystems and personnel worldng

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD08

6. EXTERNAL BEAM LINES
The external beam lines will comprise a 12 km longneutrino channel, leading up to the neutrino experimental
area. and three 6 km long hadron beamlines leading to theirown experimental area each. The operational patterns of thebeamline zones are, by their nature, different from the accelerators. The essential aspect is the more frequent and rapidchanges, following the experiment's requirements.
The technology of the equipment used in these beamlines and experimental areas is similar to the one of the accelerators proper, including the use of superconductivity
hence cryogenics. A strongly different aspect, however, fonn
the target areas and splitting stations with their radiation
problems and remote handling requirements. Some advanced
devices such as polarimeters and crystal bending and focusing may be used
One presently consideis a controls architecture which isvery close to the one described for the main UNK ring.
There will be workstations with the modem windows andgraphics oriented software, these will be interconnected witha TCP/IP based network, which in tum connects to the accelerator network, and at the frontend to VME based 32 bit microprocessors driving ECs over the Mll..-STD-1553 fieldbus.
In contrast with the accelerator system, the ECs of the external beam zones controls may still be CAMAC based.
Powerful number-crunching multiprocessor assemblies
will be used for digital signal and image processing in thepolarization hodoscopes, electron-gammas tagging system
and TV- cameras based beam instrumentation.
Systems software will essentially be the same as for theaccelerators. Applications will be strongly data driven and

S03SRD08
138

Status Reports: Design/Construction

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

ICALEPCS1991, Tsukuba, Japanmodel oriented and an expert system is being contemplated
for operator support.
Although routine operation may be done from a central
MCR, a strong local access and stand alone component remains essential.

2. V.Alferov, S.Goloborodko, S.Logatcbev, A.Skugarevsky,''The Control System for the UNK Cryogenic Complex",!HEP internal report, November 1990.

Contrary to the situation for the accelerator and beamzones controls, for which options were open, the U-70 injector group has a strong historical bias since both booster andU-70 proper are largely computer controlled. Moreover, theupgrade must be done virtually without interruption of the
U-70 experimental programme. Fmally, the urgency of thisupgrade practically dictates using products now readily
available in the USSR and using a stepwise implementation,
converting small slices during the short planned shutdowns.
The FBCs for the U-70 upgrade will be the Multibus I
based SM1810.30 computer with an Intel-like 16 bit
8086/8087 processor board, using an RMX compatible realtime kernel. They will have appropriate RAM capacities, a
LAN interface and a parallel branch highway CAMAC
driver. Each of the about 12 FBCs, spread over 4 buildings,
maximum 4 km apart, drives up to 3 CAMAC crates catering
for I/O. Servers for files and data base, 4 to 6 in total, will beenhanced configurations of the FBCs, featuring larger memory, hard disk and a more complete generation of the operating system. Interaction will be using PC-AT computers un·
der DOS. A commercial LAN product is still being sought in
the USSR.

3. V.Sakharov et al., "Preliminary Considerations on the
Top Level Part of the Control System for UNK External
Beam Clwmels", IHBP internal report, November 1990.
4. S.Balakin, V.Brook. V.Voevodin, V.Tishin, "The Control
System for the Booster Synchrotron of IHBP", 19th

School fpr Control Systems in Science Research, Novosibirsk., 1985,p.11.

S. V.Voevodin, ''Preliminary Considerations of the RealTime Data Management for the UNK Control System",
UNK Control Group internal report, June 1991.
6. MMikheev, "Proposal for Use of the V-System Software in the UNK Beam Transfer Line Control System",
UNK Control Group internal report, April 1991.
7. N.Trofimov, "On Object.Oriented Approach to theEquipment Access", UNK Control Group internal report,
September 1991.

8. PRESENT STATUS
A conceptual design study of the upper part of the control system has been made and is accepted Prototype partial
integrations of the main control system and front end assemblies, as well as a quench protection test facility, are being
prepared and should be available early 1992. An applications
development environment with servers and workstations isbeing prepared. The external beam zones controls are in theconceptual design phase. The U-70 controls upgrade has
been largely defined and frozen and implementation has
started.
The Multibus-I based BCs have been largely defined,

prototypes of most modules exist, industrial contracts are being negotiated. All BCs for the BTL are assembled andtested and installation in the equipment buildings is in progress. The V-System applications for the temporary BTL
controls are largely prepared and corresponding communications and PC front-end software is under development.

9.REFERENCES
1. M.Mi.kheev, N.Trofimov, B.Schelbakov, S.:l.elepukin,

B.Kuiper, ''The UNK Control System Conceptual Design
Study", !HEP and CERN internal report, June 1990.

S03SRD08
Status Reports: Design/Construction

139

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

7. U-70 CONTROLS UPGRADE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD08

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-S03SRD09

modules. The resulting object code is being linked with
Pascal library and the one, containing control system
support modules.

Controlledparameters

Control station software structure.
The structure is depicted on fig. 3. Feedback control
loops include control drivers, algorithms and reenterable
data acquisition drivers. Reenterability allows to obtainmeasurement data by any program module, initiated withinterrupt, while the same device is used by another program unit. Control drivers and algorithms are supervisedwith monitor. Real time processes deal with interrupts,
initiated from different sources (network, CAMAC,
timer). Network support system handles net protocol;
access to data transfer buffer is also reenterable. Low level
real time techniques include P-V operations to protect
critical resources, repetition of critical section with nonsavable resources and counting flags to prevent CPU
overload.

Real timeprocesses

Monitor(___s_o_ur_c_e_P_a_sca_I_&_M_a_c_r_o_c_o_d_e_ _)Network support system
To concentrator

Pascal- I compiler

1

Fig. 3. Control station software structure.

Macro-code im{>rover(prorsm, compiled with Pascal-2;
yiel s about I 0 % improvement)

l
Macro

~If Ii"'' '"' ' ',,,,,,.

l ""'' 'r--

be accomplished with received parameters. These
functions include: status of parameter inquiry, control,parameter value acquisition, free coefficients setting(calibration) and implementation of predefined
operations. Special frames, consisted of only commandcode, are used to support network protocol and characterize
general subsystem status.

CAMAC support
modules

Algorithms.
!::

I

Pascal library

I

Control system support library.
Contains real time, error processing
and network support modules.

Fig. 2. Basic compilation tools.

Network data communication.
Data transparent network protocol is supported byexchange of byte-serial frames. They include commandcode, destination and source codes, data counter, unit ofdata and checksum. Command code indicates function to

Algorithms, realized in RTM control system, can bedivided into three groups: dynamic methods, functioning
under strict time conditions, and two groups of quasistaticalgorithms, where timing is not essential. The latter are
based either on optimization technique or apply physicalmodels of microtron's systems. Control system itself
executes only dynamic and optimization methods.
Dynamic ones include DDC methods both for logicalcontrol (switches) and analog algorithm simulation. The
latter one <PI method) is used for temperature stabilizationof accelerating sections [3 ]. Optimization algorithms are
realized in one and two dimensional modes. One
dimentional algorithm is based on "regula falsi" method
and is used for fine tuning of various control parameters.
in particular, to stabilize reference frequency generator.
Two dimensional algorithm is used to steer electron beam
via collimators by minimizing it's leakage current. The
method deals with approximately symmetric goal function
with flat bottom and uses non-derivative direct searchingalgorithm. At first stage steering algorithm scans withbeam, using spiral trajectory, to find out goal function

S03SRD09
Status Reports: Design/Construction

141

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, Japanposition.
Model algorithms are not immediately
supported by control system. They can be carried out withthe help of any external computer, interfaced with control
system. For this purpose man-machine interface computer
also handles remote terminal protocol, allowing to inquireand set new values of any controlled parameter or toactivate predefined functions.

Man-machine interface and external worldcommunication.
Man-machine interface software is based on approach,which gives means for operator to design -within hardware
possibilities - his own computer images ofthe accelerator.
It is supported by several types of windows and a list of theirnames (menu), allowing to activate any window. Special
program supports creation of menu and windows .
Graphical window can be chosen among several predefined
types, which include those, representing several twodimensional curves and the windows, which support anamplitude analyzers mode. Operator is not able to change
geometrical shape of a window, but have a possibility to set
colors, inscriptions and some other attributes. Anygraphical window can then be loaded in a graphics support
computer.
Alphanumeric windows contain a set ofparameters, extracted from parameters data base. Theirvalues are represented on a terminal in any chosen
position. Operator can previously fill the window with anarbitrary text. One type of alphanumeric windows is used
to set constant parameters of accelerator (calibration
coefficients etc). Their values are defined during awindow's editing and transferred to subsystems when it's
activated. Another type of windows - a working ones support actual interaction with control system. Theyinquire and represent current values of parameters on adisplay. Operator is able to set a new value of any window
parameter or initiate predefined control procedures. To
adjust microtron's systems, it's possible to scan with any
parameter (time among them), while others are represented graphically or (and) listed in a data-storage file.
Working windows automatically support local data basefiles. Parameter's values are stored there before exit andextracted from the file when window is activated. There
are also several windows, which are not programmable andare used to support system functions (time setting,password etc). Statuses of parameters, obtained fromcontrol stations, are stored in a special data base and canbe displayed by operator's request. As mentioned above,
man-machine computer also supports "external world"interface with a required data communication protocol.

Software development. technique.
A considerable number of controlled parameters (about
400 now) requires definite technique to develop software.
The development cycle is shown on fig. 4. It allows to avoid
discrepancies between expression of requirements andactual control station program. During the cycle
parameters data base is being corrected and supplemented.
This base is used later to develop man-machine and"external world" program interfaces.

Expression of requirements

Loading of hardware database(bits, ADC and DAC channels
destination etc.)
Source code for control
station
Program testing anddebugging
Parameters data basesu lement
Filling of parametersfunction and status lists

Discrepancy

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD09

References.
(1 ). A.S. Alimov, I.G. Artiukh, V.I. Shvedunov et al
Preprint NIIYAF MGU, 88-012/ 33, Moscow, 1988.
(in Russian).
(2 ]. A.S. Alimov, V.G. Gevorkyan, I. V. Gribov et al"Beam emittance forming line of the CW Race-Track
microtron of the institute of Nuclear Physics of Moscow
State University (!NP MSU )". Nuclear Instruments andMethods in physics research A278 ( 1989 )p. 379-388.
(3 ]. A.S. Chepurnov, I. V. Gribov, S. Yu. Morozov,
A. V. Shumakov and S. V. Zinoviev "Feedback Systems for
Local Control of Race-Track Microtron RF Accelerating
Sections". These proceedings.

Fig. 4. Software of control station
development cycle.

S03SRD09
142

Status Reports: Design/Construction

142

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

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-S03SRD10........
.
lnjcdor

ConsoleCon!OleCompuLer

ComputerComputer

VAX6000

V-3100

V~l!OOhoc'"'

Console Levd

llollli610

SRltC
UN

W..W16• console Computer

vAXAatiao 3100
Modd40~Modol76

Coolrol UN (l.!lhend).

• Tum-key JYllcm• *' •• • • • I

Figure J. Hardware configuration of the control !!)'Stem at SRRC

The process computer creates and maintains the databaseand manage them at current development. The central databasehas been used at SRRC control system due to the on-timeschedule to commission the machine. It will be modified as a
distributed data base in near future. The update data rate from
IL.Cs is set 10 Hz due to broadcasting mode or under request
mode. These data can be received by any top level computers.
The top computers can also set the parameters of the device
and read the signal back and display it graphically. The
process computer is running in VMS operating system but
the console computer can run in VMS or Ultrix operating
system. The ethernet using TCP/IP protocol is used to link
all top computers and multi-ILCs.
The console computers are composed of V AXstation
3100 model 76, model 40 and DECstation 5000 model 200
that is run Ultrix operating system. The workstation will
provide the console control and monitor the machineparameter and/or device signal through user graphic interface
software. It provides the real time data trend or graphic display
friendly.
The ILC is an VME crate system which includes
Motorola MVME-147 central processing unit (CPU) board
and variety of 1/0 cards. The CPU board consists of 68030
microprocessor, 68882 floating point processor, 4 Mbyte onboard memory and ethernet interface. The field devices areconnected into ILCs through parallel analog or digital
input/output or IEEE-488 bus standard or serial
communication interface. The major tasks of the ILCs willhandle the data setting, data acquisition interlocking, andclose-loop control and monitoring function of the equipments
or devices. Twelve set ILCs will handle the magnet power
supply, RF system, vacuum system, beam diagnostic, andgeneral purpose measurement instruments, ... etc. The userfrom the workstation can set and read back the parameters ofthe device easily.

III.COMPUTERSOFrWARESYSTEM
Based on the VMS operational system and utility
package, the software of the control system at SRRC has
been designed and basic program of this software was coded
and tested. The block diagram of software structure is

Figure 2. Block diagram of software system

shown in figure 2. The software structure is divided into
several logical layers that is device access, network access,database management, graphics user interface and applications.
The goal to modularize the software into layers is to reducethe developing time.
The device access process are run on the ILCs. The
pSOS+ real time kernel provides the ILC with support fortask scheduling, memory allocation, even handling andmessage queuing. The pNA+ network support package
provides socket network interface. The control tasks andvarious 1/0 tasks are developed and tested on the ILC. The
device dependent software drivers are implemented partially.
The magnet current regulator, RF low-level electronic
controller and vacuum gauge controller were implemented andtested successfully. The speed of the dynamic data uploading
to the top level computers is about 10 Hz. Downloading thedatabase from the process computer into the ILCs to form a
local distributed is initialized and underway.
The network access software is in charge of theinformation exchange between the top and the low-levelcomputers. The protocol of the IEEE-802.3 is used tocommunicate with the turn-key injector system. The highlevel protocol TCP/IP is using at this moment. The reason touse IEEE-802.3 and TCP/IP protocols due to the beginning of
the vendor contract to made an agreement for IEEE-802.3.
That time the TCP/IP is not popular enough for VAX
computer and 68000 series computer vendors. However, it
would be changed into TCP/IP after the commission of theelectron injector to form a unique local area network.

S03SRD10
144

Status Reports: Design/Construction

The database access is developed on the console levelcomputers. The console level computers are VAX/VMS
system ( or can be an Ultrix system for the console
computer). The software is coded in C language. The functionof the process computer and operational console computer (orcalled workstation) is slightly different. The process computer
keeps the system-wide static database and maintains it. The
upload sequence is also requested by the process computer. At
system start-up, each workstation requests and receives a copyof the static database from process computer. Each console
computer then has all the database information necessary toprocess dynamic database frames received from the ILCs.

ICALEPCS1991, Tsukuba, Japan

Control Proaram ot the Operator Interface

The workstation are mainly to provide user to operate themachine. The upload sequence is requested by the processcomputer, the ILCs multi-cast the dynamic data sequentially.
All of the console level computer received dynamic data andupdated into database at the same time.
The central database on the console level computer is usedas buffer between the low level tasks at the ILCs and theconsole level applications. The application programs of theuser can access the equipment parameters directly from theirown database rather than from the ILCs. The application
programs are device transparent. The development programson the top level computers can be run concurrently.
The basic control and monitoring program has beendeveloped at current stage. These programs are urgently needfor machine commissioning. Those programs include the data
logging, archiving, alarm checking and display routine etc.,
were coded and tested successfully. The machine model
calculation can be run on process computer and/or individual
workstation. The graphics user interface software wasdeveloped based on X Windows and Motif in VAXstation
3100 model 76. The block diagram of the relationship todevelop the graphics user interface is shown in figure 3. The
graphic edit program is to edit the display pattern of themachine components and build up the linkage relationshipbetween the component and the static database. Those patternfile is stored with ASCII format in the hard disk. The control
program is to read these ASCII file and make a connection
between the component pattern and dynamic database. This
program is also to execute the task of the data reading, setting
and display from the DDB server. All subprogram is written
in modularize software package. This human interface
software will provide the operation of the synchrotron
radiation facility more friendly.

IV.SUMMARY
The control system for the dedicated synchrotron radiation
light at SRRC has been designed and the computer hardware
and software was implemented partially since last year. Twolevel hierarchical computer control system has been
configurated and the high speed local area network that use
ethemet and high level protocol such as TCP/IP have been
implemented and linked. The data upload rate is to maintain
about 10 Hz without increase of traffic load at network. The
over-all performance of the process computer and multiple
ILCs as well as digital communication network has been

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD10xs.......

C-LAN (Btl..,all)Figure 3. Block diagram ot the operator Interface

tested and evaluated. The results show the 10 Hz update fromthe ILCs is not big issue to control and monitor the devices
for synchrotron radiation facility at SRRC.
The object-oriented development tool of the graphic
display and data trend display were developed and tested. The
user can set and read back the signal from the field level
devices within 10 Hz. The flexible change of the time interval
for the data display at specified signal is allowable to change
from 1 sec up to 60 sec. The GUI software can be developed
from the developed basic edit program to code and modify it.
This software will provide the user to operate the machine
were easily and friendly. Finally, the two level computerarchitecture, multiple ILCs that are linked by ethemet local
area network using TCP/IP, object-oriented graphic display
software will be a nice control system for synchrotron
radiation facility.

V.ACKNOWLEDGEMENTS
One of the authors (G. J. Jan) would like to express his
appreciation to R. W. Goodwin and Mike Shea of FNAL, W.
D. Klotz at ESRF and Tomotaro Katsura at K.EK-PF formany useful suggestions. We also would like to acknowledge
David Rice at CESR to discuss the technical considerationfrom the operational point of view. We would like to thankShin-ichi Kurokawa at KEK-Tristan to give a lot of technicalinformation and experience.

VI. REFERENCES[I) "SRRC design Handbook", Synchrotron Radiation
Research Center, April 1991.
[2] M. Castellano, S. De Simone, G. Di Pirro, S. Guiducci,
P. Patteri, M. Serio L. Trasatti, "Diagnostic and control
system for the LISA project", INFN, Laboratori Nazionali
Di Frascati, European Particle Accelerator Conference,
Rome, 1196 (1988).

S03SRD10
Status Reports: Design/Construction

145

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-S03SRD10[3] A. J. Kozubal, D. M. Kerstiens, J. 0. Hill and L. R.
Dalesio, "Run-time environment and application tools
for the ground test accelerator control system", Nucl.
Instrum. and Meth. A293; 288 (1990).
[4] S. Magyary, M. Chin, C. Cork, M. Fahmie, H.
Lancaster, P. Molinari, A. Ritchie, A. Robb, C. Timossi
and J. Young, "The advanced light source control
system", Nucl. Instrum. and Meth. A293, 36 (1990).
[5] B. Robinson, and P. Clout. "Modularization andstandardization of accelerator control syst.ems", Nucl.
Instrum. and Meth. A293, 316 (1990).
[6] J.P. Stott and D. E. Eisert. "The new ALADDIN control
syst.em", Nucl. Instrum. and Meth. A293, 107 (1990).
[7] W. D. Klotz, C. Herv6, "The conceptural design of the
ESRF control system", European Particle Accelerator
Conference, Rome, 1196 (1988).
[8] Marco P. Mignacco, "The ELETIRA control system",Nucl. Instrum. and Meth. A293, 44 (1990).
[9) F. Potepan, "The ELETIRA man machine interface",lnt.emal Report ST/M-91/2, Sincrotrone Trieste, Italy,
March 1991.

S03SRD10
146

Status Reports: Design/Construction146

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

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, Japanare the computing service layer, the human interface layer, thesubsystem control layer, and the ma.chine interface layer. The
computing service layer is a· time-shared host computer in thecomputer room, and it is linked to various operator consoles
whicli form the human interface layer. These workstations a.re
located in the ma.in control room. The consoles are connectedto the master crates which form the subsystem control layer via
an Ethernet. These master crates are located in local control
stations distributed throughout the ma.chine. The master crates
are connected to slave crates, which form the machine interface
layer, via a MIL-STD-1553B network. Each slave crate can use
a variety of protocols to interface with ma.chine components.
Among these are IEEE-488, RS-232, RS-422. New protocols
can be added with plug-in modules.

software interoperability derived from its support for industrysta.ndard platforms. In addition, we will be able to easily integrate with other software environments such as relational databasesand expert systems, and effectively develop integrated softwareby separating the GUI from application code.
A total of six workstations will be used as operator consoles
for the storage ring and the lina.c, and a few additional color display monitors are planned for continuous display of informationsuch as beam current, vacuum status, and magnet power supply
current.

Computing service layer - Host Computer
A host computer with a high computational speed, large
memory, and multiple job capability is needed for code anddata management, mathematical modeling and simulation, offline analysis, and for genera.I purpose computing. For a low
emittance light source, there a.re many critical para.meters andit is more important to provide good computer modeling or simulation of the beam optics. For this purpose, the computation
speed should be fairly high, and the machine should have at lea.sta 32 bit processor with substantial physical and virtual memory
space.
The DEC/VAX SYSTEM 6000™ may be a good choice forthis as the VMS™ opera.ting system provides an excellent software foundation upon which to run software donated by cooperative accelerator laboratories. However, if we can port therequired software to the UNIX™ environment with little effort,a high performance RISC computer might be an alternative.
The host computer will be installed at the end of 1993 after
the storage ring building is completed.
Human interface layer - Console .Computers

Mid-range engineering workstations will be used as operator consoles to put in the operational parameters and show theoperating status. Input para.meters will go through some arithmetical processes and be converted into control commands foreach affected piece of equipment.
Operating status should be shown on color display monitors
in the form of simulation diagrams, various kinds of charts, andother graphical expressions. For this role, an engineering workstation is the best fit due to its high computing power and relatively low cost, high resolution color graphics capability, andhigh performance multiple window display system.
Currently, several SPARCsta.tions™ of Sun Micro Computer
Corp. a.re being used for console software development since
they are well equipped with competitive capability, open system
policy, and software availability.
Even though workstations provide excellent graphics capability, typical implementations of easy-to-use man-machine-interfaces
have required sophisticated programming effort. However, we expect the use of a GUIDE (Graphical User Interface Development
Environment) will be a great help in saving development effort.
DataView™ of V.I. Corp. is a potential solution. DataView™
consists of two components: DY-draw™, an interactive drawing
editor for creating sophisticated screens without programming,and DY-tools™, a library of subroutines that connects graphics
created with DV-draw™ to an application program. Thus itsaves development effort, allows rapid prototyping, and future

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD11

Subsystem control layer - Subsystem Control Computers
The Subsystem Control Computers(SCC) are microprocessor
assemblies based on VMEbus and Motorola's 680x0 microprocessor. The reason for adopting VMEbus is its reliability and popularity. Each SCC consists of one Single Board Computer(SBC),(!.n Ethernet interface module, and a MIL-STD-1553B network
interface module, all of which are put together in a VMEbus
crate. Motorola's MVME147™ with 32-bit 68030 CPU and 4
Mbyte memory is used for the SBC of the SCC.
The SCC does many control and monitor functions, such as
reading and setting parameter values of ma.chine components,
feedback-control, alarm handling, and raw data processing foreach subsystem, i.e., vacuum, magnet power supply, R.F., beamdiagnostics, timing, a.nd interlock. Each SCC is interconnectedto the multiple Ma.chine Interface Units(MIU) through MILSTD-1553B network. The SCCs a.re also linked to the high levelcomputers through Ethernet.
Ma.chine interface layer - Machine Interface Units
MIUs are also microprocessor assemblies based on the VMEbus and Motorola 680x0 microprocessor family. Ea.ch MIU has
one SBC, one MIL- STD-1553B network interface module, anda number of analog and digital input/output modules, all ofwhich are put together in one or more VMEbus crates. An
SBC equipped with Motorola's 68000 16-bit microprocessor and
1 Mbyte memory is used for the MIU. In order to handle various
types of analog and digital input/output signals, a wide rangeof standard analog and digital input/output modules as well as
home-ma.de or non-standard interface modules are used. MIUs
are distributed in local field stations, which a.re located a.roundthe machine, to reduce the length of the signal cables between
the MIUs and the machine components and also to reduce electromagnetic noise problems with the cables. There are 12 local
field stations a.round Storage Ring, 3 around Lina.c and 2 a.round
BTL. Multiple VMEbus crates in the MIU are interconnectedwith VMEbus-to-VMEbus repeater module..
A development environment is being set up for the development of SCC and MIU. This environment is composed of development hosts and target VME assemblies, which are connected
through Ethernet(TCP /IP). Motorola's SYS1147™ VME station, which uses MVME141fM as its single board computer, isused for the resident development host, and Sun Micro Computer
Corp.'s SPARCstation/IPC™ is used for the cross development
host. Microware's real-time opera.ting system, professional OS9™, is ported to the resident host and industrial OS-9™ is
ported to every target VME system. Initially, this development
environment will be used ma.inly for the development of the beamdose orbit correction system and the modulator/klystron control
system.

S03SRD11
148

Status Reports: Design/Construction

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingported to the operator. These values are archived in files at thesame time. The differences might be compensated by a slow
feedback control program as long as there is no serious failure
in correction. Continuous failure in correction would result inan alarm situation, which would be reported to the operator immediately. Any fault in apparatus should be reported to theoperator, who can cope with it appropriately.
A total of 110 man-month is estimated to be necessary to develop the machine control software including the man-machineinterface, for both storage ring and linac .

Data Communications Network
The components of the PLS control system are linked via twolevels of data communication networks; a low level and a highlevel network. The low level network is used for data acquisition
and forwarding of control commands. The high level network
delivers operational setpoint values to the lower level computers
and information acquired by the lower level computers to theconsole computers.
The low level network must be tolerant of electro-magnetic
noise because MIUs should be installed close to various noisegenerating equipment and cables. Due to this requirement, MILSTD-1553B specification is used. MIL-STD-1553B is a multidrop network specification which is operated in a master/slave
mode on which one Bus Controller(BC) may communicate withup to thirty Remote Terminals(RT). The SCC acts as the BC
and the MIUs as RTs.
For the high level network, Ethernet is chosen because of its
popularity which allows cheap and easy implementation for both
hardware and software. TCP /IP will be adopted as the higher
layer protocol for the same reason. Ethernet is a CSMA/CD
network with a maximum transfer rate of 10 Mbps. However,the length of transmitted packet and transmission speed must
be carefully selected to guarantee the appropriate transfer delay
time and throughput.

Database
A comprehensive database defines all machine parametersand device signals. The database is generated in one of the console computers. The generated database consists of two parts:
the static and the dynamic part.
The static database includes static machine parameters anddevice information such as names, locations, and various coefficients which might be used to convert scientific units into actual
signal values, and vice versa.
Generated static database should be shared among the console computers by transferring the static part and maintaining
consistency between the original and copies. Appropriate portions of the static database should be downloaded to the secs
to be used to control each subsystem properly. The SCC might
download parts of its static database to MIUs under its control.
MIUs use this static database to convert scientific setpoint values into actual control signal values or actual monitoring signal
values into scientific readback values.
The dynamic database consists of setpoint values such as
magnet power supply currents and cavity gap voltages, and readback values such as ion gauge currents, magnet power supply
currents and cavity gap voltages.
Dynamic database on a console computer has just a structure at the very beginning. It might be filled with valid data,when a control process which might need appropriate data weresp~wned. The valid data should be transferred from the appropriate SCC to the requesting console computer on "Supply-OnDemand" basis. Setpointing might also cause updating part ofdynamic database with set point values.
For the PLS database structure, we took the idea of SPEAR's
database system, since it is fairly portable and helped us to save
development effort[4]. However, the update policy of dynamic
data is quite different between the two database systems. PLS
has d'.stributed databases on the secs, the data of which can bes~pphed to upper layer computers on "Supply-On-Demand" basis. On the contrary, SPEAR has centralized database which iscontinuously updated by the hardware. We expect our scheme tomaximize the network throughput by keeping unnecessary datafrom ?eing transferred via network. Resulting gain in network
capacity could be used for faster data acquisition of any particular signal group.

Software
System software
A real-time operating system should be used for the SCCs
and MIUs because some machine control jobs such as closed
orbit correction requires real-time performance. OS-9™ fromMicroware Systems is selected because of its advanced kernel
functions and variety of software development tools. OS-9™
not only provides a real-time kernel and its associated systemmodules, but all the file managers and device drivers necessary tosupport integrated i/o processing. The user interface includes aneasy-to-use UNIX-like shell, hierarchical directory /file structure
and over 70 utility programs to allow simple user access to theoperating system's management functions.
The database on the SCC contains all subsystem parameters. It also has a component table which acts as a name severproviding the translation between the different symbolic names
allowable at the high level and signal names in the MIUs, aswell as linking these names with addresses of the appropriate
MIU. The database on the MIU contains component data suchas hardware addresses, set values, limits, conversion and calibration factors, and so forth.
Machine control software
Operating status of each subsystem such as vacuum, R.F.,
and magnet power supply subsystem should be displayed orarchived to files, which might be later processed to analyze theoperating history.
Desired setpoint values such as magnet power supply current and cavity gap voltage should be set. Setpoint values andother operational parameters might be put into the control system manually by the operator or automatically ~y the control
software.
.
. Intolerable differences between setpoint values and correspondmg readback values should be continuously monitored and re-

Beam diagnostic software
Knowledge of accurate machine parameters is very important
for the efficient operation and study of the machine. We intend
to automate all the beam diagnostic processes with various beamdiagnostic programs such as beam orbit measurement real timeorbit correction, tune measurement, beam lifetime, b~am emittance, and lattice function measurement, etc. Some diagnostic
software will be run at the low level control computers for the·S03SRD11
Status Reports: Design/Construction

149

149

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

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-S03SRD11

real time beam diagnostics and feedback.
Modeling and simulation software
Traditionally commissioning of particle bearnlines is a very
time-consuming and laborious task. Even in day-to-day operation after start-up, various types of machine and beam errors
have to be corrected. To reduce the time and effort for thesetasks, fast and easy-to-use computer programs are needed.
Conclusion
An important requirement in designing PLS control system
is flexibility. Natural growth of the system will require expansionof the control system or more complex control of the accelerator, and it is often necessary to implement new technology on
the existing control system. We have designed a control system
which makes substantial use of industry standard components,
thus maintaining a very good level of flexibility and expansibility. we expect (and hope!) that industrial development of thesestandard component will procede faster than the ever increasing
requirements on the PLS control system.
References[1] S.C.Won, Jae W. Lee and Jinwon Lee, "Computer control
system", PLS Conceptual Design Report, pp. 2-101, POSTECH,
Korea, Jan. 1990
[2) S.C.Won, Jae W. Lee and Juno Kim, "Computer control
system for PLS", Proc. of the 4th Asia Pacific Physics conference, Seoul, Korea, Aug. 1990, pp. 1114-1117[3] S.C.Won, Jinwon Lee and Ji Hwa Kim, "DACS(Data Acquisition and Control System) for PLS", Proc. of the 4th Asia
Pacific Physics conference, Seoul, Korea, Aug. 1990, pp. 11391142[4) S. Howry, T. Gromme, A. King, M. Sullenberger, "A
portable database driven control system for SPEAR", SLACPUB-3618, SLAC, Apr. 1985

S03SRD11
150

Status Reports: Design/Construction
150

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

Ethernet

MAP

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD12

Ethernet
to other LAN

MAP

N

:Node

L : Unac
Sy : Synchrotron

VME : Versa Module
European
PLC : Programmable
Logic
Controller

Storage Ring

Sr : Storage Ring

XT: X Terminal

8GeV

BT: Beam Transport

MAP:Manufacturing
Automation
ProtocolFig. 2 The computers and their interconnecting networks.

Ill. COMPUTER SYSTEM

The control system consists of a central control system and several
sub-system for each accelerator. Tbese sub-system and central
control system are linked through computer networks. Each subsystem consists of a host computer, several front end processors(FEP) and an operator's console. Figure 2 shows schematically thecomputers and their interconnecting networks. The function of each. system are:

The FEP's are distributed throughout the power supply rooms andon the circumference of the storage ring building, and the maximum
length of the networks will be about 1 km. Tab_Ie I shows theestimated number of input/output points, and the comparison with
KAON facility (2]. Where LS-BT means beam transport line
between linac and synchrotron, and SS-BT between synchrotron andstorage ring. More than 200 VME system are to be used in wholecontrol system.

A. Central Control System
1) Selection ofoperating mode and scheduling;2) Monitoring, logging, and display;3) Linking with other computer system such as that of the computer
center, of experimental system, and of a radiation safety control
system.

Table I Estimated numbers of input/output points.

B. Program development and Darabase
S P

Central management of application programs and database:r I n g - 8

Part

C. Accelerator Control System

DO

The control of injector linac, the synchrotron, and the storage ring.
These sub-system controller are loosely coupled, due to the different
accelerator construction schedules and the convenience ofindependent operation and maintenance.
At the lower hierarchy level, some FEP's are linked. These FEP's
are microprocessors such as VME and programmable logic
controllers (PLC). When high-speed data processing is required,such as by a fast digital feedback system, a VXI system will be used,since the data transmission rate of the VXI bus is much higher thanthat of VME system.
Workstation (WS) or X terminals are used as operator's consoles,
which perform X-window servers.

S1£nalsDI

AOAI

T R I UMF
DO

DI

AO

AI

7973

16310

2554

10214

S03SRD12
152

Status Reports: Design/Construction152

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

IV. NETWORK SYSTEM

VI. TIMING SYSTEM

As is shown in Fig. l, a so called multi-media LAN will be adopted
for backbone control, with full- and mini-MAP LAN for real-time
control. Voice signals and TV signals are also transmitted on FDDI
(Fibre Distributed Data Interface) cables. MAP has two advantages
over Ethernet (TCP/IP). One is that messages are exchanged bytoken-passing method. Henc~, e~en under heavy ?'affic co:i~itions,real-time response can be mamtamed. The other is that m1m-MAP
bypasses the middle 4 layers (3-6) of the 7 OSI layers. Thereby
quick response is achieved.

The common clock (508.58 MHz) is distributed with temperaturecompensated optical fibers to the linac, the synchrotron, and ~hestorage ring. Trigger request pulses are to sent from. the storage _nng
to the synchrotron and from synchrotron :o the hnac. Rece1~ed
devices generate beams after accurate delay time. We are developing
an accurate delay pulse generator using GaAs preset countercircuit. [5].

VII. R&D

V.SOFTWARE
A. Operating System
An UNIX is used for upper level computers, and real-time OS for
FEP's. Table 2 shows examples of commercially available real-time
OS[3]. Some of them conform to IEEE POSIX (portable operating
system interface for computer environments) standard. An actual
performance measurements have been reported on four kernels, allrunning on the same hardware platform f4].

B.Language
The candidates are Pascal, c++, and Ada which are appropriate forobject-oriented programming. C and c++, however, are the main
candidates because many program developing tools prepare C libraryfunctions as application programming interface. FORTRAN is usefulfor large numerical calculation programs, sue~ as .COD correction~ ..
For the effective development of application programs, It 1s
convenient to use computer aided software development tools, suchas CASE tool and GUI developer.

C. Artificial Intelligence
We intend to use expert systems mainly for alarm message handlingsystem, and partly automatic operations. Introducing an AI tool,"NEXPERT OBJECT", a feasibility study of an expert system for theoperation of a test stand of a klystron is started.

I). Development of accurate timing system for a 508 MHz clock.
GaAs preset counter,
E/O and O/E for optical fiber cable with small temperature
coefficient.
2). Development of a pattern generator for the synchrotron operation.
3). Development of a field level bus.
4). Control of a klystron test stand.
HW: EWS, X-terminal, VME, Ethernet,
SW: UNIX, LynxOS, C, TCP/IP (socket),
GUI: Xt, ("SL-GMS"),
AI: "NEXPERT OBJECT"

VIII. REFERENCES[I] H. Kamitsubo, "8 GeV synchrotron radiation facility project in
JAERI-RIKEN SPring-8 Project", Nucl. Instr. and Meth.
vol. A303, pp. 421-434, 1991.
[2] W, K. Dawson, R. W. Dobinson, D. P. Gurd and Ch. Serre,"A Conceptual Design for the TRIUMF KAON Factory Control
System", TRI-87-1, 1987.
[3] Partly from T. lmai, Nikkei Electronics, no. 517, pp.149-153,
1991 ( in Japanese).
[4] K. Low, S. Acharya, M. Allen, E. Faught, D. Haenni and
C. Kalbfleisch, "Overview of Real·Time Kernels at theSuperconducting SuperCollider Laboratory", in 1991 IEEE
Particle Accelerator Conference, San Francisco, CA, May 6-9,
1991.
[5] T. Kumahara, T. Wada, H. Yonehara, and H. Yoshikawa,"Design Concepts of The SPring-8 Control System", in 7th.
Conf. on Real Time Computer Applications in Nuclear, Particle
and Plasma Physics, Julich, June 25-28, 1991.

Table 2 Examples of real-time operati~g system.
OS NameCompanypSOS+

VRTX32

VxWorks

VMEexec

EXECUTIV

Microprocessor

Ready
Software
Systems romponents
680X0,80X86
680XO

Bus
Network
Protocolnot fixe
Ethernet
TCP/IP.xedt ernetTCP/IP

VMEbusEthernet
TCP/IP

8

11.5- 13

256
256
0

65535
255

so-'"
,_
10
65535 ~
t
32767

Kernel Slze1KBl
Task
Max. no.
Priority
MultiBus
Processor Network
rile System

SPARC~6u

MS-DOS~t~d.
MS-DOS

Wind
River
680XO

Motorola
680XO
88000
VMEbusEthernet
TCP/IP
UDP/IP255~T

JMI Softwa Microware,..._onsul tant Systems
80386,1486
680XO
80286
not fixed not fixed
Ethernet
Ethernet
TCP/IP
TCP/IP

32767

n

x

()
11,UNIX, Fast
MS-DOS
System
19µ s
17 u s
8µ s
6µ s

OS-9000

x
MS-DOS

53
No Limit
65536
x
x
Dedicated,
MS-DOS
220u s
40µ s

LyrutOSPDOS

EyringLynx~eal-Time S Research I
30386,680XO
680XO
lt860,88000
not rrxed
Ethernet
ctnernet
TCP/IP
TCP/IP
190
No Limit
32
_\.!
~

25
225

n

1-nodewitchin<r
15u s
19u s
17 µ s
26.2.u s
13.u s
10µ s
nterrupt
7.u s
NA
30µ s
Vai t Time
Measured B8020,25MHz p8020,25MHz 68020,25MHz p8020,25MHz p8020,25MH B0386,20MHz ~0386,33MHz 68020,20MHz
ondl tion
1 Waitno Waitno Waitno WaitAP Language
C,ASM,Ada C,ASM.Ada C,ASM,Ada
C,ASM
C,ASM
FORTRAN,C
C,ASM
f'ORTRAN,CFORTRANFORTRAN
ASM,Adaf\SM PASCAL
Environment forUNIX.VMS
UNIX
UNIX
ANY
OS-9,UNIX
Self
UNIX
Self
DevlQpment
OS-9000
UNIX PC
UNIX
Exec.
Time

S03SRD12
Status Reports: Design/Construction

153

153

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD13

fovels. The number of hard wires is the number of the ·emergency levels, and each hard wire is connected in series· with same emergency level signals. Inter lock process on thecomputer sends the detail of what kind of inter lock works to
the host computer.

CONCLUSION
Conceptual design of the linac control system is almost
finished, and development of the system for a test stand will
be started from next June. Coding of software is started
already, and now modification of network protocol is goingon.

Unac Control System Diagram
Backbone LAN

Linac CotTPuter-,----T--.---'----.1
I

I
I

4-.......---'I

I

VacuumS03SRD13
Status Reports: Design/Construction

155

155

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-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 PublishingSY SYSTEM

Etberut

Perlpher als
Ethernet

Terminal Server

BridgeYAX Station
3100/76SPl

1 4

14" Tor111l1I

.....

I

4
8T CPU

RF CPU

Monitors

YME CPUs

PLC

Fig. 2: A control system for HIMAC synchrotron.
3100/76SPXs with 16 MB memory a.nd 104 MB disk a.nd
two 14-inch terminals a.re installed a.t ea.ch console for operation a.nd display. Touch panels a.nd rotary encoders a.realso equipped a.t the consoles a.nd almost operations a.re
perlormed by them with common procedures to the othersub-systems.

YME CPU ---YAl4000/3110
YME bu1

TRANSCEIVER

RF computer
A dedicated small computer connected via. Ethernet
controls the RF system including position monitors. Details of the RF control system a.re described elsewhere[3].

PROGRAMMEMORYFATTERll
MEMORY A

PATTERNMEMORY 8

OSP but

BT computer

DO & STROBE

The injection line from the injector sub-system a.nd
the extraction line to the high-energy bea.m transport subsystem a.re also controlled by small computers. Devices
in both lines a.re ma.inly de magnet power supplies, beam
monitors a.nd vacuum pumps except for a. pulse magnet
power supply to switch the injection beam to the upper a.nd
the lower rings. Device status, para.meters a.nd measured
data. a.re transferred through Ethernet.

CLOCK & CONTROL SIGNAL

POWER SUPPLY

Fig. 3: A blockdia.gra.m of the FDO module. The FDI
module has almost the same structure.

The VME-computers communicate with VAX4000/300 via.
Ethernet and control de power supplies through the DI a.nd
the DO modules.
A Programmable Logic Controller(PLC) is used as a.
On the other hand, the FDI a.nd ·the FDO modinterface between VAX4000/300 a.nd the power supplies inules have been developed to control power supplies which
the ma.in rings to communicate ON/OFF commands, sta.should be operated with a pattern, such a.s a bending, atus signals a.nd warning signals, although device para.mequadrupole and a. bump magnet power supplies. A blockters a.nd measured data a.re transferred through DI/DO,
dia.gra.m of the FDO module is shown in Fig.3. The FDO
FDl/FDO modules and VME-computers.
module has a. Digital Signal Processor(DSP) a.nd two pattern memories(A,B). The DSP sends data. from the selected
Power supply controller
pattern memory to a power supply synchronizing with a.n
All power supplies in the main rings a.re controlled by external clock of 1200 Hz. While the DSP is reading andpower supply controllers which consist of micro-computers sending the data on the selected memory, new data ca.na.nd Digital 1/0, Fa.st Digital I/O modules based on the be written on the other memory, a.nd then the memory is
VME standard. We plan to use 68000 family CPUs switched quickly from one to the other. The FDI moduleand a. real-time, multi-tasking operating system, PDOS. has almost the same structu~e a.nd functions. This func-

PLC

S03SRD14
Status Reports: Design/Construction

157

157

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-S03SRD14

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.----0ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S03SRD14l - - - 2--t (sec)FOO FOR CURRENT PATTERN] 111- --- - ,, ..,..,. ,... -----111111 Q G

I"""'O"

Br-:=~ 1---· ~u·· [I · """'°"' • •••.. I
mo ""' ,,.,. " " "

Q
LIHAC

Fig. 4: A schema.tic view of the timing system. The FDO module is a.lso used here.
tion pla.ys a.n important role for a. repetitive feed-forward
pattern control of the bending a.nd the quadrupole magnet power supplies in the ma.in rings. In the feed-forward
pattern control, the FDO module sends the reference da.ta.
a.nd the FDI module receives the measured data.. Then the
VME.computer ca.lcula.tes the correction pattern from thedifference between the reference a.nd the measured data.
using a. transfer function of the ma.gnet system a.nd writes
the new pattern on the background memory while the foreground memory is fa.cing the power supply.

tion with the clock of 1200 Hz. The FDO module for thetiming system has the data. of the sa.me size. In this case,however, not the 16 bit da.ta. but the rows of 0th - 15th
bit ha.ve meaning because each bit is assigned to a specific event, for example, 'BEAM INJECTION', 'RF ON',
'ACCELERATION START', etc. The event signal corresponding to ea.ch bit is generated at the time when the bit
is 'ON' or 111 a.nd delivered through a. delay controller.

TIMING SYSTEM

The authors wish to tha.nk many of their colleagues
concerned with the HIMAC project for their helpful discussion and a.dvice.

ACKNOWLEDGEMENT

A timing system is very important to synchronize thesub-systems because each sub-system is designed to be operated rather independently except for a. software interlock
among the sub-systems. Event signals ate generated in thesynchrotron sub-system and delivered to the own and theother sub-systems by ha.rdwa.re. As the bending magnet
power supply consists of 24-pulse thyristor rectifiers andmust be operated in synchronization with the a.c power lineof 50 Hz, the timing system generates clock signals of 1200
Hz (50 Hz x 24 pulses) phase-locked to the ac line voltage.
The FDO module is also used for the setting of the event
signals. A schema.tic view of the timing system is shownin Fig.4, where the synchrotron is operated, for example,
with the repetition rate of 0.5 Hz. The FDO module forthe current pattern data. of the bending ma.gnet ha.s 2400
data of 16 bits and they a.re transferred in synchronizar

REFERENCES(1) K. Sato et al., "Hea.vy-lon Medical Accelerator in
Chiba.(HIMAC)", Particle Accelerators, 33, pp.147152, 1990.
(2) T. Kohno et al., "Control System for HIMAC Injector", Proc. of 7th Symp. on Accel. Sci. & Technol.,
RCNP, Osa.ka, Ja.pa.n, 1989, pp.246-248.
(3) M. Ka.na.zawa et al., "RF Control for HIMAC Synchrotron" 1 in these proceedings.

S03SRD14
158

Status Reports: Design/Construction

158

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-S04SRS01

ill. LOCAL CONI'ROLThe control layout for the equipment of the RF unit,
situated in racks underground in the klystton gallery beside the
LEP machine tunnel, is shown in Figure 1.
DATA MANAGER

preset array stored in battery-backed-up memory whichindicates active ECs. The DM also executes control procedures
involving access to various pieces of equipment, for example
HV switch-on, RF switch-on, RF ramping and local
surveillance.
For example the RF switch-on procedure for the SC cavity
units involves the presetting of the various control loops,
setting of initial klystron input drive level and cathodecurrents, clearing of any RF interlocks, setting the tuning to
the correct mode and setting nominal tuning system reference
values. After RF switch on klystron drive level and current are
slowly increased to a given value of total forward power,
sufficient to allow the cavity tuning systems to operate in thepresence of LEP beam. As the cavities approach resonancethey are slightly detuned by introducing a tuning reference
offset to avoid producing full RF voltage and resulting large
variation in synchrotron frequency. Once all cavities are in thisstate the voltage control loop is switched on, the tuning of allcavities returned to nominal and the starting RF voltage set
While this and other procedures can be different from thoseof the copper cavity units they are called up in exactly thesame way. All equipment and hardware dissimilarities arehandled as far as possible by the DM and the ECs.

IV. OVERALl.. CONfROL OF TIIE LEP RF SYS1EMINCLUDING SC CAVITY UNITS

Figure 1 Control Layout within an SC Cavity RF Unit
An EC is dedicated to each major element of the unit i.e.
HV equipment, klystron(s), low-level equipment, waveguidesystem, cavities and cryostats. For the SC units one or two
klystrons can be installed, depending on available beam
intensity. Second low-level and waveguide system ECs areallowed for to give independent RF operation of two ' · -.111cavity sub-units if two klysttons are used. Overall cor
each RF unit is provided by a VME based "Data 1- 1
(OM) running a multitasking operating systr. 1t
communicates with the ECs via two local IEEE .., (GPIB)

buses.
The DM provides remote and local access to all equipment
parameters via the ECs either singly or in groups. The DM
equipment access functions have been modified for the case of
the SC unit in order to cope with the various configuration
possibilites. The low-level bus access routines make use of a

The DMs at each point equipped with RF areinterconnected by an Ethernet segment and to the general LEP
control system Token Rings by bridges.
The principles of operation for the SC units are exactly thesame as for the copper cavity units. Direct remote access must
be provided for all equipment functions in view of the large
amount of equipment and the long distances from the control
centre. At the same time maximum use is made of local
intelligence at the levels of the DMs and ECs to reduce theamount of accesses required for standard operational procedures,such as switch on and setting up the RF voltage ramp for
acceleration. These procedures are initiated by simple
commands, the same for both SC and copper cavity units, andare normally carried out simultaneously in all units.
The Apollo workstations used for LEP operation in thePrevessin Control Room (PCR) communicate with the DMs
and ECs over the network and local buses. Network
communications are based on standard TCP/IP socket libraryroutines[2]. Simple protocols based on command responseusing strings of ASCII characters are used throughout. The<'!ommand fonnats sent resemble their corresponding equivalent·c" language functions with additional infonnation denoting
the unit and equipment EC to be accessed. The equipment
access functions are implemented as simple macro definitions
which invoke command response and appropriate data
conversion procedures.
For example in a local DM program the "C" language
function "s_valve(C9,3,40.0)" will cause the string"s_valve(3,40.0)" to be sent to the EC of cavity 9 requesting
it to set helium gas valve 3 to 40 per cent of its range. The

S04SRS01
160

Status Reports: Subsystems

160

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

EC carries out the action and returns a reply in string form
e.g. "OK" for successful completion. Similarly thecorresponding function at the level of the PCR workstation,"LRFSetValve(LRF_233,C9,3.40.0)", causes the string
command "C9_RS,O_O,s_valve(3,40.0)" to arrive at the DM
ofLEP RF unit 233. The command format is compatible with
the LEP standard command format intended for communication
over the MIL-1553 bus : C9 is the device to be acted on inmember 233 of family LRF and RS denotes that a reply instring form is expected. The reply is always in string form andwhen a numerical reply is to be returned it is converted at thesource. the appropriate function being part of the macrodefinition.
This method first of all allows simple direct command
response for remote access to equipmenL This low-level accessis essential in initial commissioning and has proved to be ofvalue later on for troubleshooting. The command format
reflects the logical path to the equipment and the function
itself can be clearly understood and easily remembered by theequipment specialisL The underline character in the example
given is included in all commands which change equipment
states or values to permit a simple equipment protection
system.
Secondly, the method of implementing equipment
functions as macros based on the same simple directcommand/response communication protocols allows
straightforward build-up of more complicated software, both atthe levels of the DM and the PCR workstations. The total
number of functions defined both for the DM and for the PCR
workstation is over 300, of which around SO are specificallyrelated to SC cavity control and data acquisition. The initiation$ld monitoring of DM procedures is done in the same way, inthis case the equipment accessed is the DM itself.
PCR application programs for overall RF operation are
based largely on the use of these DM procedures. They are
essentially data driven. Use is made of a table called the RF
current data set (CDS) which is set up by the operator toindicate to the program which units are to be acted on. The
table is stored in the standard Table File System (TFS) format
used for LEP applications software data. The RF CDS also
contains data such as HV settings and available RF voltages
for the various RF units. This means that one piece of
application software can handle both SC and copper cavity RF
units without the type of each unit having to be checked.
For the copper cavity units a large amount of software,
based on interactive graphics packages, has been provided for
the RF equipment specialists to show the detailed state ofoperation of the various pieces of equipmenL The preparationof equivalent software to handle SC cavity and cryostat
equipment is in progress.

operating system "data module" in the fonn of a s1ructure. The
unit configuration must be taken into account by thesurveillance program and it deduces this from the contents of
the active EC array. The data structure contains approximately
300 integers, strings and floating point values and is updated
every 15 seconds. The infonnation is also stored in a cyclic
buffer in the local memory of the DM. At present up to one
hour of data can be stored, but this will be increased by adding
more memory to the DMs. The structure is transferred to thecontrol room on request using TCP/IP protocols directly over
Ethernet and Token Ring. It is used for overall logging of RF
system performance and also for a permanently updating PCR
display of RF system status.
The DM also carries out logging of parameters of special
interest for cryogenics. Helium levels and pressures, RF
powers and cavity temperatures are measured every 1S minutesby a background program and stored in ASCII form on local
hard disc in TFS format. These files can be read remotelyusing Telnet or copied using FTP.

V. SURVEllLANCE ANDDATAl..oGOING

In the same way as for the copper cavity RF units a DM
background local surveillance program gathers the mostimportant states, settings and readings from the SC cavities
and other equipment in the RF uniL The data is stored in an

VI. OPERATIONAL EXPERIENCE AND
CONCLUSIONS
The incorporation of the first SC cavity RF unit and its
operation with the rest of the RF system has proved
straightforward. The SC cavity unit is now routinely usedduring the running of LEP and its operation is treated in thesame way as the copper units. As in the case of the copper
cavity units the response time overall of the control system isadequate and its reliability good.
Whilst the software facilities for PCR operation are ascomplete as those for the copper cavity units, those for thepresentation of collective data and detailed equipment states forthe specialist await completion. In addition initial running-in
experience has shown a need for more rapid monitoring, forexample to help in the diagnosis of certain faults or when in·situ conditioning has to be carried ouL The possibility oflogging helium gas pressure and RF level for example and thedetection of transients is envisaged. Special inslrumentation,connected via the GPIB buses, to measure such parameters
will be installed.
The gradual introduction of more SC cavity units will
require practically no modifications to existing operational
procedures. The control system hardware is finalised and in
production and software facilities will be expanded as LEP200
installation progresses.

VII. REFERENCES[1)

E. Ciapala and P. Collier, "A Dedicated Multi-Process
Conlroller for a LEP RF Unit", in Proceedings of the 1989
Particle Accelerator Conference, Chicago, March, 1989,
pp. 1583-1585.
[2] E. Ciapala, P. Collier and P. Lienard, "Use of Ethernet and
TCP/IP Socket Library Routines for Data Acquisition andConlrol in the LEP RF System", Contribution to the the 1991
Particle Accelerator Conference, San Francisco, May, 1991.

S04SRS01
Status Reports: Subsystems

161

161

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

Operating Systems and File Servers

More than 80 ISA (PC/AT) boards are being installed indifferent PCs or PC expansion chassis. 8 FECs are necessary,
controlled by 3 consoles in the control room (or any office
PC).

These FEC, alias hardware servers, are running MS DOS
and the Nodal for DOS program. The Nodal for DOS programis an environment that provides:
An equipment server to all consoles. The built-in
network listener allows the consoles to access theequipment attached to the FEC.
A local nodal interpreter that allows access to theequipment from the FEC. This is used mainly by
the equipment engineers to test modules locally.
Local alarm treaunent
The Netware file system can be mounted also from
Macintosh via Appletalk as an Appleshare file server andfrom Unix workstation via TCP/IP as a NFS server. All the
Isolde databases or documentations in Word™ or Excel™
fonnat can then be retrieved.

Numbers, manpower and financial resources

The manpower necessary to design and install the wholesystem is about 3 man*year.
Costs are equally divided between acquisition boards andcomputers. About 100 KCHF have been invested in PCs andthe same amount in ISA boards. Wiring costs, 50 KCHF, are
not included.

III BASIC TOOLSGraphic User Interface (GUI)The graphic user interface is Microsoft Windows™ and it
provides a common access to all applications. The shell tostart the different applications is the default Windows
Program Manager.
[lie J!pllon•

t4

11!1111:ttlndow li•lp..
Odd"""

fi
-

=-=

g'j

~$"""' FllWM-.

~

g'j
~

"-

7 1 ti_<1...,..c:n•a~~~~Iii
...

8-Lre

V-

i.r.l~A1""-U""'-

tim tim 1m1 tim mm . . ifil,.. ·mi 1m1
a- C....-- S- --.s"4N·""'°~ D -u..

The program manager· Icons and menus oriented shell

Documentation
All documentation is produced using Microsoft Word™
for Windows, and is available on-line on the Isolde Server.

Databases

The CERN Isolde Facility

Databases are built using Microsoft Excel™. Database arestored in the native Excel fonnat (BIFF) or in Comma
Separated Value (CSV) fonnat when they must be accessible
from C or Nodal programs. The system is entirely databasedriven using Excel.

To quantify the dimension of the project, the control
system comprises: 2 Faraday cage 60 Kv power supplies, 6Extraction electrodes, 27 Faraday Cups, 5 Slits, 5 Lens
Collimators, 15 Beam Scanners, 5 Wire grids, 6
Thennocouples, 18 Target power supplies in 60 Kv faraday
cage, 9 Beam gates, 3 Separator Magnets with gauss meters,
58 Quadrupoles, 25 Steering Quadrupoles, 8 Kickers, 7Benders, 4 Correction Plates, 3 Multipoles, 5 Deflectors andthe Vacuum system. This gives roughly 300 devices(elements) and 1700 analog or digital wires (control channels)
coming into the control system on three buses (CAMAC,
GPIB, ISA).
On-line databases

S04SRS02
Status Reports: Subsystems

163

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

The whole system is built on a commercial PC network,
Novell Netware™/386. This network provides a shared filesystem, shared printers, peer to peer and peer to server
communications that are used in the control system to share
databases and to share the hardware equipment between
different consoles. The FECs are in fact just seen from theconsoles as equipment servers to which client requests can be
sent.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS02

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

An Excel based application

AlarmsAn alann process is running in all Front End Computersand systematically checks for inconsistencies in the element
status or in the difference between acquisition and control
values.

The third environment where control applications can beproduced is the Microsoft Windows Software Development
Kit™ (SDK). Any application can be written in thisenvironment and high performance and acquisition rates canbe achieved.

The alarm process has a list of active alarms that arepolled by the alarm program running in the console. The
Alarm program in the console is normally minimized in agreen icon that becomes red when there are active alarms.

file

CAO.FC30

fAllADAYCUPk

I

An SOK application

The Alann eye

Applications

SecurityThree environment are available to develop applications.
The first is Windows Nodal that provides a Nodal language
interpreter with graphics capabilities that emulates theexisting Isolde console.

Any application accessing the hardware must be attachedto the Isolde Disk server where the client applications are
stored. To attach a Netware file server a usemame and an
encrypted password must be provided. In this way the Isolde
Control System inherits all the security features that the
Netware environment provides that are widely used by banks
and other commercial Networks. In particular, it is possible toaccount the usage, to restrict the hours or days of the week aparticular user can attach, to limit concurrent connections,force systematic password changes and several other features.

Using Nodal for Windows it is possible to run all old
applications developed in the Isolde history. The existing
isolde console is made of a keyboard, a track ball, analphanumeric display, a graphic display, two hardware knobs
and a touch panel. Nodal for Windows emulates all these
peripherals and permits reuse of the old software (see next
section).
The second environment where. control applications can be
developed is in any application that supports Windows'
dynamic data exchange (DDE). Several high levelapplications with programming facility could be used, forexample Actor™, Toolbook™, Microsoft Word™ andMicrosoft Visual Basic™. The recommended tool of this levelis Microsoft Excel™. The Spreadsheet facility can be used tocorrelate physical quantities to control parameters and viceversa.

IV DEVELOPMENT TOOLS

Windows Nodal
The Nodal for Windows interpreter allows to run all
existing Isolde software and permits the development of new
applications. Interaction with the user is done using the two
knobs and the touch panel. Data are presented in thealphanumeric and graphic displays.

Nodal !or Windowa

S04SRS02
164

Status Reports: Subsystems

164

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

ICALEPCS1991, Tsukuba, Japan

Programming in this environment does not require any
particular skill beside having read the Nodal manual.

An Excel course for beginners is enough to allow aphysicist to start building the applications himself.

Microsoft Exce/1'"

Advanced Excel features can be used to produce
applications with their own pull down menus and dialog
boxes. The Excel Dialog Editor can be used for this purpose.

The spreadsheet facility provides the possibility of having
hot-links, i.e. dynamic links between a cell in a spreadsheet
and a particular property on a particular equipment, forexample the acquisition of the current in a magnet. The
spreadsheet cell is updated automatically whenever thephysical acquired value changes. Formulae can be used to
calculate from control parameters acquired with hot-links any
physical quantity related to the parameter. All calculated
values are, of course, also automatically updated when any
quantity in the control system changes.

Windows Software Development Kifl'" (SDK)
There are different tools available to design Windows
applications, for example, the Dialog, font and Bitmap
Editors, or the CodeView Debugger for Windows.

-~

Iii

SDKIW- DillogE"""

rt

F<riEdlo<

~

p-

Z-U~

ID ClV

Shlbr

Ill

SDKP•

~

t:odo'{-

~

...

II

sS'
HMoW'-

1(30051"'""1

ll
1
2

GHM.
Volts•The SDK tools as example,

. GHM

3

Writing applications using the SDK gives very highperformances but a good knowledge of the C programming
language and of the Windows architecture is necessary.

Microsoft Quick 0 14~-- ...._.._., ..... __.., ..
,_..........,.._...._..._ _,.""'=",,,,,,,._,
lo Hcudwnra

Example of application development using Excel

Basic macros, usually written automatically by the Excel
Macro Recorder, allows to execute complicated algorithms.
When attached to push buttons on the spreadsheet, macros
allow to trigger complicated measurements, start optimization
processes or to write calculated values to the hardware.
The Excel charting facility is used to produce graphics foranalog presentation. Charts are normally also dynamicallylinked to the hardware properties and dynamically updated inreal time.

The major tool used to develop Equipment modules is
Microsoft Quick C. Beside providing an interactive EditCompile-Link-Debug environment as if C was interpreted, it
has also on-line the complete C language reference. This
context sensitive hypertext documentation provides also readyto run examples of all C library functions.

V CONCLUSIONS

Simplicity
Using the same type of computer (ISA PC compatible) at
all levels of the control system leads to uniformity andsimplicity. This advantage is reinforced by using the same
operating system as the office machines.
All the persons involved in the design of this control
system master it completely and are able to solve any problem
at any level, front end or console. This global view on an
uniform system reduces the skill necessary to cope withdifferent parts of the system, because the approach is always
the same, data driven from the Excel Database.

Development timea dynamically refreshed chart

The use of well tested, market leader products. (hardware
and software) has reduced the development to a strict
minimum. The very few necessary development done with theavailable tools have shown that:
Development is very quick because of the user
friendliness of the tools and because the SOK,
the Microsoft C and QuickC compilers offer

S04SRS02
Status Reports: Subsystems

165

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

Excel in addition to its database facility. provides
spreadsheets, charting, database and advanced macro
programming facilities.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS02

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

incremental link and compilation options and run
time dynamic link.
Infonnatic skills are not necessary: Physicists andengineers can write their own programs after very
tittle training. ·In particular, the time to develop the application
programs, nonnally the stumbling block in most control
system is very significantly reduced: for example, it does nottake more than 10 minutes to build a simple application using
Excel to display graphically several parameters acquired fromthe separator.

Integration
The Isolde control system, although completely
independent in case of problems, is transparently connected tothe office network and all its services are available.

manufacturers. The PC production is more than 10
Millions/unit per year with perfonnances increasing by afactor of 2 every year.
It's a world wide standard, with binary compatibility, withmajor European involvement such as Olivetti, Philips, Bulland Siemens. A chassis, made in Europe, to control 48 power
supplies (48 ADCs, 48 DACs, 288 digital 1/0) cost about 12
KCHF. The cost per control channel is 9 CHF per digital bit,
55 CHF per ADC channel and 155 CHF per DAC channel.

LimitsThere are no limits to the numbers of control channels thesystem can handle. If more are necessary, just add more FEC
and more consoles.

Beside providing an access to the Isolde control systemfrom nearly 1600 points at CERN (the number of PCs
installed), it is in the user culture by providing the same userinterface to control applications as to any administrative or
scientific applications. It is of . course possible to
Copy/Cut/Paste between any applications, for example, theExcel chart acquiring the status of the Isolde magnets can bepasted into Microsoft Word to produce a written report.
Development of control application from any office ispossible without the installation of additional hardware.
All A3/A4 laser printers (including the color ones),
plotters, scanners, disks, software and data of the office
network are available, including the support.
By relying on this infrastructure, the infonnation can beeasily distributed cern-wide as Statistics and/or electronic
Logbook, as it is done now for the PS accelerator complex.
As the file base is shareable between different platfonns andoperating systems (Macintosh, Windows, Unix), all data in
Excel fonnat can be retrieved from any user on the site.

Speed
The benchmarks done with the Olivetti 386/25 computers
have shown that these computers are fast enough to control
large processes where dozens of parameters from different
FECs are involved. The margin can be enlarged in this areaby using i486 based 33 MHz machines that are much faster.
The speed of the control system is often limited by the
network used. The Novell network based on ethemet give us aperfonnance of more than 100 Kbytes/second transfer rate on
the busy CERN ethemet. A typical Remote Procedure Callwith a search in the element database to find which FEC andwhich equipment module to call takes less that 30
milliseconds.

A typical console screen

VI REFERENCES[l) D.J. Simon, "Transfer of Isolde to the PS Booster", CERN
PS/PA-EP Note 90-13[2] B.W. Allardyce et al, "Isolde at the PS Booster", to bepresented at the European Particle Accelerator Conference,
Berlin, March 1992[3] O.C. Jonsson et al, "The Control System of the CERN-Isolde
on-line Mass-Separator Facility", EMIS·l2, Sendai, Japan,
September 1991. To be published inNucl. Instr. and Meth. B[4) A. Bret at al, "The Isolde Control System", CERN PS/OP/Note
91-27[5] A. Bret at al, "The Isolde Control System Reference", CERN
PS/OP/Note 91-17[6) A. Pace, "Office Local Area Network at the PS Division",
CERN PS/91-45 (OP)Cost
The market of Personal Computer in the world is roughlyof 80 Millions units and with a strong competition between

S04SRS02
166

Status Reports: Subsystems

166

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

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-S04SRS03

Structure of the system
The main components of the systems are:

CRYRING is equipped with different diagnostic elements
to measure the low energy ion beam profile and current
in the injection lines, to monitor the beam properties in
the ring and to control the frequency of the accelerator
structure keeping the beam centered in the beam tube.

• The main computer, a PDP-11/73, with terminals
and two operators consoles.

THE CONTROL SYSTEM• A serial CAMAC loop for distribution of data andtiming.

The control system is based upon the LEAR control system at CERN. The architecture of the system, as well as
the main part of the software and some parts of the actual hardware implementation are copied from the LEAR
system. The development work in the CRYRING system
has mainly been done in two areas. One is the low-levelinterfacing to our accelerator equipment using microprocessor systems with software written to allow local control
for test purposes and thus make trouble-shooting easier.
The second is the adaption of the software in the main
computer to the actual hardware and to our operational
needs which partly differ from the ones at LEAR. The system controls the whole CRYRING complex, that is the ion
sources, the beamlines and the ring. The electron cooler,
which will be installed this winter, will also be controlled
by the same system. The general structure of the control
system is shown in fl.g. 2.

• A large number of G-64 microprocessor systems forinterfacing to the machine equipment.
A piece of accelerator equipment connected to the system is called a parameter. Analog control signal output
to parameters from interfaces in G-64 systems can be of
two different types: static, controlled directly by the main
computer, or ramped, controlled via programmable function generators in the G-64 systems. These function generators, called GFDs [3], have the shape of the function
down-loaded from the main computer via the CAMAC
serial loop. They can then be started, stopped, held andreleased synchronously with each other by pulses from thetiming system. The timing system [4] consists of one master and a number of decoder modules, all sitting in CAMAC, interconnected with a timing distribution cable.

Terminals

Operator consoles

Computer
PDP-11/73- - - . . . . - - - - ' Ethernet

Serial CAMAC loop

High voltage:••••••••••••>•u•t>•••.,••••,.•

Tlmlng distribution

G·G4
Mlaop10Ceesor
syalem

0
p

u

A

D I

0

O·O

D A I

Synchronl:r:allon

pulses
GFD • Digital Function Generator

Accelerator
Fig 13 The control system.

S04SRS03
168

Status Reports: Subsystems

168

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS03

DIAGNOSTICS

The master and decoders are programmed via CAMAC
by the computer to execute a predifined set of timing
events, a machine cycle. Starting, stopping and repeating the machine cycle is done by external pulse inputs.
This means that once the GFDs and the timing systemhave been loaded the cycling of the ramped parameters isdone without need for intervention by the main computer.

The beam intercepting devices in the transfer lines are
Faraday cups for intensity measurements and strip detectors for beam profile and emittance measurements. Also,
chromium doped AhOs plates viewed through TV-ca/1ne/-ras are used here.
The control system moves these devices into/out of thebeam, switches TV-cameras to different monitors and theread-out of the beam current to selected instruments.

The control of the CRYSIS ion source demands special
flexibility and quick responses, as well as a more developed
local control. These needs have been met by adding a PC
that has access to the necessary hardware via an auxiliary
crate controller in one of the CAMAC crates. This has
requred an optical link between this PC itself and its keyboard, because the PC as well as the mentioned CAMAC
crate is put on a 60 kV platform.

The signals from strip detectors (each detector consists of
16 horizontal and 16 vertical strips) are amplified, multiplexed and sent to ADC's in a VME computer system
placed in the control room, fig. 3.

Status, November 1991:

The control system• has been running since the first parts of the accelerator system were taken into operation in 1987.

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

YME
llU•

• presently controls around 160 static and 20 ramped
parameters. New parameters are successively added.
• allows control from both control room and equipmentareas.
The G-64 systems• control from 1 to 16 parameters each.
Ship d•ltolor •l90lronlo1• have hardware and software tailored for their actual
applications.

Fig 3 Strip detectors.

• can be equipped with terminals and run in local mode,thus making it easier to trace faults in accelerator
hardware and in main computer software.

In the ring non-destructive measurements are performed
using 9 horizontal and 9 vertical electrostatic pick-ups, abeam current transformer and a Schottky noise detector.
The signals from the pick-ups, fig. 4, can be processed bya fast peak-detection system [5] or by using synchronousrectifiers for low-bandwidth measurements. An even fasterpeak-detection system is now being installed on one pickup, to allow for measurement over 128 consecutive turns,
to study transient behavior of the beam [6].

Development:

Some upgrades are being considered to improve performance and user interface. These developments are partsof today's control system at LEAR and would be logical
updates to the CRYRING system:• More computing power can be added by network linking to VAX computers at the institute.

A high resolution ( 300 nA) current transformer from Ber/goz, for measuring the absolute value of the current of theunbunehed beam, was installed. So far there has been
problems with the signal-to-noise ratio where the noise
has been observed to come mainly from the ring magnets. Work is going on to solve this problem. The electronics
of the Schottky detector is shown in fig. 5.

• Workstations and PCs are considered as complement
to the operators consoles. Operation with graphic
presentation, also from equipment rooms and experimental areas, is desired.

S04SRS03
Status Reports: Subsystems

169

169

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-S04SRS03

Fig 4 Pick-up detection system.

References

The input signals are amplified by high bandwidth (.0150 MHz) amplifiers and the difference and sum signals
are created in a passive circuit consisting of three power
splitters. Frequency analysis of these signals can yield theq-valueofbetatron oscillations and the momentum spreadof the beam, as indicated in the figure.

[l] C. J. Herrlander, K.-G. Rensfelt and J. Starker, "CRY_;·
RING-a heavy-ion synchrotron and storage ring,"
in EPAC 88 Rome, June 7-11, 1988, p. 350; K.G. Rensfelt, "Status of the CRYRING project," inEPAC 90 Nice, June 12-16, 1990, p. 623; C. J.
Herrlander, "CRYRING- a Low Energy Heavy lon
Facility", in Cooler Ringa and Their Applications,Tokyo, November 5-8 1990, to be published.

The same result, but much faster, can be obtained byprocessing the signals in a DSP consisting of a flash-ADC
and a FFT processor. It is considered to include this typeof module in the VME system. The VME computer isequipped with a GPIB controller which allows control andread-out of auxiliary instruments.

SChoHlty nol..

Wldt-bandO•tector

Alllpllflon[2} U. Tallgren et al., "The distributed computer control system for the CERN low energy antiproton ring
(LEAR)," CERN PS/85-27 (LI) 6.5.1985.
[3] P. Lienard, "The LEARGFD," CERN/PS (to be published).

•• 1)$al/Jv[4) J. Knott, "The LEAR control timing system," CERN
PS/LI/Note 83-12.

Spectrum
Analyur[5) S. Borsuk, K. Agehed, W. Klamra1 and Th. Lindblad,"A peak detecting pulse height ADC system for beamdiagnostic pick-up detectors in the CRYRING accelerator," Nucl. lnstrum. Methods, vol. A284, p. 430,
1989.
[6} S. Borsuk, "The fast digital peak detector for the
beam diagnostic system in the CRYRING accelerator," (to be published) .

VME..
Longitudinal

Schottky

Speetrum :.) °'pP

Transverot

Schottky d)q

Fig 5 Schottky detector.

S04SRS03
170

Status Reports: Subsystems
170

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-S04SRS04

PC's present the middle level of computers hierarchy. The of application programs is maintained by the system
upper level is fonned by two Host Computers of DEC - facilities.
The system software is all software that doesn't depend
f ami/y. All computers are connected with Ethemet.
The inteiface electronics is based on /HEP version of on the object of control and one that is common for various
CA.MAC. In cryogenics the groups of CAMAC crates subsystems. It maintains the operational environment forcommunicate with PC's through RS-232 lines, connected to application programs inteifacing with operator andequipment and includes the following components:
crate controllers. CAMAC crate houses:- intelligent crate control/er with 16 bit, LSI-11-compatible - operating systems of high- and middle-level computers
and their utilities;
processor;- systems of automation of programming;- convertors for Allen Bradley thennometers;- convertors for vacuummeters;- software for intercomputer communications (TCP/IP)
that includes the communication of high-level computers-12 bit ADC;
with the computers of /HEP central complex;- I/O - registers;- automation system data base and its utilities;- restart memory module after power failure/restore;• thyristor and relay drive amplifiers for Motors and valves; - the operational bank of superconducting magnets tests• intelligent (16 bit, LSI-11-compatible) module for 4 results;
control loops, aimed to provide reliability of the Control - packages of subroutines for organization of the operator
system itself as well as the cryo-complex.
dialog with computers, fonnat data conversion and data
Such a distributed processing means that all processors representation on the infonnation representation
provide local control algorithms, gather local data pool of equipment,'
all related equipement, transmitting infonnation to upper - multiprogram real-time monitor for low-level computers,·
level only on request.
- the tests for system equipment components.
Control of PS's is provided with 16 bit computer,
The features of problems solved by high-level
connected to CAMAC. Electrical/magnetic measurement computers permit us to use the VAX/VMS operating
station consists of 2 CAMAC crates, connected to PC, system that maintains a parallel execution of some tasks in
CA.MAC crates house:multiprogram and multiaccess modes. We want to use the• 18 and 16 bit ADC, 20 bit DAC, timers, function mode of the RSX-llM operating environment emulation
generators for PS's control,·especially in the system of automation of programming of• amplifiers, filters, comparators for quench detection;
tasks for /ow-level microcomputers.
• NMR - convertors, voltage/frequency convertors, step
We have selected C and FORTRAN as the
motor drivers and so on for magnetic measurements.
programming languages for high-level computers. The
features of the programming of /ow-level computers aredefined by two reasons: small amount of main storage (56Kb) and the short response time requirements especially
3. SOFTWARE
with respect to control programs. The first reason requires
elaborate and accurate programming. Second one requires
The purpose of software is to maintain functionality of
the use of specially developed monitors.
all subsystems connected with production, testing and filing
The middle-level computers may be used as the local
of magnets. In addition (independently of the serviced
consolefor subsystems that need a control.
subsystems) software must maintain:
automation of programming that includes the
progromming of low-level computers;
4. INTENTIONS- communication between all computers that includes
loading and start-up of programmes on low /eve~ data a) Analog electronics interlock is being constructed to
exchange, subsystems inteiface through a middle-level protect the most impoTtant cryogenic equipment in case ofcomputer;
Control system default.
- filing of the produced superconducting magnets and b) Cooling of CAMAC crates with help of vortical air
preparation of all necessary documentation about them;
refrigerator will be tested.
- support of the bank of programmes that maintainexecution of the system tasks.
5. ACKNOWLEADGEMENTS
All software may be devided into the system softwareand the application one.
The author list of this status paper contains only names
The application software comes main functional loadof group leaders. Much more people really take part in theand includes algorithms· of control, data acquisition,
designing of the Control system.
mathematical processing and representation of data thatare individual for each technological subsystem. The
software toolkit necessary for quick and qualitative writing

S04SRS04
172

Status Reports: Subsystems

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

ICALEPCS1991, Tsukuba, Japan

3,4

2

I \

o··o

I \
~o··o

I

5+.10

Host

11,12

13-15
: ......__......

\

PC:RS 232 to:20 mAD:converter
CAMAC

1r
~1r
v :v

1r
\/

1r 1r
v v

1r
1r
v v

.J,

1r
1r
1r
1r
v
v
v
v
PS
PS
PS

.J,

Compressors,
purification.J,

8 refrigerators
a cryobenches
vac. system

2 assemblies
for 2 Q-benches.J,

Purification,
rectifier.J,

4 assemblies
for a D-bencheswith 4 PS's
2 assemblies
for 2 reference
benches

173
Status Reports: Subsystems

Equipment

3 asssemblies
for "warm"
testing

S04SRS04
173

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

2

1

1

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS04

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the computing systems was cho~en (fig.ll.
synchrotron
control system,:;i--~~-ioth"!r

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS05

processing of •easurement results
at the normal system
operation;
information exchange
with
the
other
~tatistic

synchrotron control system.
For information exchange with

the

other

synchrotron control systems. 91>ecially withrf systems, electrOJ11agnet supply system andothers, the second serial port of IBM PC/AT
is used,
as
well
as
a
non-standard
communication unit <CU>.

Fig. 1A

setof

specialized

microprocessor

modules of KP5ROBH80 type, allowing to solvethP following tasks
wasdevelopedfor
operation at the low level;- continuous measuring, tolerance parameters
control and formationof the actions forcontrolling accelerator extraction devices;buffering,
preliminary
processing,information conversion and transmission to
the computer· of thP. higher levP.l;- synchronization of measurement and control
processes with thesynchrotron cycles.
The wish to minimize andgetlessexpensive apparatours from the one hand andto achieve the sufficient universality of its
functional possibilities from the otherwasthe main reason of the development of thesemodules and of not
using
the
nucleuselectronics apparatours.
The microcomputer RPT-80 <Hungary) usedon the middle level with the processor of
INTEL 8080
type
runs
systemterminalfunctions in the separate control subsystems
at its off line work and as a peripheral
processor at the controlling through thehigher level. In the first case it solves theuser tasks providing a standard interface toall the modules of the low levP.l and in thesecond one it solves the same problems aswell as the other ones but under the controlof the computer higher level.
At the higher level a personal computer
IBM PC/AT is used, the main functions ofwhich are the follDMing:
creation and maintenance of the parameterdata base of the main - operation modes ofthe beam extraction devices;
realization o the local control algorithm~
with the feedback;1.1. Timer Unit <TU>

The timer unit is developed on

the

base

of the microprocessors and is usedforsynchronization of all the extraction devices
and equipment of physics-experiinenters withthe synchrotron acceleration
cyclesandcarries out the folloNing functions:control of the synchronization main pulse
and its selection on thefalse signals
backgroundmeasurement
andtolerance
control offrequency; in case of mode
violation of the main pulse forming
timer
unit
automaticallyswitchesoffthecontrolling of the extracted beam channels
for elimination of the break-downs in thethyristor devices;
program distribution of the synchronization
main pulse in thedevicesofdifferent

extraction beam lines depending on theoperator given sequence;time pulse delay formation in the given
devices for running thephase control.

Main technical featurespulse distribution channels number - 8;
the range of the programmed pulse time
dP.lay is within o.s µs 32 µsJ
pulse distribution periodicity in the beamlines is arbitrary - up to 256 cycles.
1.2. Beam lines control units <BL.CU>
Eight units of the beam control lines are
based on the unified microprocessors forcontrol all the parameters of the magnet
extraction devices and have the following
functions:- measuring· with the help
ADC - the current control

of

the

different

pulse inmagnets and beam intensity signal from

the
the

S04SRS05
Status Reports: Subsystems

175

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
scintillator

pickupandtheir tolerance control

realization<thP. numbm-

the pointer to system area, which is given toofeach external devicP., are kept in the control;.;. µ"• measurement accuracy is 1~

digit">;
the phase control of the amplitude andshape of the control current in thP. magnP.ts
intervals

measuring andtolerance control of timesynchronizilltion and
intP.rvals betWP.en(Uppulsescontrolling

to

time

16

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS05

ofanalogsignals
at
pointsi<ampl ing
mP.a">UrP.mP.nts is up to ~~6, sampling stP.p isby means of the 6 control
time
for each forming current pulse;

ICALEPCS1991, Tsukuba, Japan

table. Command tab.le contain!lltheaddressesof the functional tasks.
The input-output dispatcher is creatPd
for a cOllllllcn access to differP.nt external
devices.
communication
co111111and input

ManagPr of asynchronouslines gives an alternatives;ourcewhich·

realizes

theinformationexchange between the cC111puters.
The describPd software is written in

theassP.mbly languagl!! ·in the r::P/l'I 00 environ111•mt

intervals);
information exchange with the higher

level

and occupies 2 kBof ROl'I.

CIJlllPUter •Conclusions
The created system realizes the following!.3.

Oiagnostica unit
signillls (J>U)

relay

the

of

possibilities:
continuaus

controlThis unit realizes registration, control,
diagnostics of the statP. signals of the

dP.Vice!'I state;"switch on -

of

the

measuring and display of the current values(numberofof all the ·-a!iured

channels -64, blDCk ti-. rP.">ponsP. tostate change - not more than 100 µs>.

the.

digital and graphic.al form;

1.4.

switchoff"

type~oftwarein

thP.

monitoring the .. extractian bP.am quality
fault diagnostics;

andmanualtheandparameters

autDllliZed

control

The lowlevel
microprocessor
units
software is based on the program-monitor,

extraction devices throughrealizing the main cycle of wiit opP.rationand organizing
communications
with
thP.

stabilization of

subprograms as well as

on

the

asynchronous

subroutines oflines, drivers including
the data exchange, control words receive
determining equipment
~ode

while

the

the

COQ!Puterand·extraction

111Ddestheir .parallll!'ters.··

More than one year operation of thesystem provad the reliability of its work andthe convenient maintenance.

transmission

programs

software

A.R.Toumanian,

1.

N.A.Z.apolski. Theof the corresponding unit.
RPT-AO consists oftuningOf

operationand status-words
Middle level

extraction[~J

commandrealizedmonitor,

Kh.A.f:i111onian,way

gettingsecondary beam in the high energy
acceler.ators. fin
Russian>.

inglobalofthecycliccontrol table 'and command table, input-oatput

2. A.G.Agababian, and othera. - The structure

dispatcher of thP. driver
external devices,manager of the asynchronous communication

and ar.ganizatian of.autD81ized control
sUbsystems by the beam: extracti·an. frDlll thelines and the interrupt handlers.
Command monitor realizes
thefaat cycling aynchrotron. Proc. of the II
Sov.Union conf. an charged
particles.accel • V•.l ,.p~·.1 ?.5, .'Dubna, 1989. (in Russi an> •interaction with the operator

throughdirectmenu,

which gives the list of allavailable

taskA

and the ways o'f access to them. Mani tor

al so

subsyst- .control

supports the global

theYerevancontrol• c:o111111and table.
The information of

table

and

~.

A.S.Agababian

andothers.
organizationsynchrotron.

Preprint

SoftNareof

the

YerPhy12R4fROl-90, Yarevan 90. (in Ru!Ssian).
theexternal

operation mode, the interrupt bytes anddevicealso

S04SRS05
176

Status Reports: Subsystems

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-S04SRS06

It consists of a profile monitor, a video signal synchrowill be discussed as example. Intel 310 (CPU 286, HD
40M) can be used for task management, data sort, data nizer, a. high speed A/D converter with 15 MHz inserted
processing and BITBUS communication control. Two sets into the Intel's MULTIBUS. The video signal of beam spotof industrial level console computer (CPU 286, HD 40M, · from the camera was transmitted to the TV monitor of
RAM 2M) which can be used for humanmachine interac- control room. It is easy to correct the target haircrossing
line using the movable data window by the computer contion.
trol. The 4000 points signal could be collected in less than
4ms. After data processing, a beam profile distributed picture and three dimensional distribution will be shown tooperator immediately.
BITBUS
The major function is follows:
SBC88/40* Measuring resolution bett.er than 0.2mm
TV MONITOR* Data window Size: 50x80(256x25) would be possible)* Sample rate: Max. 15MHz* Multipurpose: profile, energy spread, emittance measurement.
* High anti-interference:
When the beam intensity is so weak that the beam proBea
file can not be observed on TV monitor, therefore it may
Triggerbe clearly seen on the graphic display after eliminating
Gun
Ace I
Acc2
1
background noise from the image data taken repeatedly.
8-f-----=J-+-----~-P~In order to record the 2us beam intensity data which isimportant data for accelerator operator ,high speed sample
Flg.2 Beam Siaiion Schema11c
hold circuits are being developed and we intend to use it
instead of 7104 oscilloscope.

[mJ

B. Timing system

III. HARDWARE SYSTEM
A.Local station

Each local station has own iSBC 88/40 microprocessor andvarious 1/0 interface boards which are linked together on
the Intel's MULTIBUS.
I.Modulator and Klystron Support Unit (MKSU) [2] isa powerful interface between MK station and Klystron &Modulator. It was developed by SLAC in 1985. and contains various interface circuit linked with intelligent PIOPCAMAC module. In order to keep this powerful functionin our system, a dedicated bus adapted from MULTIBUS
to MKSU bus have been developed successfully.
2. MG station
The PLS 60 MeV has 29 sets of power supplies to bemonitored and controlled for serving the solenoid coil,steering coil, analyzing magnet and quadruple magnet. A
digital remote control model using data modulator anddemodulator with Manchester code has been adopted. By·the way, a remote D/A controller could be mounted at themagnet power supply as close as possible.
3.BM station is designed for measuring various beamcharacteristics such as beam profile, beam energy spreadand beam emittance. This is a multifunction image processing system, illustrated in Fig.2.[3]

PLS 60MeV LINAC timing system is a small system withthree triggers to electron gun, travel wave tube, and modulator. In general, we refer to the LINAC timing system of
KEK because the same kind system had been running for
5 years in the Beijing Election Positron Collider(BEPC)
without trouble.
·

C.Beam monitors
According the physical requirements and our running experience in the BEPC, three categories of monitor are
adopted.
The short pulse current monitor consists of a ceramic~olid resistor in the shape of a disk, magnese-zinc ferrite
aluminum case with BNC connector. Its features are:* Measuring min. limit: 0.2 ma without amplifier*monitor sensitive: 3mv/ma*Frequency response: >1.5 GHz
The fluorescent target typed AF955 has been mounted
in the profile monitor and can be movable by console computer. The beam loss monitor is not necessary for the shortdistance of 60 Me V LIN AC, but it could be a prototype as
reference for 2 GeV LlNAC beam loss system.

S04SRS06
178

Status Reports: Subsystems

178

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

IV. SOFTWARE SYSTEM

We should appreciate to Prof.
K. Na.ka.ha.ra., I.Abe,
A.Enomoto, T.Ura.110 a.ud Prof. Y. Kimura. of KEK for theirva.lua.ble experience a.nd sincere assistance during the system
configuration. Also we thank ma.ny friends a.t SLAC for theirsuccessful experience a.bout Klystron control.

A.Sy3tem 3oftware
The main control software on the Intel's 310 is the real time
multitasking control software which is based on the BITBUS network. According to the LINAC physical requirements, it can carry out the control to each local station. and make data processing. It owns its multitask scheduler. When the scheduler receives the command from theconsole, the related application tasks will be activated at
any time. The control system uses fully operating functions, and the tasks will be put into operation in order of
their priority level. The real-time data base is built in;it always holds refreshed data (over 300 signals) of wholecontrol system~ The data adjustment and command sending task is running forever after the control software is
set up. It acquires the datum from each local station via
BITBUS and updates the DB continuously in rate of 2-3
times/second.
0VII. REFERENCES[l] K.Na.ka.ha.ra, I.Abe, R.P.Bissonnette, A.Enomoto, Y. Otake,T.Urano a.nd J.Tana.ka., "Control System for the Photo Factory
2.5GeV Electron LINAC", Nucl. Instr. a.nd Meth. A251 (1986)
327.
[2] R.K.Jobe, M.J.Browne a.nd K.P.Sla.ttery, "Hardware Upgrade for Klystrons in the SLC" 1 SLAC-PUB-3666 poster pa.per
presented at the 1985 Particle Accelerator Conference[3] D.K.Liu, K.Naka.hara., I.Abe, T.Urano, A.Enomoto and
J.Ta.naka.. "Image Processing System for Electron LINAC
Bea.m Diagnosis", Contributed to the 1986 Linear Accelerator
Conference, 2-6 June 1986, SLAC, U.S.A.
[4] R.K.Jobe, K.Thompson, and N.Phinney, "Klystron control software in the SLC", SLAC-PUB-3667

B.A.pplication 3oftware
In normal times, the control software in the local station iscontinuously acquiring the datum and monitoring from/tothe accelerator's equipments. The major application software include as follows:* Modulator/Klystron package (4) such as control andmonitoring to modulator, drive power control, waveform
digitalized control* Magnet power control and monitoring* Beam FWHM calculation and emittance processingetc.
The Human-Machine interactive software have been designed for those physicist and specialist who are not familiar with system software. It easy to operate and configure
various control system. Please refer to "Human-Machineinterface software Package" in this conference proceeding.

V. CONCLUSION
During the configuration of I&C system of 60 Me V LIN AC,
some technology, experiments and equipments such as
beam monitors, MKSU, and timing are transmitted from
KEK and SLAC. We believe that international collaboration has speeded up the progress of PLS 60 MeV LIN AC.
Instrumentation and control system of PLS 60 MeV isdesigned for PLS's preinjector. So far, its commissioning
with the whole machine will be in November, 1991.
It is a compact and complete control system for PLS
60MeV LINAC.

VI. ACKNOWLEDGMENT
We should sincerely a.pprecia.te Prof. W .N a.mkung, Prof.
LS.Ko, Dr M.H.Cho a.nd I&C group of PLS for their direct
support a.nd friendly collaboration. .
·S04SRS06
Status Reports: Subsystems

179
179

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-S04SRS06

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

The desired magnet
excitation currents are obtained bycontrolling the output voltage ofthe thyristor power converters
through the SCR gate firing pulse.
The rectifier voltage reference
pauerns are implemented by thecommon action of two negative
feedback loops, i.e. a low-gain
automatic voltage regulator (AVR)
and a high gain automatic current
regulator (ACR). These patterns areelaborated by the control computerand fed to the regulation through a
DAC, synchronized at 600 Hz on
the zero crossing of the two 3phase ac line systems. While
providing the voltage reference
patterns the computer implements
a repetitive control algorithm on
the base of measured deviations of
the magnet current from reference .
The digital system is in charge ofthe fast feedforward pattern control
and of the repetitive control via
the ACR.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS07...-----! LP~ 1U..

ANALOG CONTROL SYSTEM"'Tfr

CLK. GEN.
!600 Hz)1······+·············'SYNCHR.

__._..;.;;..;;,.;.....;;::..:......J.-•• ...1..-• • -•• - - - - - - - - -DIGITAL CONTROL SYSTEM

2. MULTI-MICROPROCESSOR CONTROL

2.1 GeMral LayoUJ
The multi-microprocessor control system has been
introduced in 1985 [4]. Initially the main CPU was a V90/5(8MHz without cash-memory); this was then upgraded to a
V90/25 (16MHz with cash-memory) in order to improve thespeed of the main system and of the communication loop.
The main parts of the digital system are based on a 16-bitmicroprocessor and on LSI components, connected to anindustrial standard bus and to standard peripherals, supported byr----------.. --------r----------------·-!
an universal operating system. Consequently a high level'
language and powerful utilities facilitate development and
'
'I'I
'
'
I
maintenance of flexible software for the pattern control
'II
!
HISEC
I
system which consists of the main CPU HIDIC-V90/25 andI'I
04Mof the input and output controllers lllSEC-04M. The three''\..---distributed systems have no hierarchical software but are rather
independent even at assembler level because of the difference
between the CPU families and in particular of different
addressing for memory access. The main components are LSIof the MC-68020 CPU family. The direct digital control
system, as main part of the controller, consists of I-8086 and exclusively devoted to input or output network
home-made LSI modules. Fig.3 shows a layout of the multi communication, transfers patterns or logged data between themain and the input or output controllers. The fact that thiscomputer system.
communication is rather slow, due to time sharing operation
2.2 H/DIC-V90125 systemon the same system bus, limits the speed of response for fineadjustments.
The system, equipped with memory management unit
The locat terminal is supported by a serial 1/0 fulland 16MB DRAM on the internal bus, has a floating duplex link. The remote terminal, located in the Center
processor. Two local area network (LAN 1 and 2) loops Control Room (CCR) of the 12 GeV PS, is linked by anprovide the interconnection between main system and standard optical cable to cope with the 350 m distance between CCR
peripherals, i.e. 5-inch 80 MB hard disc and 8-inch 1 MB and power station, where the main system is installed.
floppy disc drive, two CRT terminal stations , a typewriter
The application programs are written in the system
and a printer. These resources are supervised by the UNIXcompatible main OS.
One of the network-loops, LAN 1, language C and FORTRAN 77 [5]. The parameter files of
1

S04SRS07
Status Reports: Subsystems

181

181

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, Japanthe programs displayed on a CRT terminal can becommunicated to the central control system. Powerful UNIXutilities are used not only for program development but also
for maintenance of the application programs. controlling andmonitoring the whole system by file management, screen
ediior and shell command.
Pattern generation can be done while the power
supply is running by using the main CPU and storing thenew pattern in its memory. Therefore the operating pattern
can be changed without interrupting power supply operation.
Fine adjustment of the injection current and of the tracking
ratio between bending magnet and quadrupole current is done
from either terminal in the CCR or the local power supply
control room. The main tasks are control operation. e.g.
start-stop and status monitoring. calculating the correction
patterns of the repetitive control and fme adjustment of patterndata. As far as additional supporting tasks concerns, thesystem works on pattern generation, processing of pattern andoperational data, control program development and back.groundprocessing.
The main operator commands are shown in
Table 1.

corrections. Concerning the B2 and B3 rectifiers. the reference
voltage pattern is subdivided and distributed to each of the 12
pulse thyristor converter groups in order to obtain the desiredmagnet voltage with minimum reactive power generation[6]. In both fine adjustment cases a step variation is smoothed
out by applying optimum polynomials in a fixed interval.
The main and the controller systems are linked in a LAN with
an effective transfer rate of 20 kB/s. Typical response time,
on fine adjustment of tracking or of injection current for
beam tuning, was 20 to 50 s for the V90/5, even after thecontrol programs have been optimized by fixed point
calculation, but becomes less than 10 s in case of theV90f).5. Table 2 shows as an example display of injection
current adjustment by function fS (see Table 1).
Table2.
tH# MR-PS injection tuning ( on line ) tH#

page • 1/1••••MR-PS OPERATOR COMMANDS••••UPPER LIMIT> INITIAL> LOWER LIMIT
Injection [GJ
1598.9 > 1449.0 > 1285.5: stopf3 pattern No.
f4

Footnote: [ default pattern number ] can be neglected

Generated pattern files are used for fine adjustment of
injection level of the bending magnet current (without tune
shift ) by additional smoothing corrections calculated in thesame pattern generation algorithm. Tracking offset
calculations are done similarly to iniection current.------t Ki 1 - - - - - - , ACR !ANALOG!

: 198.88: 116.73: 116.29

Binj. [G] 1450.0:nm: pattern exchange (wilh repetitive control): IQ tracking adjustfS: B inj. adjustn: pattern generation
f8: PS status display: pattern No. display
f9
flO [pattern No.] : pattern savefl 1 pattern No. : pattern remove
03 pattern No. : pattern exchange (without repetitive control): command menu display
menu
menu2
: command menu next page display
pc20: repetitive control start
cpcstop: periodic control stop

proton/q05066
injection
injection
injection

Table 1.

fl [pattern No.)
fl

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS07

Repetitive magnet current control has been performed
to suppress the deviations from a given current reference
pattern and repetitive voltage control has been used to reduce
the parasitic voltage ripple [7]. The principle is based on thecontrol method applied to a repetitive reference input (8]. The
excitation current in the respective magnets is to be controlledaccording to periodical patterns. The frequency response of thecorrecting transfer function has been confined in a lower
frequency region, about 15 Hz or less, to track a periodic input
and assure the stability of the power system. Fig. 4 shows analgorithm of the repetitive control of current and voltage. In
Fig. S the convergence of the repetitive control, from theinitial pattern to the corrected one, for an ACR deviation of
the bending magnet current pattern is shown over eightcorrection cycles. (Timing pulses, Pl,P2,P3 and P4 areinjection start, acceleration start, flat top start and flat top end,
respectively.)

E DIB

30t

~.
10~

..:!..

. !.
;.

....
--------···''

GX(n) : Transfer function for compensation.
F(s) : Transversal fm.ite impulse response of low pass filter.
L=mT: Dead time ofm times period T, m: integer.

Fig.4 Block Diagram of the Repetitive Control.

S04SRS07
182

Status Reports: Subsystems

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS07. fine adjustment of the injection current and of the tracking
ratio between bending and quadrupole magnet currents. It is
The HISEC-04MJD and G controllers, belonging to easy to change the operating patterns without stopping thedifferent families i-8086 and HD-68000, are subdivided into power supply. During the extension of the flat top duration
two sub-system working on the same system-bus. The first [9], memory and hard disc capacity has been increased and
one works as direct digital control and feeds operational the application software modified. When operation ispatterns through 16-bit DAC's at 600 Hz clock. The other perfonned with a long magnet current flat top, the control
one acts as a data processing system and a support to the clock is synchronized at 300Hz to save memory space. At
direct digital control; it logs the magnet current from the present the multi-microcomputer control system allows to
DCCT and the group voltage through a sets of 16-bit ADC's perfonn stable operation of the PS and to achieve effective
working at the same clock. It communicates through LAN 1 utilization of the slow extracted beam spillwith the V90/25 and re3ds or writes data or messages on thememory of the HISEC-04M/D.
Acknowledgements
The output controller. supervised by the processmonitoring system, executes application programs such as
The authors would like to thank Prof. Michio
start-stop as well as process timing and sampling Nakano (Tokyo Institute of Technology) for the many
synchronb:ation. The routine output processing function technical discussions concerning the control system design .
distributes 15 data patterns in memory through parralell 1/0 They are indebted to Prof. M. Kihara for his advice andto the 16-bit DAC's.
encouragement during this work. They also thank many
Eleven sets of DAC's serve the bending magnet colleagues of PS group for their effective cooperation.
power supply: eight of them give the voltage reference
patterns to the thyristor converter groups, two are for the References:
ripple detectors of the dynamic filters and one gives the current
reference for the analog ACR. Each focusing and defocusing [1] S.Matsumoto, ff.Baba. ff.Sato, T.Sueno and K.Mikawa.
"Improved Control System of the Thyristor Flicker Suppressor
magnet power supply has three sets of DAC's. Two serve as
for the KEK 12GeV PS," IEEE Transactions on Nuclear Science,voltage and current reference to the analog loops and one isNS30(1983)2932
used for the dynamic filter. The system ouputs the pattern data [2] T .Shintomi. M.Masuda and S.Matsumoto,"ffannonic Current
to the seventeen sets of DAC at every 1.67 ms clock period
AC Filters at a Large Accelerator," Particle Acc. 8(1978)87
and the data conversion is synchronized to the zero-crossing of [3] S.Matsumoto, T.Sueno, K.Mikawa and N.Kumagai. "Control
the six phase ac power line. Control signals of by-passof the Ma.in Ring Magnet Power Supply for the 12 GeV PS,"
Proceedings of the 6th Symp. on Acc. and Tech., 1987, Tokyo,
thyristors and gate pulse suppress signals are distributed by
Japan. pp.158.
lhe system.
The input controller is dual with respect to the [4] S.Matsumoto, T.Sueno, K.Mlkawa, M.Toda and ff.Baba. "NewMulti-Microprocessor Control System of the Ma.in Ring
output controller as far as hardware and system software
Magnet Power Supply for rhe KEK 12 GoV PS," Proceedings ofconcern, except the digital input and output. Its main task is
the 1987 IEEE Parti.cle Accelerator Conference, 1987,
to collect the data from the ADC's through paralell 1/0 andWashington D.C., pp.689.
to accwnulate and save lhem at every control clock.
[5] T.Sueno, M.Toda, S.Matsumoto and K.Mikawa. "Software
Simultaneously the system reads data from six sets
Systems of the Main Ring Magnet Power Supply for the 12of 16-bit-ADC's through a Sample/Hold amplifier at the same
GeV PS," Proceedings of the 6th Symp. on Al;,c. ind Tech.,clock as the DAC system. Three sets serve for the DCCT
1987, Tokyo, Japan. pp.155.
current signals and the others for the de voltages applied to the [6] ff.Sato, T.Sueno, T.Toyama. M.Mikawa. T.Toda,
S.Matswnoto and M.Nakano, "Performance of the Main Ring
B, Qf and Qd magnets. The clock is sychronized on ac
Magnet Power Supply of the KEK 12 GoV Proton
voltage zero-cross pulses but has a constant delay of 100
Synchrotron", Proc.of the 1991 IEEE Nuclear Science
microsec corresponding to about twice the conversion time.
Symposiwn. 1991, Santa Fe, to be published.
The DCCT current data serve in the repetitive control loop
[7] T.Sueno, S.Matsumoto, K.Mikawa. M.Toda, ff.Sato,for calculation of corrections to the voltage references.
N.Kumagai and ff.Baba.,"Repetitive Voltage Control of the
2.3 Controller System

3. CONCLUSION
The hybrid control scheme of an analog and a digitalsystem and the multi-microcomputer control system HIDICV90/25 and twin HISEC-04M have been implemented in themain ring magnet power supply of the 12 GeV PS. The
HIDIC-V90/25 and HISEC-04M system perform fast
feedforward pattern control at 600 Hz clock and slow buthigh gain feedback control of current pattern for steadydeviations according to the repetitive control method. The
analog system works as real time feedback control loop of thevoltage and current reference pattern fed by the digital system.
The repetitive current control is not yet usedroutinely, despite its effectiveness, due to the cwnulative
effect of small errors produced by the intrinsic ripple of thepresent DCCT. It is used for initial pattern correction and

Main Ring Magnet Power Supply for the KEK 12 GeV PS,"
Proceedings of the 14th Int. Conf. on High Energy
Accelerators, 1989, Tsukuba. Japan. Particle Accelerator.
29(1990)133.
[8] T.Inoue, M. Nakano, T.Kubo, S.Matsumoto and ff.Baba. "High
Accuracy Control of a Proton Synchrotron Magnet Power
Supply," Contl.Sci. & Tech. for Prog. of Soc. (IFAC 82)
Vol.6, 3137, Pergamon Press(l982)[9] ff.Sato, T.Sueno, T.Toyama. M.Mikawa. T.Toda and
S.Matswnoto, "Upgrade of the Main Ring Magnet Power
Supply for the KEK 12 GoV Proton Synchrotron", Proc.of the1991 IEEE Particle Accelerator Conference, 1991, San
Francisco, to be published.

S04SRS07
Status Reports: Subsystems

183

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-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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Thu Nov 07 B9:0EHOO l.SS'l.

• For Booster extraction:

TC'i!UJ•" •t
J,lKl- a mountain view of currents of four kicker magnets and a pulsed beam measured by a wall
current monitor (see Fig.I)

100 · · · ·• • • • · • · • •• · · · · • • • · · · • • • • · • · • •• • · • •· •• • · ·· · • • • · · · · · • • • • · · • • ;,.

cir B~PZ

1
S R ~ B~Pl

• For Main injection:a mountain view of currents of five kicker magnets and a pulsed beam measured by a wall
current monitor• For all pulse magnet fire timing:

10"/..· ""....:.'.'... •••• •••• •••• •••• ~..:_... •·•• •••· ···: ·••· •·•• •••• ···• •·•• KR INJ' SCPTll'11

r--..:.._

Tku Nov 0? 09:06:48 1991
CH1 lV/diY 2us/di"'- a mountain view of currents of sept urns, bumps
and a kicker (see Fig.2)

8R £:)(T 'sep~

CH2 lV/div '50011s/divd1v

BR £:)(T SEPT!.t1J.

Tr.itsu· at
BKl

100 ........ •••• ................ •·•• ....................

~

t· .................... ..
l'1R KIOCCR ll

I'1111: t<IO<CR 1

Thu Nov 07 08:56:40 1991
CH1 5001T#J/d iv 60ns/d iv

Figure 2. A mountain view of all kinds of pulsed
magnets in PS-BT (from top figure to bottom)
Booster Extraction Bump (#2, #1)
Ma.in ring Injection Septum (#2, #1)
Booster Extraction Septum (#2, #1)
Ma.in ring Injection Kicker ( # 1)
Booster Extraction Kicker (#1)
Booster Extraction Bump (#2, #1)

C. Tuning machine

CH2 500mV/d iv 50ns/div

Figure 1. {from top figure to bottom)
A mountain view of currents of a pulsed beam measured by a wall current monitor, currents of four kicker
magnet and averaged those four kicker currents

After tuning positions a.nd emittance figures of a beamat the transport line, final tuning should be carried byobserving the injection efficiency of the Booster and theMain. By dividing the Booster circulating beam particle number at injection by the Linac beam particle number, which is calculated by integrating the Linac beam
current with time duration, the injection efficiency of
the Booster is obtained. And by dividing the circulating particle number at the Main injection by that at
Booster extraction, the injection efficiency of the Main
is obtained. The fire timing of the kicker magnet should
also be adjusted by observing the height of the Booster

S04SRS08
Status Reports: Subsystems

185

185

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-S04SRS08

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 Publishingbunched beam at extraction and of the Ma.in at injection. The trigger used to observe these monitors canbe selected among nine successive Booster extraction
beams which inject to the Ma.in ring in the Main injection porch:

D. Searching for trouble points of the bump and kicker
systems

doi:10.18429/JACoW-ICALEPCS1991-S04SRS08• For Booster injection efficiency:- Linac beam intensity and Booster particle number measured by a slow intensity monitor (seeFig.3)• For Ma.in injection efficiency:- Booster particle number measured by a slow
intensity monitor and the Ma.in particle number

The thyratron used in a bump and kicker power supply has a lifetime when the turn-on timing becomes delayed. When one of the two Booster extraction bumpmagnets happens to show such a deterioration, the betatron amplitude arising from the bump firing increases.
Ther~fore, two bump currents and LlR monitor signal
in the Booster a.re needed to check the problem.
Every kicker has a separate delayed trigger circuit,which has low reliability, and sometimes becomes outof order. When one of the kicker currents begins to
be delayed, we can distinguish which causes the trouble(thyratron or delayed module) by changing the following
trigger:• For Booster kicker firing timing:• For Booster extraction bump trouble (signal):- fast intensity monitor at Booster extraction- Booster extraction bump currents and ~R monitor signal• For Ma.in kicker firing timing:• For kicker trouble {trigger):- fast intensity monitor at Ma.in injection- origin of the trigger to fire all kickers* for Booster extraction kicker* for Main injection kicker
Thu Nov 07 10:37:09 1991

- output of delayed trigger module after branching from the origin trigger

CHl l00ITTJ/d iv 10us/div

lOl!I·

. ...

-

('

... . ..

... .

)

,_
W.· •

Booc·hr BU.• <BSI')

ll

,...

. ...

v

/ ··\ ... . ....

* Booster kicker( #1 "' #4)* Main kicker(#l,..., #5).. .. .... . .

....

!~

-

·-·

. ..

I

I

I

I

3. BLOCK DIAGRAM OF THIS SYSTEM

8.98e+l lppp
BOOSTER 8.56e+1 lppp
Tnjection
I INAC

8 5%

E:fficienc~

I

Ii., I"I

l'Y·r .. ,..

l..i,..._e B•an (Cll) <BSF")

I

I

1

CHZ 100ITTJ/div 10us/div

Figure 3. Linac beam intensity,' Booster particle number
at injection and Injection efficiency

In order to obtain the injection efficiency precisely,
the Linac and Booster intensity, or the Booster andMain intensity, should be evaluated a.t the same time.
Therefore, the Linac and Main intensity are connected
to different inputs of an oscilloscope from that of the
Booster intensity. The figures changing rapidly as a
kicker current are connected to the input via the "equalizer" mentioned in the footnote. All of these input figures are. displayed by using a proper trigger, as shownin Fig.4.

S04SRS08
186

Status Reports: Subsystems

186

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

4.FUTUREIMPROVEMENT
We are using an oscilloscope with a sampling rateof 250MS/sec; the memory number is IK words. This
number is too small to display the synchrotron oscillartion by talcing the envelope of the height of the bunchedbeam train (because of "areasing" of digital oscilloscope).

We will purchase an oscilloscope with greater memory, so that we can display not only the synchrotron
oscillation, but also a. "mountain view" of a bunchedbeam train at the Main ring injection with an intervalof a quarter of the synchrotron period.

(Fast Pulse}I''
BR EXT KICKER 15
MR l~J KICKER 11''

MR INJ KICKER 15
LINAC FAST IM
MR SLOW IM
MRWCM
BR DRM
MR FAST IM

TOUCH PANEL

VME

BR EXT KICKER #1-

ATTEN·UATOR

BUFFERAMP& DISPLAY-MPXDDIGITALoscchl( Slow Pulse }9•

BR lNJ BUMPBR EXT SEPTUM #l
BR EXT SEPTUM #2
BR EXT BUMP#l
BR EXT BUMP 12
MR INJ SEPTUM U
BR SLOW IM
BR WCM
BR FAST IM
MR INJ SEPTUM 12

ATTEN·UATOR
BUFFER
AMP

-

ch2

n

trig

0

I

MPX

:3"'

E5
~
( Trigger Puloe )I

I

BR KICKERl''

MR KICKER9
BR KICKER#l'I
BR KICKER14
MR KICKER#!

-

MPX

-

I

'

DELAY

-

MR KICKER15

MPX
BR INJ BUMPBR EXT BUMP
BSF(ARC}
MR (ARC)
MRWCM
SEPTUM
KICKER ( BSF)

Figure 4. Block diagram for observing system of pulse currents(BR:booster ring, MR:ma.in ring, IM:intensity monitor, WCM:wall current monitor,
DRM:delta R monitor, BSF:booster facilities, MPX:multiplexer)

S04SRS08
Status Reports: Subsystems

187

187

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-S04SRS08

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

requests to send wave fonn data of MPS's output voltage; 255
words binary data with EOl, its sampling period is about 25
millisecond. Figure I shows an example of the wave form.

5, Magnet #1 Ready/ Trouble.
6, Magnet #2 Ready/ Trouble.
7, Fault; DC over current.

8, Fault; DC current leak,
9, Fault; MPS over heat #1.
10, Faull; MPS over heat #2.
11, Fault; cooling fan
12, Fault; MPS's door open.
13, Fault; magnet #1; over temperature.
14, Fault; magnet #1; cooling water flow trouble.

Software
All the PSC's soft programs are written in assembler
language. They mainly consist of :(1), GPIB communication program.
(2), MPS operation program.
(3), Watching program.
(4), Fault or error message list for diagnosis of
MPS.

Messages [I] BLC--> PSC
The messages sent to PSC in MPS from BCL are thefollowings:
I),
"ST$"
requests PSC to send status message of MPS. This message
includes the following:
ON/OFF,
REMOTE/ LOCAL,READYI NOT READY,+/ • •: polarity
CC/ CV,: regulation mode
Reference value,
DAC value,
DCCI' value,
Voltage value,
AC input current value.
2),"ST1$" , or "ST3$".
These messages request PSC to send MPS's status as follows;
DCCT value, or absolute output current [A].
Voltage value, or absolute output voltage [V].
+/ •polarity
CC/ CV,: regulation mode
Ac input current value [A].
I

Figure 1: Wave fonn of MPS's output voltage
7),"ID"
requests to send MPS's identifying message;
It includes MPS's rating, factory name fabricated the
MPS, etc.
8),

"YO"

requests to send DCCI' output voltage for monitoring.
9),"XO","Xl","X2",

I

I

"XIS"

request to send the value of ADC(with 16 channel multiplexer)
for monitoring.
10),"A xxx.xx"

requests MPS to set output current xxx.xx [A] smoothly.

:

11),

"V xxx.xx"

requests MPS to set output voltage xxx.xx [V] smoothly.
12),"D x" : ( -l()()()(k= x <= +10000)
requests PSC to set xxxx data to DAC smoothly.

3),"ST2$"
requests to send
Absolute output current [A],Absolute output voltage [V].

requests to send fault messages to help diagnosis of the MPS.
Its message is text-fonnat message.

13),"Tl", "12", "T3"
are setting speeds of output cUJTent or voltage.
TI: fast
T2: middle.
T3: slow.

"AC"
requests to send AC power source input current [A].

14),
"L x"
sets the limit value of output current for watching.

4)

"FL"

5),
6),

"OW"

15),
"CC"
sets MPSs to constant current regulation mode.

S04SRS09
Status Reports: Subsystems

189

189

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-S04SRS09

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

Step 13,
Current setting starts to 0 [A].
Step 14,Main power switch OFF.
Step 15,
Jump to the above step 2.
Final state is negative(-) xxx.xx [A}.

16),
"CV"
sets MPS to constant voltage regulation mode.
17),
"CK".
·
.
It invokes check program to check MPS. When MPS is OFF
state, the check program checks Interlock's fault sign~. low
voltage power supplies, DAC output voltage, and fWJCUon of
main switch and polarity switch. When MPS is running, it
initializes check list and fault flag, then check program starts.

On the step 15, when MPS receives "V+ xx.x"
message, the following steps are done.
Step 16,
Current setting starts -xxx.xx[A] to 0 [A}.
Step 17,Main power switch OFF.
Step 18,
Jump to above step 2.
Final state is positive(+) xx.x [V] on voltage

DC, SOC: GPIB command.
18),
initialize PSC and MPS. Main SW is off, and all data is clear.

On the OFF state, when MPS receives "CK"
message, the following steps are done.
Step 19,
Reset interlocks, check fault signal.
Step 20,
Check output voltages of low-voltage power
supplies, DAC, and DCCT(output current).
Step 21,
Tum polarity switch, check its status.
Step 22,Tum main switch ON, check its status.
Step 23
Check output voltages of low-voltage power
supplies, DAC, and DCCT.
Step 24,Tum main switch OFF, check its status.
Step 25,
Send SPQ, bit 7 added in order to indicate
check-end.

Message [2] PSC--> BLC
The messages sent to BLC form PSC have describedalready in the above section without SRQ.
The SRQ is a signal of PSC to request BLC. One status byte
is sent to BLC.
The bit assignment is listed below.
MPS is OFF state.
MPS is ON.
Bit 1,
Local conbOl mode.
Bit 2, I:
Fault on interlock.
Bit 3, I:
Fault on ON, OFF, polarity SW procedure.
Bit 4, 1:
Fault on Values; output current, lowvoltages, or DAC: reference voltage.
Message error.
Bit 5, I:
Bit 6, 1:
SRQ
Bit 7, I:
This bit is set after the check program runs,
and indicates that the fault-list is available for read-oul
Bit 0,

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS09

0:
I:
1:

MPS operation
All the operation of MPS is done by PSC in MPS.
When current setting message is received, the MPS's operation
is as follows.
Step I,
Step 2,
Step 3,
Step4,
Step 5,

Receive "A xxx.xx".
Invoked MPS operation program.
Reset MPS interlocks.
Check Interlocks fault signal.
Check MPS's low voltage power supplies,
MPS output current, and DAC output
voltage for reference.
Step 6,
Set MPS to current or voltage regulation
mode.
Check polarity, and tum polarity switch.
Step 7,Main power switch ON, and check.
Step 8,
Step 9,Current setting and check trouble loop.
Current setting end, and SRQ.
Step 10,
Step 11,
Set limit values for watching program.
Step 12,Watching: check status (ON/OFF, interlock
signal, remote or local), output current, reference DAC, andlow voltage power supplies.

On this state, when MPS receives "A-xxx.xx"
message, the following steps are done.

BEAM LINE CON1ROL

MPSs and control system/or K6
The control system for K6 using new MPSs isshown in figure 2. All the MPSs are connected through GPIB
highway to the BLC by a coaxial cable. A terminal display
connected to the BLC is offered to a user group to operate thebeam line. The BLC computer is dedicated for the beam line
conttol and the MPS's maintenance work.
On construction stage of the beam line, this new
MPS's function is effective for checking MPSs. All thefunction of MPS is performed through the microprocessor
embedded in the MPS. Then commands or messages to the
MPS is simple, those MPSs can be operated easily by directcommand of personal computer with interpretive language(BASIC) too. The diagnostic information of the lvlPSs areable to get without checking program on the BLC, for its
checking or test program is stored in each of lvlPSs.
On this configuration BLC programing becomes
simple, and no checking program is running constantly on
BLC. As the result, the GPIB communication line between
MPSs and BLC becomes quiet, there is no problem with~
The equipments for K6 beam line control system are:
BLC: Personal computer with BASIC language HP-300
TRM: Terminal for user of K6 beam line.
EX:
GPIB bus extender for long distance up to 1250m,
60k bytes/s. HP 37204A
MPSs: listed bellow.
Name

Addres.s KW
I
260
65

Q2

2
3

A
2000
1300

105

1600

Q3

4

200

2000

DI
QI

v
65
100

130

50

S04SRS09
190

Status Reports: Subsystems

190

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

5

CMl
CM2
Sext
Q5

6
7
8
9
10

Q6
Q7
Q8
02
(1J
QlO

11

12
13
14
15

160
85
85

2000
1300
1300
1000
1300
1300
1600
2000
2500
2000
2000

50
65
85
105
120
500
120
160

80
65
65

ACKNOWLEDGEMENTS

50
50

We would like to thank professors K.Nakai,
S. Kurokawa for encouragement and special aid.

65
65
60
200
60
80

REFERENCES[1]
K.H. Tanaka, etc all, The Beam-Handling Magnet
System of the KEK-PS New Experimental Hall: MT-12, June
23-28, 1991, Leningrad, U.S.S.R.
[2]
Y. Suzuki, M. Takasaki, Development of a
Computer-controlled Magnet Power Supply for KEK PS
Beam Lines: NIM, A293, pp. 253-257, 1990.
[3]
M. Crowley-Milling, Control Problems in Very
Large Accelerators: IEEE NS-32, No. 5, pp. 1874-1876, Oct
1985.
[4]
J. H. Humphrey, The Isabelle Control System-design
Concepts: Distributed Computer control systems, Proceedingsof the IFCA Workshop, Oct 1979.
[5]
Y.Suzuki, M. Takasaki, PSC hardware and softprogram, KEK internal paper.

to another network

Beam line controller

BLC

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S04SRS09.___ _.::to user terminal

S-232cGPIB bus
coaxial cable & bus extender
up to 30 MPSs
MPS (magnet power supply) for beam line
Figure 2. Configuration of K6 beam line control
The soft program for K6 beam line is written byBASIC language, which does not include the operation
procedures or the fault messages of MPSs, therefore it
becomes simple.
The operation procedure or the specifications or thefault messages of MPS are MPS's own. It is better that they
are not separated from MPS's body, because they form MPS's
character. If they were separated, in case of worst case of MPS
exchanging, it needs more work, e.g. exchanging of procedure
program and fault messages for individual MPS in BLC.
CONCLUSION
We have developed new MPSs, and introduced the
MPSs in K6 beam line. Both the specifications and the source
program of the PSC were offered at free to factory or
workshop for MPS fabrication. By using this type of MPS,
we rationalized the work on control wiring, check andmaintenance work of MPS s, and BLC programing.
No longer on BLC programing the programer need tobe concerned with the specifications or the fault messages orcodes of MPSs.

S04SRS09
Status Reports: Subsystems

191

191

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

Q4

ICALEPCS1991, Tsukuba, Japan

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

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

ICALEPCS1991, Tsukuba, Japan

3) HI MAC is expected hopefully to be utilized for morethan fifty patients everyday for clinical treatments. In orderto realize this, the treatment schedule and the flow ofpatients must be managed to run smoothly.

B. Patient Positioning system

JACoW Publishing4) All systems in HIMAC are designed under theconsideration of primary importance for keeping safety ofpatients and collaborating staffs. Especially, interlock
system associated with the beam must be carefully
designed from the view point of reliability.

III. TREATMENT SYSTEM
A schematic view oftbe treatment control network that
we designed is shown in Fig. 2. The treatment system of
JllMAC consists of the following components.

For patient positioning, we usually use the laser
pointe'rs, light localizer and digital Xray TVs that areincorporated in the beam port. The three dimensional
coordinates of the target are estimated by coordinates ofanatomical landmarks in the process of reconstruction by
two projected Xray images perpendicular to each otber[3].
Referencing the digitally reconstructed radiographs that are
generated at the planning, the transfer of treatment couchis detennined. The couch is to be operated by the treatment
control computer(HP9000/380) Ii nk e d to t be patient
positioning computer(HP9000/730) with image devices.
Further, CT scanner can be used for the check of patientverification.

C. Irradiation system

I r r a d i at i o n m an a g i n g computer(HP9000/380)
communicates with HIMAC central supervisor computer. It
In order to make the best use of heavy ion beam's gives a requirement of the beam course, beam energy andcharacteristics, we are developing a three dimensional ion species to HEBT controller via supervisor along thetreatment planning system using a super graphics schedule. Concerning the responsibility of beam irradiation,
workstation (flTAN750) [2~ This planning system consists we use the name "RIGHT" which means the initiative of
opening the neutron shutter and the FCN(one of theof:1) defining target volume and critical organs by interactive Faraday cup monitors) shutter. The irradiation , that is thecontouring on Xray-CT, MRI and PET images,
on/off of the beam, should be under the control of treatment
side. Usually, irradiating at the treatment room starts after2) detennination of directions and shapes of irradiation
RIGHT is transfered to the treatment control.
fields using beam's eye view graphics,
Devices of irradiation beam port (Fig. 3) comprise a3) calculation and display of three dimensional dose
distributions,pair of wobbler magnets, a beam scatterer, a range shifter,a ridge filter, a multileaf collimator and monitors. They are4) designing collimators and compensators,5) generating digitally reconstructed radiographs which are controlled by the treatment control computer via interface
wiit.
used for patient positioning.
In addition, the treatment supporting computer converts
To protect from accidental irradiation to patients andthe planning data to the treatment control data, which collaborating medical staffs, interlock systems are
consist of beam parameters, port data and treatment couch carefully built against such occasions as probable
overdose, various kinds of troubles in each instrument,
parameters.
change of beam intensity and change of patient's condition
including bis unexpected movement. Further, quick stopand restart of irradiation are required repeatedly for
B?F
medical use. In consideration of these
HI MAC IF
ill< E
Hoofhf li'j"Ethings, operation of opening and closing
HlnAC SuPervher epu
LAN
the neutron shutter and the FCN shutter
I nJeclor CPU
are handled either automatically or
Svnchrolron cpu
manually. They are synthesized in theVob!>l•r acoet
Tred11enl
Controller
form of global interlock system which is
Supporlln1
HE8T epu
Co•pulerdriven with threefold safety throughTreal•enl
hardware and software.
Control

A. Treatment Planning System

IC lltdllne
Coatroller

ComPuler

3
Treatment
Plannins
Co•Puler

"
.2

;:

.

~

Sob •onltor....x

Pal lent
Po1llionln1
ComputerFig. 2 JllMAC treatment computer network

IV. OPERATION OF
IRRADIATION
A layout of treatment room floor isshown in Fig. 4. Chief radiation therapy
tecbnologist(RTT)sitting by theirradiation managing computer canalways look over the treatment hall andwatch the ITVs coming from treatment
rooms. In addition, the status of patientsand beam lines are displayed on bis
console. So be manages the schedule ofirradiations for smooth running.

S04SRS10
Status Reports: Subsystems

193

193

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-S04SRS10

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

Fig. 3 A layout of beam port in the horizontal line
In ordinary clinical use, every morning, at first, RTI shutter. It takes about ten seconds to open. Then RTI opens
calibrates monitors in the same conditions of various the FCN shutter which takes less than one second, and thedevices just as the irradiation for each patient. Each irradiation star.ts. Besides global interlock system,
parameter file which contains beam course, beam energy, whenever RTI wants to suspend irradiation depending on
ion species, setting parameters of magnets and so on is the patient's condition, he can shut the beam and restart
saved in the treatment control computer. This file name is quickly afterward. Once the dose counting of main-monitor
checked before corresponding patient's irradiation, and the reaches preset counts, kicker magnet kicks off the beam,irradiation starts in the same condition at the time of and then FCN and neutron shutter are closed through theinterlock system. Amain-monitor system is always backed
calibration. The patient's irradiation starts after these.
Following the check of patient's ID-card, devices of by sub-monitor system. Then RIGHT returns to HEBT withbeam port are automatically set on the starting status. the data of request to next beam course. The data of
While the RTT is setting the patient on the treatment irradiation records such as final counts of monitors, times
couch, operators of HEBT adjust the beam up to the of suspension, positioning images and status of port devices
position before the neutron shutter, and keep waiting as the are preserved for each patient.
beam is stopped by FCN shutter. After the patient's setting,Now, we are designing and developing the software
the RTI goes out from the treatment room and closes theshield door. The status of shield door is connected to global and hardware to control the beam for radiation therapy ininterlock system. And next, the RTI requests the RIGHT to HIMAC. The clinical trial will start In 1994.
HEBT. After the RIGHT is transferred to the treatment
control, he opens the neutron
References
1) K.Kawachi et al., Proc.
2nd Int. Sympo.

Advanced Nuclear
Energy Research,
p.362 (1990)
2) M.Endo et al., Proc. of
hit. Conf. on MBE,
vol.29, p.317 (1991)
3) S.Minohara et al.,Proc. of Int. Conf. on
MBE, vol.29, p.859(1991)

Fig. 4 A schematic view of treatment floor (HIMAC B2F)

S04SRS10
194

Status Reports: Subsystems

194

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- ELFA would experience during its lifetime a lot of developments and theoverall sttucture would follow this evolution. This statements outlines oneof the most stringent requirements on every accelerator and experimental
physics control system. Unlike the other basic subsystems of the machine,which will experience a limited amount of developments, the control
syslem is required to be flexible and to satisfy a lot of requirements, thatduring lhe design phase have never been examined or discussed. Thisimplies that a system that just meets today needs will not be able to work
tomorrow. A lot of auractive self-contained systems are today available on
the market, usually based on Persona! Computers. These systems have an
exciting first look but the experience gained working with them teaches
that there is a not negligible risk to be tied from their internal slrllcture.
·ELFA requires some general tools which will help to manage the wholeproject. Since the different subsystems would start !heir design and testing
phase in a parallel fashion, it is very hard 10 take into account all lhe news
coming from the different teams and to coordinate all the jobs. The contr0l
system in an experiment of this son would be a valuable help in theanalysis phase. Models definitions and simulation of the different views of
the experiment would be possible using automatic tools. General rules andspecific requirements would be cross referenced, pointing out
inconsistencies or helping in optimizing perfOITOances.
Keeping into account all tlle points above discussed a conceptual
design of the control and data acquisition systems has been made. The
most relevant characteristics may be so summarized :• the systems will be based on a fully distributed environment. Distributed
systems represent an ideal answer to demands about flexibility andmodularity and may be easily implemented using commerciaJ standard
products. The availability of components which follow international or
DE-facto standards represents a great improvement in the way to think acontrol system. The auention may be moved from the home madedevelopment of basic components, which is a really expensive and time
consuming activity, to the definition of general rules for the integration ofcommercial products in a multivendor. suitable environment.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN01

The systems must follow general rules both for hardware and software
components. An extensive analysis of the general requirements comingfrom the different subsystems must be carried out in order to define thesmallest number of different boards and software modules to deal with.
This task is particularly difficult in small projects where there are a lot of
single components.
• The user of the systems must be unaware of the details of them. The dutyof the control group is to provide an high level environment for the
programmer, being a physicist or a member of the tedmicaJ staff, to let
him to develop application programs, which require bis scientific ortechnical skill, without have to deal with device or control architecture
characteristics. All the operations on the equipments or on theexperimental areas should be carried out using logical names related to thespecific functions. No matter if they are on different control subsystems, or
if !hey are moved from a controller to another one during systemmodifications. All the data must be available to the physicists when tlleyneed them in a simple and standard way.
• The development of the control system should be based on an extensive
use of automatic tools. This would start in the design phase, with a special
emphasis on software, and continue up to the installation tests. A lot of
informations must be recorded and analyzed during the project evolution
to guarantee an homogeneous environmenL This will enforce the use ofadvanced programming techniques giving the possibility to the user to takefull advantage of such an approach.
Ill. CONTROL SYSTEM ARCHITECTURE
Regardless of the real complexity of the experiment, modem
distributed control architectures develops on three levels: the plantlevel,wbere we have the single equipment control; the process level, whichis responsible for the operation of a set of functional related devices; thesupervisor level with the operator interface. This general scheme has been
adopted also for the general layout of the ELFA control and dataacquisition systems (fig. 2). The main difference between the two systems
is the absence of the plant level for lhe data acquisition system .

CONSOi.£

G41tWAYINJECTORACCELERATOR

E/£C"TRONOIAGNOsnc

RAIJIA110N
DIAGNOsnc

Fig. 2 • The hardware architecture of the control system

S05SRN01
196

Status Reports: Non-Accelerators

The process level has been designed as a set of Process Units (PU)connected on the main Ethernet network of the control and dataacquisition systems. The PU are based on the VMEbus and the Motorola
680x0 microprocessor family. At this level Lhe main tasks are to acquireand process data from Lhe plant level, for the control system, or fromdetectors, for the data acquisition system and to process Lhem according tooperator commands or control codes specific of the particular PU.
According to Lhe specific tasks which should be performed a PU may
follow a single processor or a multiprocessor scheme. The choice of
VME as the internal bus for process level stations, among other buses
similar from the technical point of view, bas been due to the world-wide
diffusion of this bus, specially in the research environment, which gives
the possibility to work with a lot of boards and drivers already developed.
A special consideration would be dedicated to the control of alarms
conditions arising from equipmentS which will compromise their safety.
To handle these situations we bave planned to use industrial PLC
connected to the main network by means of a gateway.
The plant level bas been designed as a set of microcontroller based
boards. Each bOard is housed in the equipment to which is devoted giving
an enormous flexibility to the whole structure and providing a firstprocessing of field data close as much as possible to the field itself. Boards
related to the same functional part of the machine will be connected bymeans of a bus. implemented using an HDLC based protocol (Bitbus), tothe related PU. This scheme reduces in a valuable way the pick up of noisein signal transport and helps in device biding.
The operator level will be implemented using dedicated workstations.
This choice is quite a standard one nowadays and the experience gainedusing these machines is really satisfactory [2].
IV. SOFTWARE CHARACTERISTICS
The overall structure of the control and data acquisition systems bas
been carefully analyzed from the point of view of software requirements.
Two items seems to be the most important :- the capability to configure in every moment of the experiment the wholesoftware structure in order to reflect modifications in the hardware or in
the requirements from the experiment• the possibility to develop programs without having to deal with the
distributed nature of the control architecture.
Control programs and data acquisition tasks (which are stored in a
dedicated computer) will be configured to reference to logical names andtables which every CPU will load at the bootstrap or following a specified
command. This structure allows an enormous flexibility during operationof the machine. Tables will be extracted from a central database which
stores all the informations related to the project. The choice to have a
database where the whole data of the machine are stored plays a central
role in the design of the whole machine. We are dealing with a tool basedon a CAD program which directly interface to the database : designing a

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN01

piece of equipment each relevant information may be directly stored or
retrieved for cross reference checks. A particular situation is that one when
the software itself in under development : we may analyze it using SA-SD
models and store the structure and objects we require for those particulartasks in the database. At the end of a module one may start programs
which try to find semantic or conceptual errors. Moreover it is possible toextract a detailed and complete set of informations which. constitute thespecs for writing the software. In this way we have both a graphical lookat the structure of the code and a documented version of the code itself.
To handle data and commands exchange on the network it bas been
decided to use as much as possible the RPC protocol as developed for the
LEP contrOI system. This choice let us to meet immediately the goal tobide the network structure to the user and to obtain a reliable task to task
communication in such a way that a program running on a PU may call aprocedure to be executed by another PU. RPC protocol provides thepossibility to communicate between PU and the operator worksiies. It is
not possible, as by now, to access directly an IJO point at the plant level
using our scheme. This would be possible writing special drivers on thePU where the microcontroller boards are connected.
The operating system we have chosen for the process level is OS-9,
while at the plant level an Intel kernel, iRMX 51, provides support both formultitasking operations and for message exchanges.
The operator workstations will use a Motif interface and will run a
dedicated program where the operator will be able to build its own
interface or use a predefined view of subsections of the experiment. The
choice to use workstations as operator access point to the control systemtakes into account performance and budget considerations. The only
possible alternative to the use of a workstation would be to use Personal
Computers for low level jobs and maintenance purposes. As by now, wehave experienced that a PC would use the facilities of the RPC protocol if
it uses Xenix as the operating system. As a tool during equipment design
and rest. PCs would be used in a stand alone fashion with DOS as
operating system. National Instruments boards and LabWindow software
will be the products of choice for these purposes.

Acknowledgements
I wish to thank the whole control group of ELETI'RA-Trieste for a lot ofinteresting discussions on trends in control architectures and for their help
during the first tests of the devices described in this paper.

REFERENC~[I] R. Bonifacio et Al. ''The EL.FA Project" in EPAC Proceedings, Nice,
France, June 1990, p. 340[21 D. Giove et Al. "The Operator View of the Superconducting Cyclotron
at LNS Catania" paper at this Conference

S05SRN01
Status Reports: Non-Accelerators

197

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN02

for accessing the common 300 MB hard drive the workstations.
To resolve the overload
and 600 MB magneto-optical drive. As the problem, the tasks to control devices directly
pointing devices, mice and a touch panel are are distributed over the network nodes (local
units) and the console works only for
used.
Fig. 2 shows the hardware configuration organizing the messages among them.
of the control system for the JAERI FEL
The main console unit has an associatedcomputer to display the auxiliary panels forfacility schematically.
supporting the control.
It computes theInterlockbeam characteristics using simulation codes, if
required, and helps the operator to manage
Main Console Unit
Radiation
the knowledgebase on the machine operation.
MonitorThis causes to integrate the device control
and simulation calculation in the FEL
oscillation experiments.
The response speed is also a criticalissue when the beam quality is fluctuated ina short time span. In the first phase of the
project, the accelerator is operated in pulsed
Ethernetmode with 1 ms macro pulse width and 10
Hz
repetition, so it is preferable to remedy
Local Units
the malfunctions found at the prior macro
pulse in the 0.1 s pause. Basically, the feedback loops are inside of the device controllers,and it is designed that the CAMAC/GPIB
data acquisition speed and the network speed
are not critical.
ill. SOFTWJ.B.E A.B.CKITECTUB.E'-'--'-==="" ""'==="-'~'""" <~~!i.#~.I~~!~:
Figure 2. Schematic diagram of the hardware•,

configuration.
The reliability of the hardware isimportant to maintain the laser oscillation,
which is very sensitive to the electron beam
quality. As the hardware considerations, weemploy the modular approach in each layer:(a) the device driver level, which uses thestandard interfaces, such as CAMAC andGPIB, and can be backup by other modules,(b) local unit computer level, which consistsof the same units and it can be configured toshare the task in the multiple computers, and(c) network level - if it is necessary, thenetwork can be also doubled using an opticallink of GPIB or serial communication· at theexpense of the data transfer speed.
The user interface is a severe problem
when we employ the personal computer as aconsole and use graphics extensively, because
display has lower resolution and the cpu
abilityissmallercomparedwith

The system software consists of amultitask real-time kernel, drivers for the
network, CAMAC and GPIB interfaces, and agraphical user interface.
It has two modesof operations: simulation and on-line modes.
In the development stage, the former mode isused to abstract the details and evaluate theIn the actual
system performance.
operation, it is turned to the latter mode.
The flexibility and the reliability areenhanced by employing the object-oriented
approach for software development.
The
software for FEL system control is configured
in a hierarchy of three levels: {1) processlevel, (2) hardware system level, and {3)hardware device level, as shown in fig. 3.
As an instance, it is assumed that thetask of process level control to transport in a
portion of beam line is issued by an operator
and it is requested to stabilize the conditionof the electron beam (e.g. the position andthe size). The process class has a sub classof hardware system level, one of whose
instances is a double bend achromat in thecurrent beam line.
The hardware system

S05SRN02
Status Reports: Non-Accelerators

199

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

comprises of the several sub classes of the
hardware devices and one of the instances isa specific dipole magnet.

by using 11 assert 11 or "retract" predicates.
The integrity of the control and thesimulation codes[4] can be attained by"beamtrace" or "matching" predicates, which
produces an estimated beam condition or the
optimized parameters during the control.
These functions are combined to "stabilize"
some characteristics.
And "status" and"history" are reported as the resultants.

[

FEL system control

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN02

1

Elec1ron Beamcondition

class inheritanceprocau:s,(be$10_&ansport)

super classes

Frame Representation
beam line element(bending magnet)

STATIC/OYHAMICh_system(double_bend_achromaf)

O jmenJ

coH current
magnetic field (central)lrioge fieldh_<tevico(dipole magnel)transfer matrixalignment effOf
beamempse

Figure 3. Software hierarchy of FEL system
control.

central traje~ory thiftcooling watertemperature

To satisfy the request, the database of
the magnet is searched and the corresponding
control variable is found, then it is adjusted
according to the rules sensitive to theobjectives (beam position and size).
There
are many variables related to the hardware
they synchronize andsystem so that
communicate to each other. The final results
are reported to the console as the status.
And if required, the precise information about
the history of the processing is recorded andreported the reasoning.
In the system database, or knowledge
base after learning the rational rules of theoperations, the classesof objects are
represented by frames.
Figure 4 shows an
It isexample of such a representation.
described by the Prolog style.
The "is_a"predicate represents an inheritance between
classes, and "create 11 /"destruct 11 makes/deletes
As the option, the multiple
an instance.
inheritance is attractive for categorizing thecontrol items with the different aspects, suchas the control method, speed, quality andquantity. The independent database is used
when the informations are known to beorthogonal and · the speed of the search isimportant.
As an example, the frame for bending
magnet in a beam line is shown in figure 4.
There are static and dynamic slots. And the
dynamic slots are either the measured values
or the derived values.
The derived values
can be controlled by a specified rule or
formula. The slot can be created or deletedo {nltuJ

radialion level' - - - - - ! aeQ:..lmU!aied dose rate

D (flleulo {ukjsub classes

IWS!•MMptl)lWllt@li@Wj

Figure 4. Representation of
database in FEL system control.

thesystemThe user interface for operator console isdesigned based on the graphics representation.
Figure 5 shows an example of the panel for
It contains all parameters of thecontrol.
electron gun, two buttons, three slide bars
The parameters can be
and four meters.
controlled by usin~ a mouse.

Figure 5. An example of the control panel.

S05SRN02200

Status Reports: Non-Accelerators

200.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN02

IV. CONCLUSION

The most important feature of the
JAERI FEL control system is flexibility forevolving in the future. So the hardware isselected in the frame of the standard
interfaces, CAMAC, GPIB and Ethernet, andthe software is organized using the objectoriented approach.
The control process is
combined with the simulation code to support
the operator to know the theoreticalbackground of the current status and acquire
the experiences on the operation procedure.
The construction is not yet completed, but
the control system may be used by hiding theunimplemented hardware with the simulated(virtual) devices.
REF EB.ENC ES

[1]
[2]
[3]

[4]

Y. Kawarasaki et al., 11 Linac for a Free
Electron Laser Oscillator", Nucl. Inst.
and Methods, A285, pp.338-342, 1989.
M. Ohkubo et al., "Status of the JAERIFEL System 11 , Nucl. Instr. and Methods,
A296, pp.270-272, 1990.
M. Sawamura et al., Proc. of 13th Free
Electron Laser Conf. Santa Fe, Aug.
25-30, 1991 (to be published in Nucl.
Instr. and Methods).
M. Sugimoto and M. Takao, 11 BeamTransport Program for FEL Project 11 ,ibid.

S05SRN02
Status Reports: Non-Accelerators

201

201

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-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

ICALEPCS1991, Tsukuba, Japan- Combined coherent configuration
This is the configuration used for the VLT Interferometer (VLTI).
It requires the use of at least two of the four
VLT telescopes and of one or more of the auxiliary telescopes. Important aspects are the precise control of the position of the moveable auxiliary telescopes and of their associated delay lines.

• active optics
This is a. system of 150 supports for the ma.in mirror, which allow it to change its shape. It is meant
to compensate for deformations due to manufacturing
errors, gravitational and thermal effects and also low
frequency wind load effects on the main mirror.
The image quality is analysed via a wavefront analyser, and a microprocessor provides the values to the
support system.

• Multi-instrument context
Normally up to three instruments will be mounted
all the time on the main telescopes and additionally
one has to consider the combined instrument and the
VLT interferometer instrumentation. Therefore the
VLT is characterized all the time as having a multiinstrument context.
Parallel access to all the mounted instruments will be
provided, though only one instrument per main telescope has access to the telescope beam (active instrument).

The active optics principle has been tested on the New
Technology Telescope (3.5 meter diameter) now in regular operation at the ESO La Silla Observatory inChile. It is thanks to this principle that not only excellent optical quality can be achieved, but also that
substantial savings on the weight of the mirrors andon the size and costs of the whole telescope can bemade [2].
• adaptive optics
This system is introduced to compensate for the effects of atmospheric turbulence on the quality of images.

• Multi-user context
Independently of the location of users (in the control
room or at a remote location), they will be able toaccess any part of the whole set-up with a simple logon and configuration operation. In other words, thewhole VLT system will be accessible and controllable
from any single user station.
A monitoring mode might also be important when aproblem occurs, for which expert advice is needed andthis can only be obtained from colleagues situated remotely (either in S!!-ntiago or in Garching). Monitoring will allow them to follow the results of tests
performed and investigate how the system is working.

It consists in applying to a deformable mirror a num-

ber of piezo-electric actuators, which compensate inreal-time in a control loop for the optical degradationof images.
This principle has been tested at the ESO 3.6m telescope, but not yet used on a regular basis as part ofany instrument.
The associated multichannel feedback loops require
fast and powerful computation. It is acticipated that,for the VLT, human interaction can be eliminated,and procedures can be defined to allow routine use ofthis system [3].

C Operational context
The VLT operation has to cope with a complex environment produced by a multi-telescope, multi-instrument andmulti-user context.
• Multi-telescope context
The VLT software will support the following telescope
configurations:- Stand-alone configuration
Each telescope is used alone, allowing individual
observing with an 8 m unit telescope.
- Combined incoherent configuration
This configuration includes the use of two, threeor four main telescopes working either simultaneously on the same object with identical instruments, or via a combined instrument at the Combined Coude focus.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

D

Operational requirements

The VLT shall be operated at different levels: observing,
maintenance and test level. This basically corresponds
to the needs of the different users, namely observing astronomers, operations staff and software development staff.
Observing astronomers differ very much in experienceand many of them are very occasional users of the system.
A system of privileges and protections shall allow operation of the different parts of the VLT at the required level,
without interfering with other users.
A capacity of twenty active users at the same time isforeseen, with six additional users who can monitor thework of others.
• Service observing
Observing, as such, is the purpose of the VLT system, but classical (interactive) observing is the least
efficient way to achieve this.
Service observing, on the other hand, means that theobserving programme can be performed by someone
other than the proposing astronomer.

S05SRN03
Status Reports: Non-Accelerators

203

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• Flexible scheduling
Flexible scheduling means the possibility of reacting
quickly to changes in weather and other conditions
by allocating the optimal observing program for thoseconditions.
It requires the use of service observing, as users may
not be able to wait for special conditions.
• Automatic observing
To achieve efficient service observing and flexible
scheduling, it will be possible to carry out observations automatically, in accordance with pre-defined sequences of exposures, as is commonly done in spaceobservatories.
At the same time, one does not want to lose the advantages and the extra flexibility of ground-based astronomy. So whichever scheme is adopted to perform
automatic sequences, interaction will be allowed at thedesired level (for example, only on error conditions)and at any time the user shall be allowed to break asequence.

II. VLT CONTROL SOFTWAREThe VLT control software includes the control of the main
and auxiliary telescopes, the interferometer and the instruments of the VLT (18 are foreseen at the moment).
All this will be based on a distributed environmentof workstations and microprocessors, as described below.
The total number of microprocessors for which specific
VLT software will have to be written is estimated to bein the order of 150, of about 40 different types.
The total amount of software 'to be produced, excluding the instruments developed by Astronomical Institutes
linked to ESO is estimated to be in the order of 90-100
man-years.
A Data specifications
The final purpose of the VLT software is the acquisition ofastronomical data in digital form in the most efficient way.
To achieve this, many other data concerning the telescopes and instruments and control commands will have to
be exchanged between different processing units in order to
set-up and control telescopes and instruments. Additionally, video and voice data are also necessary (for example,
field monitors).
Control information must be transferred, typically in theform of commands and replies from users, to telescopes
and instruments. Replies might contain status information and, in general, data concerning instruments and telescopes, to be stored together with the astronomical data.
B

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

Control system distribution

The VLT system is intrinsically distributed and needs user
access at any telescope and instrument. This leads naturally to a distributed structure. The implementation plan,with different telescopes going into operation at different
times, demands a stepwise implementation of the control
system.
When one takes into account the control needs of thevarious elements, every telescope is itself a distributed system where control functionality and computing power has
to be provided.
All the above considerations lead to a control systemdesign, distributed both at the telescope level and again
at a higher level, to cope with the distributed architectureof telescopes and instruments.
A distributed system improves the hardware reliabilityof the whole set-up, as the number of cables is minimized.
This has been tested on the NTT.
C

Control system layout

Figure 2 gives a schematic view of the VLT control system,
which ESO has in mind.
The four main telescopes, subsystems and instruments
are shown in the top part at the left. The central partshows the computer and communications equipment located in the VLT control room. The bottom part shows ina schematic form the remote access facility in Garching.
The part on the right at the top shows the Coude combined focus facility, while the Astronomical site monitor isshown on the right hand side at the bottom.
Additionally there will be a separate control room forinterferometry;D

Control system architecture

Referring again to Figure 2, one finds at the bottom (nearthe control electronics interfacing with telescopes and instruments) the Local Control Units (LCUs) and then a
network of coordinating processors (telescope and instrument processors and workstations) and central and remote
workstations.
In this respect the hardware layout has a two-layer structure, but the various telescope segments are separated via
bridges and gateways from the network backbone.
Functionally, a hierarchical structure with three layers
can be implemented in the software, separating the local
branches of the local area network from the central backbone, so that the central computers can be seen as the
top layer. This offers advantages in modularity and security in the case of operations at the observing level (e.g.
a command from a central workstation might go to thecoordinating processor of telescope 1 and from there, bererouted to the appropriate LCU).
At the same time at the test level the normal operational
hierarchy can be by-passed and any local controller can beaddressed and tested directly from a central workstation(two-layer hierarchy).
The system described:• supports access from any workstation to all or partsof the VLT,S05SRN03
204

Status Reports: Non-Accelerators

204

(fl)

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

(1'4)

I
I
I
I
I
I
I

Astronomieal
Sile

MonitorToVLTt

I

II~.+

I
I
I
I
I
I
I

BridgeVLTOBSERVATORY

L-----------------------------------SITE

GARCHING
Q..,hing Bo:tbono LAN (P...ibly FDDI)

Figure 2: VLT control system• can be implemented in steps, allowing independent
development of the various instruments, and• implements distributed real-time control at the telescope level, via the LCUs.
Different LANs have been introduced with the purposeof coping with the different requirements represented bysynchronisation needs, control data, astronomical data andremote access.

E Functional Software Structure
The VLT software can be divided into five major functional
blocks:F

Development model

The VLT software will be developed according to a precisely prescribed development plan and to methodologies
supported by the use of CASE tools.
The purpose of this is to:- make the development process visible- provide maintainable software
cope with the need for expansion of the VLT software.

GStandards

Standards have been selected for the computers and thesystem software to cope with the development phase andto allow a smooth transition to the commissioning phasewhen the target computers will have been chosen.
The following criteria have been applied:- Emphasis on development and productivity requirements, including cross-support tools.
- Portability of software (target hardware independence)- Hardware and vendor independence- Use of industrial and de-facto standards
For the operating systems Unix System V (with Posix
interfaces) has been chosen for the workstations. This iscomplemented by the XU window system and OSF /Motifin the area of user interfacing. Communications portability shall be achieved by using TCP /IP and ARPA services. Command handling will be based on RPC. Commercial products are used in the area of the off-line database(Sybase) and as a CASE tool (RTEE). VxWorks is the operating system which has been chosen for the VME-based

S05SRN03
Status Reports: Non-Accelerators

205

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

microprocessors (local control units). This product is particularly suitable for a distributed environment and is wellintegrated with Unix, having the necessary real-time characteristics. The software development language has been
defined as being ANSI-C, with a number of restrictions applied to it. This has resulted from a comparison with ADA
and C++. There are thoughts that this last could be usedin some selected areas.
Communications hardware is IEEE 802.3 for the control
LAN and might become FDDI for the data LAN. FDDI
will also be used for the workstations backbone.

database and interfaces to the external software, user interface tools are part of this.
The system software will contain the following modules:

Functional Software Structure

H

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

The VLT software can be subdivided into two categories :system software (or data acquisition and control software)and specific applications software (in this case Telescopeand Instrumentation control).
Figure 3 shows the structure of the VLT software.
The system software will be described in more detail in
the next sections.

1. User Interface common tools

The VLT will accomodate many user stations, locallyand remotely (both in Chile and in several sites in
Europe). All of these stations, no matter for which
instrument or telescope they are used, will have acommon "look and feel". This will be achieved by
implementing a portable user interface toolkit, basedon OSF /Motif, which will be used for the implementation of any particular user interface.
The user interface will be completely decoupled fromcontrol programs, in that the values being displayedor cyclically monitored will come from an on-line
database rather than being requested directly fromthe control programs.
This will detach user interface issues from program
development, and will allow rearrangements in thisarea easily.
In this way the variable number of users and monitoring stations will not affect system performances.
2. On-line database

The control parameters and any other information
relating to the telescope, instruments and detectors
must be accessible at any operation level and shall becontained in a control on-line database.
This has to be a real-time database, with the accesscritical data based in memory. Access to information in the database must be logical (for example, byname).
The database must include mechanisms to allow thecollection of data from a number of LAN nodes andtheir use by others. So it must have mechanisms toallow either remote access or it must support data
distribution (or both}.
The database must have an interface to generaldata.base management systems (DBMS) and conversion tools from/to it via standard interfaces must exist.
Table-driven applications can thus be easily implemented in a clear and maintainable way all over thesystem.

Figure 3: VLT Software StructureI

A real-time distributed database with a hierarchicalstructure has been implemented by ESO for the NTT
project [4] and has been ported now to Unix for the
remote control of the NTT from Munich (see later
remote observing).

System Software StructureThis contains all the common services, which allow an open
and expandable system such as the VLT to look like one
homogeneous entity to the users.
In particular common (non-application-specific) software, including protocols, libraries, utilities, tools, on-line

3. Communications software
A generalized protocol will be used across all softv.tare packages for command passing at the programto-program communication level. Commands should

S05SRN03
206

Status Reports: Non-Accelerators

206

have a logical nature and shall not refer to any specificphysical address.
Cascade routing of messages will be supported to allow remote access.
4. Common LCU softwareThis includes all the common microprocessor software,contained in the LCUs, but not yet application specific.
Command passing, downloading of initialisation files,
common rules to access and exchange information,synchronization methods, lists of common genericcommands and boot procedures have to be incorporated in this software.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN03

Some relevant areas for possible collaboration include:- UIF portable toolkits (although specific applications
will be different)- Command handling in distributed environments (application level protocols and internal syntaxes).
- Use of on-line distributed databases in control systems, in combination with commercial database management systems. Computer and software vendors arealso starting to enter this area.
These are some of the areas in which collaboration andexchange of information can play an important role (seealso [6]).

III. VLT REMOTE OBSERVING

V.REFERENCES

Remote observing means that users shall be able to observefrom a remote site, Santiago, Garching or even home Institutes in Europe. This is explained in detail in [5], as ESO
has already been running a rather unique regular remoteobservation service from Munich with the Observatory inChile, for about 4 years.
The extent to which realistic observing conditions canbe reproduced depends, of course, largely on the link
bandwidth available. Experience with previous telescopes
shows, however, that, even with very limited bandwidths,
remote observing can be implemented, provided the software is suitable for this.
Remote observing, using the VLT will be indirect. Users
will have an interaction possibility, but normally via operators at the VLT or in Garching, or via the scheduler
program and shall not control any part of the VLT directly.
Remote monitoring is the simplest level of remote observing. It is sometimes called 'eavesdropping'. It is arequirement for the VLT operation and will complement
service observing, making it friendlier for users.
The remote observing facility in Munich will be linked,
according to the current plans, with the site at Paranalwith a dedicated leased satellite link at 1-2 Mbit/sec using
ESO-owned antennas.

[1] D.Enard, "The European Southern Observatory Very
Large Telescope", J .Optics,vol.22,n.2,pp.33-50, 1991.
[2] L.Noethe et al., "Latest developments of active opticsof the ESO NTT and the implications for the ESO
VLT'', in Proceedings of SPIE, vol.1542, 1991.
[3] F .Merkle et al., "Adaptive optics for the European
Very Large Telescope", in Proceedings of SPIE,
vol.1542,1991.
[4] G.Raffi et al., "NTT control/acquisition system asa prototype for the VLT", in Proceedings of SPIE,
vol.1235, Tucson, USA, February 1990, pp.428--435.
[5] G.Raffi, "Remote Observing", in Proceedings of ESO
Conference on Very Large Telescopes, Munich, Germany, March 1988, pp.1061-1072.
[6] A.Daneels, "Controls in Experimental Physics", Europhysics News, vol.22, pp.23-25, February 1991.

IV. CONCLUSIONSThe VLT system software is now in the analysis phase.
Reuse of some components is planned, while for new software ESO is planning to take advantage of collaborations
with Astronomical Institutes and industry.
There are a lot of areas in the VLT control software,
which are common to other control applications in physics.
The common denominator for high energy physics, fusion
research and astronomy being the production offairly highamounts of scientific data, for later analysis and also withon-line processing requirements.

S05SRN03
Status Reports: Non-Accelerators

207

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-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

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

ICALEPCS1991, Tsukuba, Japan

allow user definition of specific lines to suit individual
system requirements, trigger implementation, clock
facilities. and if higher speed data reoo-out is needed in
the future, a 32 bit local bus is available.

participating in a multi-parameter event and fonns a data
block for transmission via its output port which is a 32
bit ECL bus (DT32) capable of rates up to 4 Mbytes/sec.
The DT32 bus is chained to all ROCOs in the system
and read-out is performed sequentially from each VXI
crate. A Master Trigger unit is required for the dataacquisition system and this is also designed in VXI
format and housed in one of the front-end crates. A
small amount of trigger logic is associated with eachdetector channel and this is provided by the local trigger
facilities on-board each instrumentation card. Master
Triggers are produced when one of several
pre-programmed multiplicity levels is reached (ie, anumber of detectors involved in multiparameter event).
This is done by summing current outputs provided by
the local trigger of each active channel and combining
this with logic inputs provided directly to the Master
Trigger. The trigger unit is programmable and software
access is again via registers on the VME bus.

IV. HISTOGRAMMER
III. VXI SYSTEMSThe VXI front-end crntes are dedicated toprocessing of analogue pulses from the detectors.
Special components have been designed andmanufactured for the Ge and BGO interface boards
which accept the analogue output pulses from detectors
and provide all the signal processing required to produce
a digital output data stream which can be accessed overthe backplane. A 6 channel Ge board is available andthis is matched by a BGO card which provides signal
conditioning, event vetoing and read-out from the
suppression shields surrounding the Ge detectors. All
adjustable parameters on the Ge and BGO cards areunder control of the software via read and write accessto registers over VME bus. Local trigger facilities arealso provided on each board. Each VXI crate iscontrolled by a Resource Manager (RM) unit which also
contains the Slot 0 module functions. The RM ismodular in its construction and allows the integration ofcommercial VME processor boards offering an on-board
Ethernet network interface with the 3 other RM boards
which provide VXINME interfacing.
Thus thearchitecture of the RM can be updated or tailored tomeet other experimental requirements without complete
re-design. The current RM has been developed byelectronics engineers working on the EUROGAM
project and engineering staff from Struck in Germany.
The company are responsible for the manufacturing of
this unit. Read-out for each crate is provided by aRead-out Controller (ROCO) which shares mastership ofthe VME bus with the Resource Manager. The ROCO
collects data from each instrumentation card

The ability to histogram parameters from individual
detector channels is a requirement of the system and thisis achieved by inserting a Histogrammer into the DT32
chain. This is a single crate VME system which consistsof a special interface together with commerciallyavailable memory and processor modules. The special
interface unit spies on the data passing over the DT32
but does not participate in controlling the flow of datafrom the ROCO. Data to be histogrammed is loaded
into a FIFO which acts as a de-randomising buffer
between the 10 MHz burst rate on the DT32 and theaverage rate at which histogram updates are required. A
software loadable look·up table is used to compare theaddress fields of each parameter passing over the DT32
with internal values to see if this parameter is to behistogrammed. If a match is found the look-up tablealso provides the base address of the area of memory
assigned to this parameter. By smruning the baseaddress and current data value of the parameter thecorrect memory location is then incremented over
VSBbus. Histograms are read out over the VMEbus andshipped by the crate control processor over the set-up
and control Ethernet for visualisation at a user
workstation. Such histograms are generally used tocheck the quality of data from an experiment and tomonitor detector perfonnance. If data rates exceed thecapability of one histogrammer unit additional systems
can be inserted into the DT32 bus and assigned different
groups of parameters to monitor.

S05SRN04
Status Reports: Non-Accelerators

209

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

Components of the system not requiring a very low
noise environment are implemented in a number ofstandard VME crates for economy, commercial
availability of many modules, and efficient use of space.
Functions implemented in this form are Histogramming,
Event Building, On-Line Sorting of Data, High Voltage
Control and Autofill Systems for detector cooling. The
overall system is set-up, controlled and monitored from
UNIX workstations via an Ethernet LAN. A separate
high speed data path is provided for data acquisition.
Users of the system can also use the same workstationfor visualisation of on-line and off-line data. VXworks
has been used for the real time software components ofthe system and runs in all the VME/VXI based
processors.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN04

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

V. EVENT BUILDER

provides general network access to the DRS via its
Ethernet port. The task of the Data Sorter is to provide
on-line analysis of the data.
Multi-dimensional
histograms are built in global memory and can then be
made available to the user for viewing at a workstation.
The main data stream from the DRS is output via aparallel interface to the resource computer.

The Event Builder (EB) is a multiprocessor VME
system which is built entirely of commercially available
modules, except for a small interface board (ROHS!)
which terminates the DT32 bus and passes data to one ormore CES HSM8 l 70 units which are controlled by
FIC8232CPU. The main task of the EB is to fonn
self-contained events from the raw data stream foronward shipment, further processing and/or storage.
The EB can also carry out simple functions such asindividual/shared suppression filters, event filtering andsimple arithmetic operations. The system must be
capable of processing 100% of the data in real-time andit is therefore equipped with a number of MVME165
processors (4 initially) which are assigned to event
processing and operate in parallel on the data stream.
The EB is initially targeted to process about
1 Mbyte/sec of raw data but is expandable by theaddition of further hardware modules. The output
stream of fonnatted events is via a dedicated fibre optic
link driven by a CES FIC8232 and CES ODL8142. The
fibre optic link and its drive units are capable ofoperation at rates up to 6 Mbytes/sec. Control of the EB
is via the Ethernet LAN and as the unit is fully
programmable other software functions can be added as
experience of user requirements is gained during
operation of the array.

VII. RESOURCE COMPUTERThe Resource Computer which provides tape anddisc drive facilities to the data acquisition system is a
GEC4190 machine, one of a range of computers whichhave been used at Daresbury for several years with great
success. Tape server software has been written for the
GEC4190 which allows the event by event data received
from the DRS to be written to one or more Exabyte 8500
drives. The server software supports different data
streams and it is the responsibility of the user to selectthe event type to be assigned to a particular stream. At alater stage of the project a UNIX based system will be
developed to provide tape and disc resources.
VIIL HIGH VOLTAGE CONTROLThe High Voltage (HV) supplies required for thedetectors are provided by LeCroy 1440 high voltage
units which are controlled and monitored via a LeCroy
1131 interface board and controlled by a VME processor
unit connected to the Ethernet. The software allows
interrogation of each HV mainframe to find unit type,the voltage setting for each channel, ramp rate, andcurrent limits; it will also continuously monitor all
channels to check for any irregularities.

VI. DATA ROUTER AND SORTER
The Data Router and Sorter (DRS) is a VME
system which sits at the remote end (ie outside theexperimental area) of the fibre optic link driven by the
EB. In addition to providing a high speed data path theoptical link also provides an excellent means of isolating
electrical noise and potential earth loop problems in thecomputing zone from the more sensitive experimental
area.

A hardware interlock to the Autofill System has
been provided so that any failure of the cooling system
to an individual detector will cause shut-down of theappropriate HV channel. This condition is detected by
the control task and reported back to the user. A local
database of the current set-up state of all HV channels ismaintained and is available to the user over the networkfor viewing and/or storage for use on a future
experiment. The user interface to the HV system will befrom the UNIX workstation.

Although contained in the same crate the functionsof routing and sorting are to be seen as completely
separate facilities. The Router fonns part of the dataacquisition path whereas passing data to the Sorter is
optiorial and to be selected by the user.
The optical link is .received by an identical pair ofunits to those in the EB (FIC8232/0DL8142). The
Router software then allows all or some percentage ofdata to be sent to ·the Sorter or alternatively directly
written to tape; if required, both paths can beaccommodated in parallel. The Data Sorter consists of anumber of MVME165 processors which are controlled
and supervised by an MVME147 unit which also

IX.AUTOF1LL
It is necessary for the Ge detectors in the
EUROGAM array to be kept at liquid nitrogentemperature during operation and data taking. This isaccomplished by means of an Autofill System which
regulates a series of solenoid valves according to thecooling requirements of each detector as indicated by

S05SRN04
210

Status Reports: Non-Accelerators
210

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingtemperature monitoring. A VME syslem wilh local
processing capability has been provided to control theoperation and much of the controlling software runs instand-alone mode. The VME system has a network
interface onto the control Ethernet thus allowing
monitoring information and error messages to be passed
to remote terminals for viewing.
The Autofill
equipment has been designed with an optional manual· mode of operation and as indicated in the section on HVcontrol there is a hardware interlock to ensure thevoltage supply is removed if the temperature of thedetector exceeds its limits.

up and monitoring, lhrough acquisition to analysis
functions, all controlled from a UNIX workstation
offering graphical menus in multiple windows to meetall general requirements.
The software has been
designed so that it is modular in its architecture thus
providing for easier maintenance and the developmentof additional facilities in the future.
Whilst UNIX workstations were selected to provide
the user interface,
UNIX is not considered an
appropriate operating system for the real time elementsof the software which run in the VXI and VME
processors and which provide various functions in the
EUROGAM architecture. VxWorks was chosen as thereal-time kernel and has proved to be very efficient inboth its ease of development and run-time performance.

X. ENVIRONMENTAL MONITORING
To ensure the quality of lhe environment in which
EUROGAM operates, the data acquisition system isbuilt into water cooled racking systems. To prevent
damage under fault conditions and to provide early
detection of potential problems, the systems aremonitored for temperature, fan failure, power supplies,
etc. This information is fed back to lhe control system
via VME interfaces which are accessed over the
network.

The software is designed around the client/server
mode of working and Ethernet provides communications
to all areas of the distributed system. Four main server
programs have been developed to provide access to alldata acquisition resources, these are a register server,
spectrum server, tape server, and message/error logger.
The main path for data from the experiment is kept
separate and is as described in the hardware section.
This palh is not used for software commands and is
uni-directional. Figure 2 (overleaf) shows the overall
software structure and how it relates to the hardware
components.

XI. UNIX WORKSTATIONS
Networked workstations provide lhe user, andwhere appropriate, engineering support staff wilh aninterface to lhe whole of the EUROGAM control, dataacquisition and data analysis system. This is achievedby using a window system based on XI 1 which gives theuser access to a series of purpose designed windows
which provide visualisation and control to various areasof the system.
The workstations also provide a
programming environment for users in which they candevelop their own software tools for analysis. Menus
are provided to set up EUROGAM to meet individual
experimental requirements and the current configuration
Access to thestatus can be sorted for future use.
system is not restricted to any single workstation andprovides facilities for groups of users to work in parallel.
Security features are built into the network system toprevent access to areas of the array software andruirdware facilities which could be damaged in error.

XIILSOFfWARECOMPONENTS
Communications

Common network software is used to access allcomponents of the system and Ethernet is used as thecarrier LAN. CPUs which are attached to the Ethernet
can also act as gateways for communication with otherprocessors in the same crate using the backplane as a
network.
The protocols used for communication are:

XII. SOFTWARE ENVmONMENT
The individual hardware components of the systemhave been described and form a networked set of
distributed computing elements. It is the softwareenvironment which provides the integrated approach to
EUROGAM control and data acquisition and offers theuser complete control of his or her experiment, from set

L

NSF (Network File System).

2.

RPC (Remote Procedure Calls).

3.

XDR (eXtemal Data Representation).

4.

UDP/IP(User
Protocol.)5.

IP (Internet Router).

DatagramProtoco]/Internet

S05SRN04
Status Reports: Non-Accelerators

211
211

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-S05SRN04

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

VllCr Interface- - - Elhcrne<

Menq• I Emir
LoggerfIGll!Ut 2.

Communications between clients and servers use
RPC to pass requests for control, monitoring andread-out functions. Fixed UDP/IP ports are used byservers to avoid delays which the use of dynamic ports
would involve. To offer facilities which are more suited
to the data acquisition and control envirorunent thestandard Sun Microsystems RPC library has been
extended to provide:

1.

Asynchronous RPC to improve response to userinterface requests.

2.

Multiple RPC requests to different servers.

3.

Variable RPC timeouts for specific applications.

2.

Software is designed and developed using UNIX
workstations and is UNIX source compatible.

4.

Performs well in the areas of task scheduling andinterrupt handling.

5.

Remote debugging facilities are available.

6.

Support is provided for amanufacturers products

wide range of

The Register Server allows client programs tocommunicate with server processes anywhere within the
EUROGAM system.
It is a general purpose
communications package which can be tailored to fit aparticular application envirorunent When the system is
initialised, each server process is loaded with theapplication specific processes it requires to carry out its
designated task which can be viewed as a set, or, insome cases, sequence of writable and readable registers
within the VXI and VME systems for which it is
responsible. Registers are defined dynamically byclients using the Register Server protocol and specify the
local procedure to be invoked when the register issubsequently accessed.
The Register Server also

The decision to run VxWorks as the real-timekernel was based on the following criteria:
Offers a multi-tasking envirorunent designed tomeet the need of real-time control and dataacquisition.

BSD networking available.

XV. REGISTER SERVER

XIV. VXWORKS

I.

3.

S05SRN04
212

Status Reports: Non-Accelerators212

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingprovides for data to be passed between client processes
and server applications.
The Register Server Primitives are: a) Read,b) Write, c) Initialise, d) Read Attribute, e) Write
Attribute.
Attributes are additional pieces ofinfonnation required by application procedures, forexample the offset address of a register in an individual
VXI or VME card.
For reading and/or writing
sequences of registers wild-card techniques have been
implemented based on the register name. This allows
many registers to be accessed with a single RPC request.
XVI. SPECTRUM SERVER
The Spectrum Server is responsible for thehandling of all spectra and provides access to data in the
Histogrammer and Sorter units and is also able to accessoff-line spectra held on disc. The server controls andallocates memory in the Histogrammer as required tomeet user demand and will pass the address of anindividual memory area assigned to a parameter to behistogrammed to the Histogrammer look-up table via theclient workstation using the Register Server. In response
to user requests spectra can be named and created andthen read back for on-line display at the workstation or
for off-line storage.
XVII.TAPE SERVER

XIX. OTHER SOFTWAREEUROGAM provides facilities such as Event
Building and Data Sorting described in the hardware
section. These functions are controlled and accessed in
the same way as other VXI and VME devices and use
the VxWork:s kernel. In order to perform theirdesignated scientific function each system has specificapplication code which is tailored to meet experimental
needs. This software is not described in the paper. To
provide the graphical scenes required for the userinterface the Open Look Window Manager is used
together with DEV Guide to provide the development
environment. To complete the software system several
small application routines are provided to meet specificrequirements, these routines use the software
infrastructure described.
XX. ACKNOWLEDGEMENTS
The EUROGAM project is a funded by IN2P3 in
France and by SERC in the UK. The author wishes toacknowledge and thank the members of hardware andsoftware teams in France and the UK who have been
responsible for the development and production ofindividual items referred to in this paper, also thephysicists who have provided discussion and support forthe control and data acquisition project. Special thanks
to V F E Pucknell for assistance with the software
section.

As previously mentioned in the section on the
Resource Computer the server software provides accessto tape storage devices. Data striping has been
implemented to permit data to be written to several units
in parallel when higher data rates are required than canbe accommodated by one drive. Alternatively the samedata stream can be written to multiple tapes
simultaneously which is a useful feature when several
users in an experimental collaboration wish for theirown copy to take to their home institute.
XVIII. MESSAGE & ERROR LOGGER
When problems or errors occur in the system areport is passed to this process. Such items would be
HY malfunction, Autofill problems or an environmental
failure. Clients programmes can declare that they areinterested in receiving messages from a particular areaof the system and these message types are thenforwarded to the client in addition to being logged by
the server.

S05SRN04
Status Reports: Non-Accelerators

213

213

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-S05SRN04

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

B : Brightness distribution
D : Baseline vectors : Unit vector
Os: Geometric delay
V : Correlator output

ICALEPCS1991, Tsukuba, Japan

Correlator-Multipller+lntegralor

Antenna
Drive
Controller

V{u,v) <- FT - B(x,y)

Figure 2: Aperture synthesis observation with two element
interferometer.

Since, in such a case, the delay tracking cannot compensate
the phase difference due to the path difference, exactly, it
is necessary to compensate residual phase by controlingthe phase of LO with a fringe rotator (phase tracking).
Therefore, for aperture synthesis observations with the
NMA, we must control the antenna tracking, the delay
tracking, and the phase tracking. Since the resolutionof the delay tracking system is finite, control sequencesof the delay tracking and the phase tracking are very
complicated. These control accuracies affect the qualities of radio images obtained with the aperture synthesis
observations[4].

Tuning of the Receiver System

The receiver system of the NMA consists of SIS mixers,
LO oscillators, IF amplifiers, and a reference signal synthesizer. Before each observation, observers must optimize many parameters of each component of the receiversystem. This task which is called as "tuning" is very important for sensitivities. At higher frequencies, the tuning
becomes much more important and its sequence is very
complicated. These know-hows of manual tuning must be
programmed for each device in the control software.

FFT SpectroCorrelator (FX)

Figure 3: Hardware system of the NMA.

2.3

2.2

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN05

Operational requirements

Generally, astronomical observations with radio telescopes
are serieses of many short observations of different celetial
objects. In typical aperture synthesis observations with the
NMA, of which duration is 6"" 10hours,a10,.., 15 minutes
observation of standard objects is taken every 30 ,..., 60
minutes in order to monitor complex gain variation of thearray. Such observing sequences depend on observational
requirements of observers. Thus, it is desireble that thecontrol system provides an environment where observers
can easily realize their observing sequences.
Since we have many observers who are inexperienced in
the NMA, a friendly human interface is very important
for the control system. Quick display of backend data,
observing parameter menus, and multi windows are very
effective for smooth operations.

3

OLD CONTROL SYSTEM

The old control system of the NMA was a centralized system, which ran on an IBM compatible mainframe and two
mini-computers. Main control tasks (sequence control ofobserving modes, tracking control, data acquisition, human interfaces, etc.) ran on the mainframe. A terminalof the mainframe was used as a telescope operator console. The mini-computers managed communication be-

S05SRN05
Status Reports: Non-Accelerators

215

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-S05SRN05

tween the mainframe and each device of the array which
was connected with the mini-computers via GPIB. Hydrogen maser clock was supplied to the mini-computers sothat tracking parameters were sent to the tracking devices
at the· exact time. With this system, we realized high tracking accuracy and high reliability of array control [5].
However, since softwares of the system were complicatedand not flexible, there were following drawbacks in it:

Antenna
Drive

Dlglllll

DelayController

SIS,t.O,IF
Sy•tem

L To add functions for new devices takes very long time.
2. It is difficult for observers to develop control programsfor their own observing sequences.
In particular, since the progress of the receiver system isvery rapid, it was difficult to develop control programs forvarious receiver tuning methods. Besides these drawbacks,
it is hard to find out good graphical user interfaces (GUl's)
for IBM compatible mainframe. To overcome these problems, we have developed a new control system of the NMA.

r................... .. ...... . , ... "'.

ETHERNET! FACOM S-41370 i:
I(SPARC 370):
It.. ......... - ... ,. .............. ..,J

4

MANAGERNEW CONTROL SYSTEM

The new control system of the NMA, which is shown in Figure 4, is divided into three sub-systems (MANAGER, ENGINE, and STATUS CONTROLLER). MANAGER subsystem as a telescope operator console provides the human interface. A UNIX workstation has been introducedin this sub-system, because of its high graphic capabilities and multi-window environment. ENGINE sub-system
tracks astronomical objects and acquire the data from thebackend. Tuning of the receiver system is realized withSTATUS CONTROLLER sub-system. Several personal
computers are used for this sub-system, because of theirsimplicity of programming and reduced costs. These subsystems are connected with an ethernet.

4.1

Figure 4: New control system of the NMA.
this sub-system. Since these programs a.re not directly
connected with real-time control tasks, it is easy for ob.
servers to make new ones for their observational requirements. The SOCKET interface system between the workstation and the mainframe was developed by Fujitsu.

To
ENGINE.-----....
Communlw---•cator

Main
ConsoleMANAGER
Main

ConsoleServer

To Status

MANAGERc~

MANAGER runs on a UNIX workstation, Fujitsu S-4/370(SPARC 370 compatible) with a main memory of 32
MByte. Functions of MANAGER are as follows:

Network
Files forArray Control

L Making command tables (OBSERVATION BOOK)
for various observing sequences and sending them to
ENGINE.

Schedule Table
Figure 5: MANAGER.

2. Communicate with ENGINE by using of a. SOCKETinterface.
3. Providing flexible GUI based on the X-Window to observers.

Scheduler

4.2

ENGINEENGINE runs on an IBM compatible mainframe (Fujitsu
M760) and two mini-computers (Fujitsu A80 and A60).
This hardware structure is the same as that of the previous
control system. The followings are functions of ENGINE:

4. Acquisition of the monitoring data from each device.
5. Displaying the backend data quickly.
Figure 5 shows the software structure of MANAGER.
There a.re several standard programs (OBS.BOOK generators) which make standard OBSERVATION BOOKs in

1. Executing observing sequences in an OBSERVATIONBOOK from MANAGER.

S05SRN05
216

Status Reports: Non-Accelerators
216

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

2. Calculating accurate tracking parameters for every
400 ms.

Actually, a receiver engineer wrote the software for the tuning by himself. Thus, the software can use his know-how
of the receiver system.

3. Sending the paramters to each device at the exacttime.
4. Acquiring the data from the backend and applying therealtime correction to these data by using of control
parameters.
Software structure of ENGINE is shown in Figure 6.
There are three main tasks on M760, which share a common memory area to communicate each other quickly.
This sub-system is very rigid so that it is possible to realize
the accurate tracking control and data acquisition without
data losses. Softwares of tracking control and data acquisition are simple and compact compared to those of theprevious system.

5

SUMMARY

We have developed a new control system of the Nobeyama
Millimeter Array. While the old system was a centralized one, we have constructed a distributed control system
which consists of three sub-systems. Thus, the new system
will provide a friendly GU l's for observers and flexible enviroments for adding new functions. The developement has
almost completed and has been be used for observations
from the end of 1991.

References[1] M. Ishiguro et al., "The Nobeyama Millimeter-Wave
Interferometer", in "Instrumentation and Techniques
for Radio Astronomy", ed. P. Goldsmith, IEEE Press,
1988, pp.151-155.

MANAGER
Ethernet[2] R. Kawabe et al., "A Dual-Frequency 40/100 GHz
SIS Receiver for the Nobeyama Millimeter-Wave Array", in the Srd Asia-Pacific Microwave Conference
Proceedings, Tokyo, 1990, pp.217-220.
[3] Y. Chikada et al., "A 6 x 320-MHz 1024-Channel
FFT Cross-Spectrum Analyzer for Radio Astronomy", Proc. IEEE, vol. 75, pp.1203-1208, 1987.
[4] K.-1. Morita et al., "Tracking Accuracy of Astronomical Objects in the Nobeyama Millimeter Array",
Trans. IEICE Japan, vol. J73-B-ll, pp.41-50, 1990.
DeviceCommun!·cator

DeviceCommunl·
ca torAntenna

Delay, Phase~100Byte/40ms[5] K.-1. Morita et el., "Control System of the Nobeyama
Millimeter-wave Array", University of Tokyo, Tokyo
Astronomical Observatory Report vol. 21, pp.82-100,
1987.

Backend
120kByte/s~100Byte/s[6} A. R. Thompson, J. M. Moran, and G. W. Swenson, Jr., "Interferometry and Synthesis in Radio Astronomy", New York: John Wiley & Sons, 1986.

Figure 6: ENGINE.

4.3

STATUS CONTROLLER

Functions of this sub-system are as follows:
1. Controling and monitoring many components of thereceiver system.

2. Communicating with MANAGER through NFS.
This sub-system consists of 6 MS-DOS 80286-based personal computers (NEC PC9801). Personal computers with
MS-DOS do not have a multi-tasking environment. However, programming is so easy on each personal computerthat duration for the software developement is very short.

S05SRN05
Status Reports: Non-Accelerators

217
217

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-S05SRN05

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN06

plants. Plant support control is provided for controlling 3.2 ZENKE/ Computer System and Changes of Its
conditions of machines and monitoring their status. Included Configuration
are on systems for operation-mode control, alarm monitoring,
emergency control, protective interlock, etc. These control
The computer system for ZENKE! was originallysystems are supported by a complex system of computers and composed of seven 16-bit minicomputers of HIDIC-80Es
CAMAC systems named the "plant support and monitoring" (Hitachi Ltd.) having main memories of 320 to 448 KW. The
system.
cycle time of CPU is 0.48 µsec~ Five of them, having a
Sequence control of the actuators and fast feedback control shared memory of 128 KW, were located in the JT-60· of plasmas are included in the plasma discharge control. This computer room. The rest, having a shared memory of 64 KW,
control concept stems from a distinctive feature in the were in a local control room of the rectifier building. The first
tokamak operation where plasma discharge with duration of a five CPUs are used for the plant support and monitoring
few tens of seconds is executed every few tens of minutes. the discharge control (lb), the real-time plasma control (lb )The plasma discharge control is executed via three complex and their man/machine interface (laM and lbM). The latter two
systems of computers and CAMAC systems named the (llb) were used for making a feedback control loop for plasma"discharge control", "real-time control" and "feedback control" equilibrium control in combination with direct digitalsystems. Timing systems are also used for supplying trigger controllers (DDCs) in the poloidal field coil power supply.
pulses and clock pulses in the discharge sequence control and The lib computer was connected to the lb computer through an
the real-lime and feedback plasma control.
optical linkage bus named "data freeway". Since the ZENKE!
The computer configuration of the JT-60 control system isshown in Fig. 1.

cu:l·

I/Os

VME
x3)
ToDDCsln
PF-Coil PS• NBI Heating
System••••••RFHeatlng

SystemFig. 1 Computer Configuration of the JT-60 Control System

S05SRN06
Status Reports: Non-Accelerators

219

219

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-S05SRN06

computer system is a multi-bus system with 1/0 buses that the previous section. The ZENKE! computers of HIDIC-80Es
are controlled through both of PCMA (Processor Controlled are connected to the subsystems that constitute a major part ofMemory Access) and DMA (Direct Memory Access) channels, the JT-60 facility through the nodal crates called
the CPUs can share their peripherals of disks, printers, etc. A communication crates. Various types of CAMAC highways
real-time operating system named "Process Monitor System- (central highways) are used depending on their data
M (PMS-M)" is employed in this multi-computer system. communication requirements [3]. Some of the central
The PMS-M has the functions of inter-CPU watching, control highways are composed of dual serial highways for reliability.
of tasks under other CPUs, control of I/Os shared by multi- As the NBI and RF heating systems and the data processing
system for plasma diagnostic instruments have their own
CPUs, etc.
The configuration of the ZENKEI computer system has minicomputers and a general-purpose large computer, thebeen changed along with the progress of the past five-year ZENKEI computers are also connected to them through theiroperation. The feedback control was originally performed by dedicated inter-computer linkage buses. The ZENKEI
one of HIDIC-80Es and the other is for back-up. Since the discharge control computer is also connected to a front-end
requirements for the control system were increased, the IIb processor at the Japan Atomic Energy Research Institutesystem was, then, modified to be a pipelined system by using (JAERI) computer center, where the JT-60 experimental
the two HIDIC-80Es. Moreover, a preprocessor system with database is created. For local data transfer, each subsystem
digital signal processors (DSPs) was added to the pipelined controller has its own highways named subsystem highways,
system. Coping with the requirements for faster and more device highways and local test highways.
accurate control in the JT-60 upgrade, the minicomputers in
The module configuration of the communication crate on
the Ilb system have been superseded by a VME-based the central highways in the Ia and lb computer systems is
multiprocessor system equipped with 32-bit RISC processors. shown in Fig. 1. An auxiliary controller with D-port (ACD)
Modern workstations connected via an Ethernet network have is installed in the crate as a mail-box module forbeen introduced for improving the ZENKEI man/machine communication. A dual-serial U-port adapter is used forinterface, which previously was implemented on two of the conversion of the signals from/to the serial highway to/fromminicomputers HIDIC-80Es and consoles with dedicated the ACD. Besides the ACD module, two intelligent modules
character and graphic terminals.
are installed in the crate. One is a crate controller which isdriven by the local test highway. The other is an auxiliary
4. DATA COMMUNICATION
controller with a 16-bit microcomputer of Intel 8086 or
AND CAMAC SYS'IEM
HIDIC-08L (ACM). These were developed by Hitachi Ltd.
and Toshiba Co. respectively. The crate controller, the ACD
4.1 Jl-60 Monitoring and Control Dataand lhe ACM can control the dataway in that order of priority.
The ACD is a 3-wide CAMAC module which interfaces to
The JT-60 control system hand.les a large amount of data lhe backplane dataway and the serial highway D-port at thefor plant support and monitoring and for discharge and plasma front panel. It has two 16-bit, 2 KW buffer memories and twocontrol. The plant support and monitoring system must send 24-bit data registers where the replies in the handshakedevice status data for each subsystem to the central control protocol of the communication are written and read.
computer every 5 sec to l minute. The number of monitoring
As the ZENKEI computer system must supervise many
points amounts to about 7500 analog and 9500 digital inputs. subsystems, a more efficient method than CAMAC is required
Second, it must possess sufficient data transfer capability so for the data communication between ZENKE! and thethat operators are able to watch the discharge results and subsystem controllers. Hence, the protocol and data format ofquickly decide the conditions for the next shot. The original this transfer extends lhe CAMAC standard to include a sodischarge data amounted to about 3 MB per shot (10 sec called" variable word-length " transfer. A single command
discharge duration) every 10 minute in lhe standard operation can follow a block of data in conjunction with the function ofscheme. At present, the data amounts to about 8 MB due to the dedicated serial driver for HIDIC-80E. This variable wordincrease of the discharge duration corresponding to the lenglh data transfer can operate about 2.S times faster than the
upgraded JT-60 tokamak. Thirdly, it must exchange several standard protocol. Furthermore, since each subsystem wastens of control commands and status data wilh each subsystem contracted to industry separately, lhe handshake protocol andevery 10 msec for the real-time control and every 1 msec (250 data format for the communication between the ZENKE!
µsec for the upgrade) for the feedback control of plasma computers and the subsystem CAMACs were standardized as
position and shape.
JT-60 standards at JAERI.
These communication systems allow full data transfer in
4 .2 Communication Systems
spite of the increase in the amount of data, in particular theincreased amount of discharge and feedback control data in the
As shown in Fig. 1, a hierarchical structure was adopted in JT-60 Upgrade.
the CAMAC highway network corresponding to thehierarchical structure of the JT-60 control system described in

S05SRN06
220

Status Reports: Non-Accelerators

5. DISCHARGE SEQUENCE CONTROL
AND 11MJNG SYSTEM

5.1 Discharge Sequence
Discharge control involves establishing a set of condition
parameters, implementing the discharge and collecting data
resulting from the discharge. This process is repeatedly
performed due to the pulse operation of the JT-60 tokamak.
Various types of discharge sequence have been prepared forhigh power pulse discharge, discharge cleaning and test
operation. The concept of the sequential control phase wasintroduced for synchronizing the status of ZENKE! and thecontrollers of the subsystems used as the discharge actuators.
The standard shot interval was originally designed to be 10
minutes. The discharge sequence is implemented bycommand and reply messages between the lb computer and thesubsystem controllers in conjunction with trigger pulses forthe actuators generated by the timing systems.
The functions of so-called "pre-shot check" and "post-shotcheck" on the machine status are prepared for the precaution ofmachine 1roubles. The lb computer in association with thealarm systems installed in the la computer and the hard-wired
interlock system performs the discharge termination forprotection of the machines at the occurrence of abnormal
events according to their levels of seriousness.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN06

decodes them and replies the corresponding "ACK" signals to
the TGT within 40 µsec. In case of faults occurred in thetrigger pulse generation by TMG and the transmission by
TGT and TGR, Look-At Me (LAM) signals are available forthe lb computer to terminate the discharge sequence.

6. PLASMA CONTROLA control system has to be designed according to its
control objective, which implies sufficient understanding of
the system including the objective. Since this premise did notalways hold for the tokamak plasma, the control system was
required to have a wide range of flexibility to tune the control
method. Reliability was also required from the view-point ofavailability of the control system. To satisfy theserequirements, we decided to build a fully-digital control systemwith digital computers and CAMAC-standard equipments [4].
Thus, we were able to prepare many variations of plasma
conirol structure, by changing the discharge condition setting.
In spite of the system having this flexibility, we oftenchanged the control system by replacing computers with moreadvanced ones.
In this section, the present system structure andperformance for the IT-60U plasma control are described.

6.1 Outline of System Configuration

5.2 Timing System

As shown in Fig. 2, the JT-60 plasma control system
contains two feedback loops. The major loop controls plasma
In the design of the timing system, consideration was heating and gas fueling and the minor loop controls plasma
given to safety, precision and reproducibility, correction of position and current via five sets of poloidal field coils. The
disorder in control sequence and linkage with real-time plasma control cycle of each loop was determined by its control
control. In order to satisfy these requirements, we made objectives. The cycle time of the major loop is 10 msec andprovision for the timing system to have (I) control interlock, the minor one is 0.25 and 0.5 msec.
In the major loop, the lbR computer supervises the(2) timing pulse transfer with response recognition, (3) eventcontrollers of the gas injectors and the NBI and RF heatingoriented control and {4) command ou&put by computer access.
The timing system is characterized by the following four systems by using a byte-serial highway for the transfer ofkinds of CAMAC modules: a clock pulse generator {CPO), a status data and control commands during a shot. A dual-port
timing pulse generator {TMG), a timing pulse transmitter memory module with D-port {DPMD), which has two 16-bit,(TGT) and a timing pulse receiver (TGR). The timing system 128-word buffer memories, is installed in each communicationis under the control of the lb and IbR computers through crate in the Ib8- highway as a mail-box module for the fast data
CAMAC highways.
transfer. In order.to increase the data transfer speed, the byteThe CPO generates the 1-msec clock pulse which is used serial driver, which was developed for HIDIC-80E, has a
as an external count-down clock to the TMG. The clock pulse "command buffer" to burst CAMAC functions and data to theis also used as an interruption signal of the control cycle in highway.
.
A VME-bus system has the characteristics that (1) we canthe real-time plasma control. The TMG has five 16-bit
presettable counters. Hence, the sequence control from 60 sec utilize advanced micro-processors with 32-bit or more
before the discharge to the termination of discharge is accuracy, (2) its system clock (16 MHz) is faster than theperformed with an accuracy of 1 msec. Each counter can CAMAC system clock (5 MHz), {3) VME-bus modules
generate a timing pulse when the "AND" condition is satisfied interfacing with CAMAC systems are on the market, etc. In
with its time-up and the event signal given by the computer in the minor control loop, faster and more accurate computation
the discharge sequence. Transmission of the timing signal is were required for plasma position and current control at lhe IT·
executed by a handshake procedure by using an "acknowledge 60 upgrade. Hence, we decided to supersede the old 16-bit(ACK)" signal in combination with the TGT and TGR minicomputer-based feedback control system {lib) and the 16modules. The TGT module can encode and 1ransmit 16- bit microcomputer-based DDCs by VME-based systems
channel timing signals and the TGR module receives and equipped with advanced 32-bit microcomputers [5].
:;.,S05SRN06
Status Reports: Non-Accelerators

221

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, JapanThe old 16-bit microcomputers (i-8086 based ACMs) in
the DDCs were superseded by VME-based 32-bit
microcomputers named MVME147 (Motorola Inc., U.S.A.).
J/O modules, however, are installed in the DDC CAMAC
crates as before.
Another CAMAC crate is provided for transferring data
between the Ilb and the DDCs and between the IIb and the lb
computers. The VME racks in the IIb system are connected to
the CAMAC crate via a CAMAC branch driver (CBD8210
made by Creative Electronic Systems, Switzerland), a branchhighway and a type-A2 crate controller (CCA2 made byStandard Engineering Corp., U.S.A.).
Specifications on the computational speed of thecomputers used in the plasma control system are summarizedin Table I. Data transfer rates are also shown in Table 2.

Table 1 Computer Specification
RISC Micro,orocessor £MYME181l
MC88100 RISC Microprocessor at 20 or 25 MHz
16 to 20 VAX MIPS
HIDIC-80E
Cycle Time: 0.48 µsec,
0.8 MIPS, 0.3 FLOPS
Table 2 Data Transfer Rate
HIDIC-80E (BSD) K words to I crate/module-DPMD
Time = 80 + 2.8 x K (µsec)
MVME181 (CBD) K words to any crate/module-ACB
Time = 2.4 x K (µsec)

6.2 Peifonnance of Plasma Control

The new IIb control system is composed of 4 VME racks,
which are connected with each other through 6 bus
repeater/expanders (PT-VME902A-l, Performance
Technologies, Inc., U.S.A.). Three MC88100 based RISCs
named MVME181 (Motorola Inc., U.S.A.) are installed in oneof the racks. The other three racks are equipped with I/0
modules. The parallel and pipe-lined processing of signal
inputting, calculation of plasma state variables, feedback
calculation and command output by using the three RISCs is
synchronized by interruption from a 250-µsec clock pulse
given by the timing system and the flags transferred between
the RISCs through VME-bus. The programs in the RISCs
are written in C language. The host computer for developing
the VME microcomputer programs is a Sun3/140M
workstation (Sun Microsystems, Inc., U.S.A.).
Galt Vollqe

Real-Time
ControlComputerPower/Pb•
Statm
lllJedhm ON/OFF

The newly developed plasma control system is working
well in the initial experiments at the JT-60 upgrade. Stable
deuterium plasmas with plasma current up to 5-MA and the
NBI power of 20 MW have been produced. The plasma
position and current are well controlled by PD (proportionaland differential) control with matrix gain. For example, thedifferences of the state variables between the observed anddesired values in a 4-MA divertor plasma are about 15 kA forthe plasma current and less than about 1 cm for the plasma
horizontal and vertical positions and the height of X-point (across point of the separatrix line of plasma boundary).
Dynamic switching of the control scheme is available forsophisticated control in the initiation and termination ofplasmas. The phase control also functions well for discharge
termination in association with the computer and hard-wired
discharge fault systems.

G.. l~orControl S stem
llFHeatln1
Control S stem

Statm

NBlffeat1111
Control S stemL

OH.CollPS
Current

Feedback

ControlComputer/Voltap
Command

P·CollCurnnl

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN06

V..CollPS

A

H.CoUPSsM

DCW..CoDPS/Voltaae. T..Coll...__cu_rren_1_ _ _M_11H...._llc_Sen__so_r_s11._na1s_ _-1 Electro-Maanetk:A· Detectors

Fig. 2 Data flow of the 1T-60U plasma control system

S05SRN06
222

Status Reports: Non-Accelerators

7. MAN/MACHINE INTERFACEICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN06

80Es to the SVP. The TCP/IP protocol is used for data
communication on the network. The NFS (Network: File
System) protocol is also used as an application-Jevel protocol
for a large amount of data transfer. The application softwarein the new man/machine interface of these functions are
written in C language. A window manager "SunView" isfully used in the displays of these control functions on theworkstations. Multiple windows are displayed and Japanesecharacters are available. Click operation with a mouse can beused in the operation such as selection of items on thedisplays via "pop-up menus" and "panel windows" of"SunView".
The new ZENKE! man/machine interface has been fully
used in the initial operation of the IT-60U. The load on theoperators has been reduced. In particular, mistakes in theoperation of setting the discharge conditions has been greatly
reduced and the operational efficiency has been increased. This
resulted in the decrease in the number of the operators. Somelessons remain from the view point of time response. For
example, when the operator wants to display waveforms ofdischarge result data with a large amount of data points, he can
not wait for the display without irritation.

As the man/machine interface for the JT-60 plasma
operation, the ZENKE! control system uses modern
workstations for operator's consoles. A large mimic panel isprovided for displaying overall status of the JT-60U. ZENKEI
also has an ITV system and a broadcasting system. Eachsubsystem has its own console for the individual operation.
The subsystem console is equipped with some CRTs having
keyboards or light pens, button switches, mimic panels andalann annunciators. These consoles are located in the JT-60
central control room. For individual operation of thesubsysem devices, each subsystem also has its local console.
In the experience of the past five-year plasma operation,
one of the most troublesome operations was the operation ofsetting the discharge condition parameters. As described in
Section 5, this operation must be implemented within a shorttime during a shot-interval. Problems arose because of
inefficient consistency checks among the condition parameters
and lack of guidance for the setting. Improvement of thefunctions of plant monitoring and discharge results data
display was also required for the efficient and comfortable
operation in the JT-60 experiments. For example, the
ACKNOWLEOOEMENTS
ZENKE! operator's consoles before the upgrade were equippedwith old type color semi-graphic and B&W graphic terminals.
We were not able to use Japanese characters in these terminals.
The author wish to thank the members of Control Group
Moreover, it was required that the layout of the consoles was in Division of JT-60 Facility I at JAERI for theirchanged in order to increase the number of consoles for the collaboration in the development of the JT..6Q control system.
plasma diagnostic devices.
REFERENCES
In order to cope with the above requirements, no moreroom to install new programs for the improvement was left in
the original computer system because it was designed 10 years [l] H. Ninomiya, et al_., "JT-60 Upgrade Device forago. Memory sizes were small. The peripherals were so old
Confinement and Steady State Studies," Plasma Devices
that we could not make "user-friendly" interfaces. Hence, theand Operations, vol. 1, 1990, pp.43-65.
hardware which composed the operator's consoles has beensuperseded by the modem workstations connected through a [2] I. Kondo, et al., "The JT-60 Central Control System,"
Fusion Engineering and Design, vol.5, 1987, pp.69-84.
network [6].
As shown in Fig. 1, the new man/machine interface at the [3] T. Kimura, et al., "Communication System in JT-60
central level consists of ten workstations: Sun3/80GX andControl," in Proceedings of the 10th Symposium on
AS4040 (SPARC) (Toshiba Co., Japan) as the operator's
Fusion Engineering, Philadelphia, 1983, pp.398-404.
consoles, one workstation of Sun3/470GX (Sun[4) K. Kurihara, et al., "JT-60 Plasma Control System,"
Microsystems, Inc., U.S.A.) as a file server of the discharge
Fusion Engineering and Design, vol.11, 1990, pp.441condition and an 32-bit industry control computer of HIDIC454.
V90/45 (Hitachi, Ltd.) as a file server of plant monitoring andplasma control data (We shall call it SVP). The workstations [5] T. Kimura, et al., "VME Multiprocessor System forare installed on ordinary OA desks. Hence, the layout of the
Plasma Control at the JT-60 Upgrade," IEEE Trans. on
consoles in the control room can be easily changed. The SVP
Nuclear Science, vol.35, 1989, pp.1554-1558.
computer, which works under a combination of real-time and[6] I. Yonekawa, et al., "A New Workstation Based
UNIX operating systems, is connected to the workstations
Man/Machine Interface System for the JT-60 Upgrade,"through an Ethernet network. The SVP computer can shareto be presented at this conference.
the 4-MB memory with the existing minicomputers of
HIDIC-80Es. The shared memory is used for transferring alarge amount of discharge result data. A OMA-controlled 16bit paralle1 bus, whose controller is named CLC-P, is also
provided for transferring a small amount of data such as event
data from alarms and the discharge sequence from the HIDIC-

S05SRN06
Status Reports: Non-Accelerators

223

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-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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN07

Central Controller

II. SUBSYSTEM

Synchronization
Interlock

A. Functional Decentralization

Manipulation

Inquiry
Approval

All facilities contained in the LHD system have a local
controller. The local controller is assumed to (l)fully control
all of the devices under its control, (2)monitor the devices andthe peripheral conditions, and (3)communicate with _thecentral controller (also with the other local system in a
restricted case) in order to establish mutual cooperation, as
displayed in Fig.2. This unit is called a subsystem(SS). To
simplify the whole control system the division into SSs must
be optimized as to the quantity and quality of thecommunication, because the number of items to becommunicated with others will be greatly different according
to the division. An individual SS may have many sensors toassure the safety of itself. If a particular operation is notdangerous and has no necessity to cooperate with others, theoperation can be managed locally. Such a inner-interlock,solved within the SS, gives the reliability and simple
configuration. This decentralization, however, is designed to
draw out more centralized control for the whole system.

B. Operation of Utilities
There are several SSs which are continuously operated tosupply necessary utilities, such as, water, electricity, liquid
helium and liquid nitrogen. Since the interaction of the
facilities with the plasma experiment is infrequent, they could
be operated independently. However, it also means that theload to the data transmission is small. The utilities can be
operated within the same frame with the plasma experiment.
This makes the whole control system uniform, and the system
becomes transparent to the operator.

C. Plasma Production
There are two distinctive modes for plasma production.
One is a pulse operation. The necessary electricity is stored ina fly-wheel generator and used in 10 seconds. The pulse canbe repeated every 5 minutes. Although the amount of thecontrol data is considerably large, they are managed before thestart of the pulse by pre-programming. In designing thecontrol system of the pulsed plasma machine, it is important toclassify much of the control data to the pre-programming
level, because they eventually determine the range ofparameters adjustable by the operator. The real-time control ofthe plasma by the operator is thus excluded from the present
design. When real-time control is truly necessary for somedevice, the function must be supported by a specific local
machine.

Monitorlr1--'-l";::;-;-;r~~~~m~m~a~n~d~--'-~~~1
11
Local
Local

Controller

.·...
'

·-~

:...

},;,:*:.. :·.'.!j~ ~-,:··
L.,.,.---,----.,,-,----,,,--~._-i· &_Wlb~,1~£!'!/llJ .-:<,

Fig.2 Flow of control data at a subsystem
experiments and (2)to help an operator, who is usuallymonitoring some number of SSs at a time, by providing properdata, warning, guidance, and various routines useful in theoperation. The centralized control of the whole system ismainly attained by a control computer(CC). Fast control for
generating a proper time sequence for different SSs or an
emergency stop due to an accident is one of the basic
functions of the centralized system. This function should not
be supported by CC but by an additional specific controller.
When we use a timer system and an interlock system for thispurpose, the configuration of the control system is displayed
as in Fig.3, where the time scale of the action is distinguishedas labeled on the right.

B. Man-Machine Interface
As shown in Fig.2, every manipulation of a device by anoperator is evaluated by the local controller, and then by CC
when it is necessary, and the actual instruction is issued to thedevice from the local controller. In a centralized system it is
not necessary for a SS to have its own console, because thecommand can be transmitted from CC. Since the information
describing a manipulation is of the order of the manual input,
the amount of transmission is never critical. Although aclassical form of a direct input at SS is not excluded, control
NffS·J,AN

Batch
NIFS

Super
Computer
Control-LAN

Intershots
Local

Controller

III. CENTRALIZED CONTROLLER

ConsoleDisplay .

DataAcquisition
and Centro

Heal
time

A. Control Computer
When every SS is designed to be a complete local system,
the role of a central controller is; ( l )to establish the total
safety, cooperation, collaboration and total efficiency of

Fig.3 Structure of the control system

S05SRN07
Status Reports: Non-Accelerators

225

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, Japanthrough the commonly-available general terminal of CC isconsidered to be the standard in the present system. Since aterminal can be used as a console for a number of SSs
simultaneously, it is preferable for an efficient operation of thewhole system by only a few operators. A number ofworkstations are used as a terminal of CC to provide a highquality services as stated in (2) above.

basically the same as the electronics. The action of theinterlock system of both levels is monitored and recorded by aspecific controller. The interlock system acts like one specificSS.

C. Synchronization and Interlock
It is a basic function in a plasma machine to assure any
SS to synchronize with the plasma production. This function
is served by a specific timer. As already discussed, the controlof the synchronization is completely pre-programmed. So thetimer can be controlled by CC in the same way as a SS which
is pre-programmable.
The other type of fast control is a safety interlock. In casesof emergency, the signal of the event must be transmitted
much faster than the normal control data. The function mustbe also excluded from a design of CC. The signal istransmitted through a specific line to the device which needs aquick response. The use of this specific line must be restricted
to the case where it is truly necessary. Since the action
interrupt the uniform control of the whole system, it causes
some vacancy of the control. A particular case will be studied
later.
The reliability is sometimes insufficient in thecircumstances with high power and high voltage. Then, a
hardwired interlock is demanded for safety. The action is

Rnole
Teralnals

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN07

D. Network in Control System
A local area network(LAN) is used to connect the SSs andCC as schematically drawn in Fig.4(control-LAN), because anestablished standard of LAN is extremely useful to connect
between different local controllers, each of which isdifferently designed from SS to SS by the person in charge. (Itis not considered here to specify the local controllingcomputers in advance.) Also, it is inexpensive and flexible inthe system configuration, and gives an easy method forelectrical isolation, when an optical bus is used. To find arequired network to LHD, the data transferred through the
network is examined. There will be about 30 SSs. Although
the amount of manipulation data is not so large, the amount of
status data is considerably large in some of SSs, say 20kB.
Considering the effective throughput, the rate of about
1OMbps is necessary. Then, the status data of 20kB
correspond to 16ms for transmission. The operation of several
such SSs at a time will be supported. Two possible standard of
LAN are investigated: Ethernet and mini-MAP.
The standard Ethernet based on CSMA/CD seems
eventually sufficient transmitting capacity for present
application, if there is no problem on a use of optical fiber forthe bus line. The adoption of Ethernet will contribute to the

hckbone·LAN

Display/ITVD....... .
... ."(Cenlrall~ed

Controller)

I He l~ork

0

"~

.

~hckupControl Co•puter

!.

Data

Prooess Ins~er•lnals

ConsolesControl·lAN..... •... ....

:s

!

'<

...;!.

."' .

!
;;

- -

.. ..-.... ... ."' :!
......" . ......... .=." "...,• ...•. :!
....
.,,•
::r

-

n

c

c
c

0

"ll

c

{II

.......... ........ .... !'.. ....s:: ...... "'.....,.. ...."' -...... z.,.
n..., ...... "' ..... .. "-- !!..... -co n .,,
:a::

c

r:'l

c

0

C>

111

0

0

c

0

::i:

:0

Control/Data
Aoqulslllon
forOlasnoallcs

Fig.4 Global configuration of the control system for LHD

S05SRN07
226

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

inexpensive construction of the centralized system. The use offiber inserted into the coaxial bus is already proved to beeffective to isolate between the divided segments. However,
the insertion is rather expensive compared with the usual coaxial connection, because it does not contribute to theimprovement of the transmission.
The mini-MAP based on token-passing seems more
appropriate for the present application. The difference of thedata to be transmitted, such as between the control commandand the status report, can be treated by a distinctive service
class in the token controller. A bus line by fiber is becoming
popular. The use of mini-MAP is attractive for the design ofthe control system. However, the adoption might be difficult
owing to the considerably high cost and some ambiguity in thestandardization.
The design of control-LAN by Ethernet is selectively
investigated.

electron due to the induced voltage in the plasma vacuum
vessel must be suppressed during the current reduction; andthe transiently induced current due to mutual coupling must
not yield an excess electromagnetic force. Therefore, gas
puffing or some hard object insertion to the plasma vacuum
vessel is applied for the induced voltage not to cause theproduction of runaway electron. Then, the power supply of thecoils is switched to the emergency reduction mode. To avoid
excess concentration of the current to a particular coil, thecurrent on every coil including what has not quenched isreduced simultaneously. To setup a proper time sequence forthose steps, the analysis of the quenching, transmission toother systems and synchronization are processed in theinterlock system. After a satisfactory response to the quench
there remains an emergency state in many facilities. The
recovery is complicated and not predictable. However, acentralized system will be very effective to support therecovery.
A power cut is a trouble common to any control.
Emergency stop of the whole sytem at the power cut is a usual
action. However, there are some facilities which must not stop
but rather be initiated in order to keep the whole system safein the present case.

As already shown in Fig.4, the man-machine(mancontroller) interface is basically connected to CC. A
manipulation of SS is received by CC and then checked inreference to the current status of the whole system. An
approved manipulation is analyzed into the command(s) to betransmitted to the concerning SS(s). The status report must becollected by CC in order to be served to the operator before he
determines a proper manipulation at the console of CC. If
once-a-second update of the status report for a few SSs isdemanded for operation of each SS, the LAN might get
choked. However, such a use of console is well processed, if
the update is demanded only every 5 seconds, which willusually be sufficient compared with the manual response. The
capacity necessary for the plasma control is not critical,
because the control is pre-programmed. The sufficient
capacity of CC will be utilized for allowing a flexible
management of the control data for the plasma pulse. An
experimental parameter, once selected and fixed for the
coming shot, can be safely modified, because the centralized
control can easily and quickly review the change. Thisfunction will be very helpful for a series of physicalexperiment
The real-time control of stationary plasma is not taken
into account in the present design. Such a control is possible
only within the ability of the CC designed as above.

IV. EMERGENCY PATICULAR TO LHD
A quench of a superconducting coil is detected by many
comprehensive monitors on the temperatures and voltages.
The signal is transmitted to the interlock system. There aremany SSs to be interrupted by the occurrence of a quench,when the quench takes place during the plasma production.
However, such an emergency stop is not sufficient in the LHD
system. There are many other requirements caused by a large
stored energy; the current on a quenched coil must be
decreased rapidly, say within 20 seconds; the induced voltage
due to fast decrease of current must not exceed the insulation
specification of the coil conductor; the production of runaway

V.SUMMARY
A conceptual design of the control system for the LHD
operation is discussed The fusion machine, with a large
superconducting coil system and still in an experimental
phase, requires an advanced'control system for a reliable andefficient operation. To achieve a labor-saving operation and tominimized human errors there, it is concluded that the control
needs a uniform structure over the entire system The CC is
designed to be devoted in the logical cooperation among SSs,
while every SS is designed to have a complete local controller
for each. The manipulation by an operator is given preferablyfrom a console connected to CC, because every manipulation
should be checked and confirmed by CC. Then, thecooperation is managed by CC before the issue of thecommands to local devices. The pre-programming for pulsed
plasma control can be fully supported by the centralized CC
system. However, an interlock system, which governs
emergency action, is necessary to assure the safety in case thatan accidental event has occurred. Thus, fast transmission of
emergency data is differently processed from the normal
control data. Then, the use of Ethernet for connection among
CC and SSs is an inexpensive choice for the present
requirement.
Since the relation between SSs must be definitely
controlled for the safety of the whole system, a completely
decentralized control is impossible. The SS is completely
designed to allow CC more centralized. The CC can be
regarded as a specific subsystem taking only the role ofcentralization.

VI. REFERENCES[I] A.liyoshi, et al., Fusion Tech. 17(1990)169.
[2] K.Yamazaki, et al., this Conference.

S05SRN07
Status Reports: Non-Accelerators

227

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

E. Centralized System/or LHD Operation

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN07

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

The SC magnet will be operated for about 10 hours per day,and the number of short-pulsed plasma operations will be
typically SO - 100 shots per day. After 3-year first-stage
experiments, the magnetic field strength is upgraded from 3
Tesla to 4 Tesla, and thousands of D-beam I D-plasma
operations are planned.

All Shut-Down

Facility Operation
Experiment
Magnet Operation
Plasma Experiment

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN08

IV. LHD CENTRAL CONTROL SYSTEMDESIGN
Based on the above-stated operation scenarios, the designed
control system is composed of central experimental control
system, and several sub-supervisory control systems such as
torus machine control, heating machine control, diagnostic
control and electric I cooling utility control systems, as shownin Fig.3. All sub-supervisory systems are connected by the
local area network (LAN).
Within the facility operation mode, basically almost all
equipments are operated by each subsystem controller. The
vacuum pumping and wall conditioning including baking andglow discharge cleanings are controlled from the main torus
control system, and each heating system is operated by eachcontroller. On the other hand, in the experiment mode, main
input parameters are controlled mainly from the engineering
workstation of the central experimental control system.
Overall system diagram of LHD control systems is given in
Fig. 4.
The details of this system design is described in the separate
paper [4].

Figure 2 LHD operation mode

Torus LAN

DlagnosllcContnl4
CAMAC------·L~CAMAC~=J:=::!__j
FW Motor Generator

Emergency Power S.
Seconclaly Cooling

TOlllS LAN

Figure 4 System diagram of LHD control.

S05SRN08
Status Reports: Non-Accelerators

229

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-S05SRN08- --lnter-lnslitute LAN

SuperComputer

lov
l1s
1..

Bo
Bo

.<l(~)
1C

¢1

Ip

LHD

PlasmaCoil Current Control

Vacuum Magnetic Field Control
Plasma Feedback Control

Figure 5 LHD plasma control concept

Diagnostics(a)

Figure 3 LHD conttol system architecture
F

V. REAL-TIME PLASMA FEEDBACK SYSTEMDESIGN

u

z
z

-

alp

I
F
I

4dlpldlc
A

According to the experimental requirements to makeflexible plasma operations, an elaborate feedback conttol
system with PIO and Fussy logic control concepts [5,6] areunder consideration.
The quantities for feedback are plasma current (Ip), plasma
position(&), plasma cross-sectional shape(K), plasma density,
heating power and so on. Especially, the fonner three variables
are conttolled by the power supplies of one-pair three-blockhelical coils (HF) and three-pair poloidal coils (OV,IS,IV).
The basic concept of the plasma feedback system is shown in
Fig.5 as a combination of the coil current feedback {IHF,IOV,
IIS, IIV), the vacuum magnetic field feedback (BO,BD, BQ, qi )and the plasma feedback. These components are related toeach other ttough the magnetic configuration matrix. A typicalsystem diagram of this scheme is shown in Figs.6 and 7(a).
Conventional PIO controllers or min-max Fuzzy logic
controllers with the center of gravity defuzzification method
are analyzed including eddy current loops of the LHD system.
The controllability of these two algorithms is compared in
Fig.7(b) for the LHD Plasma operations. The details of thisanalysis will be published somewhere.
Plasma Feedback Block(PIO,FUZZV}

VacuumMagnetic Field
Matrix

T
I
0
N

D
E

F

F

u

u

•
•

•

z
zy

•

•

z
zI
F
I

R

u
L

•

c
A

T

E

s

I

0

N

(b)

PIO
100
Ip

(k:A)

0

0

2

3

4

Tlme(s)Figure.7 Fuzzy logic control system(a) Fuzzy algorithm(b) Comparisons between PIO andFuzzy feedback responses.
Coil Current
Feedback
Power Supply

LHDMachine

Ip
Figure.6 LHD Plasma control system diagramwith PIO controller.

S05SRN08
230

Status Reports: Non-Accelerators

230

ICALEPCS1991, Tsukuba, Japan

VI. CONSTRUCTION SCHEDULE OF
CONTROL SYSTEM AND BUILDINGSThe construction of LHD device itself has been started in1991 as a 7-year project, and a first plasma operation isscheduled in 1997.
The basic design of the LHD central control system has been
carried out in 1991-1992, and the detailed design will be donein 1993-1994. The proto-type R&D system for LHD machine
operations and plasma controls is under preparation in 19911996 for the development of software. The LHD central
control system wiil be constructed in 1995-1996.
In the new site the cryogenic building was firstly
constructed in 1990 and the main LHD building is now underconstruction and will be completed in 1993. The LHD control
building will be completed in F.Y.1995, and the central
control devices will be installed there.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN08ACKNOWLEDGEMENTS
The authors thank Dr. S.Hidekuma, S.Kubo, S.Okamura,
S.Tanahashi, M.Fujiwara and engineers of Omika Works,
Hitachi, Ltd. for stimulating discussions.

REFERENCES[1] A. Iiyoshi, et al., Fusion Tech. 17(1991)169-187.
[2] O.Motojima, et al., Plasma Physics and Controlled
Nuclear Fusion Research, IAEA-CN-53/G-1-5(1990)[3] K. Yamazaki, et al., Plasma Physics and Controlled
Nuclear Fusion Research, IAEA-CN-53/C-4-11 (1990)[4] H.Kaneko, K.Yamazaki, Y.Taniguchi, this Conference.
[5] L.A.Zadeh, Infonn.Control, 8(1965)338.
[6] E.H.Mamdani, Proc.IEE,121(1974)1585-1588.

VII. SUMMARY
The design of the control system for the Large Helical
Device {LHD) system has been conducted for the flexible andreliable operations of the large experimental fusion systems.
The LHD machine and its control system will be completed in
March, 1997.

Japanese F.Y.

1990

1991

1992

1993

1994

Control System Design and R&D

CentralControl
Systemn

1995

I Control
SystemConstruction

j

1997.

1996

I

[ Control Building
Construction

LHD
PlasmaOperation

I

LHD
MachineISC Machine, Heating and Diagnostics System Construction

jLHD Building Construction

I

I

Figure 8 Construction scheduleof LHD machine andcentral control systems

S05SRN08
Status Reports: Non-Accelerators

231

231

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-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 Publishingpresent we assume the crate implementation of the frontend.

3. ARCHITECTURE

3.1 General
The discussion around the general architecture is basedon the analysis of the technical proposals of theexperimental setups and the outside experience in the field[5-8]. As a result it has been decided that all electronics canbe split in several functionally independent parts, interacting
during the operation:- data acquisition system for the hierarchical data collectionof the useful detector information,- multi-level trigger system for the event rate reduction anduseful event tagging,- technological equipment of the experimental setup, suchas high voltage, gas and power distribution, calibration andso on,- control and monitoring system, which must provide
supervision of all infrastructures of the experiment.
Such a separation with the definition of interfaces gives
the possibilities of more or less further independent
upgrading and modification of the electronics without
redesigning the whole system.
The control and monitoring system of the experimental
setup from this point of view is that frame where all theother functional subsystems are working. During theexperiment run it should provide the status information andthe remote access to all parts of the electronics. During theexperiment preparation it may be used as a setup for theelectronics debugging and testing. Due to this developmentof the control and monitoring system could be considered asa first step during the electronics design.
For better understanding of the control requirementsfor other parts of electronics some preliminary
considerationsof their structureandpossible
implementation have been made.

3.2 Data acquisition system
The architecture of the data acquisition system should
allow us to easily scale and adapt to the experimentrequirement, independent development of separate partsand further smooth upgrading. Natural parallelism of theevent data and pipeline structure for high performance
should be exploited. Proceeding from above supposition we
propose to use three functional level data acquisition
system:- front end electronic,- readout and event building,- event processing and data storage.
The internal structure of subdetectors specialized front
end electronics includes a number of basic components(analogue storage, converters, digital memory). The packingof the front end electronics depends on the technologicalpossibilities at the ·moment of the system realization. At

Possible implementation of the front end channels
readout and event building
electronics has several
directions (shared bus, dual port memories, work on SCI).
Dual port memory realization of the event building seems
the most suitable for us due to the possibilities of realizationand some experience we have. The hardware of this part ofdata acquisition is shared between front end and event
processing crates connected by the cables.
Event processing will be done by the farm ofcommercial single board computers housed in the crates.
Each node has input buffer, processor and output buffer,and processes all event data without passing them to otherprocessors.

3.3 Multi-level trigger system
Event selection will be performed in three stages (orlevels). Rough decision at the first level allow further
conversion of the event data. A more precise second level
decision tags the event for the readout. The third level
performs full event processing (as a part of dataacquisition).
Without going into details of different trigger
processors implementation it is possible to note some
control and monitoring requirements. In the case ofanalogue first level trigger processor implementation thecontrol system should provide careful calibration and has noinfluence on the processor during the operation. For thesecond level processors (mostly digital), as for the dataacquisition electronics, access to all internal registers for thetest purpose seems essential.

3.4 Technological equipment
The general infrastructure of the experimental setup
consists of several different technological subsystems. For
the control and monitoring of such equipment specificelectronics will be designed. It should give the possibilities
for the access from the control system even in case of nonstandard implementation.
4. CONTROL AND MONITORING SYSfEM

Following the above functional subsystems partitioningof the electronics, control and monitoring system may also
be divided into the control nodes. The task for this control
node is supervision of the allocated part of the electronics.
It should provide the interface to the user of this subsystemand the interface to the whole system. Each of the nodesconsists of three main parts:- local computing power,- interface to the controlled equipment,- LAN between control nodes and the system.

S05SRN09
Status Reports: Non-Accelerators

233
233

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-S05SRN09

ICALEPCS1991, Tsukuba, Japan

A local computer may be a personal computer or asingle board computer, housed in a standard crate. It keeps
all the information about allocated electronics.(tonfiguration, values of all parameters and so on). At
present two possible implementations of such a local· computer are under estimation: the AMS like crate with
18086 processor and VME crate with Motorola 68000
processor.

Kaon Factory, Vancouver, BC, Canada, July 23-28, 1990,
vol.2, sect.6, editor D.R.Gill.
[2] Yu. D. Prokoshkin, The Experiment to Study the Gluon
Interactions and Glueball Production in the Central
Region of Hadron Collisions at UNK Energies (2-3TeV), IHEP Preprint 85-32, Serpukhov, 1985.
[3] A. M. Zaitsev, Status of the MultiParticle Spectrometer(MPS) Facility, Proc. of Workshop "Physics at UNK",
Protvino, 20-24 March, 1989, p.27.
[4] V. V. Abramov et al., Study of Multimuon Events in
0.4x3.0 TeV Proton-Proton Collisions with Multimuon
Spectrometer MMS, (Proposal of experiment on UNK
collider), IHEP Preprint 90-93, Protvino, 1990.
[5] N. Ellis, S. Cittolin, L. Mapelli, Signal Processing,
Triggering and Data Acquisition, Proc. of Large Hadron
Collider Workshop, Aachen, 4-9. October 1990, CERN
90-10, ECFA 90-133, vol.1, pp.505-538, Editors:
G.Jarlskog, D.Rein.
[6] A. J. Lankford, Computing and Data Handling
Requirements for SSC and LHC Experiments,
Computing in High Energy Physics, Santa Fe, 9 April
1990.
[7] M. F. Shea et al., The DZero Downloading and Control
system, Proc. Europhysics Conference on Control
System for Experimental Physics, editor B.Kuiper,
CERN 90-08, p.84.
R. Goodwin et al., Initial Operation and Current Statusof the Fermilab DO VME-Based Hardware Control andMonitor
System,Nucl.
Instrum.
Methods
A293(1990)125.
[8] A. K. Amundsen et al., The Control System of the
OPAL Detector at LEP, Nucl. Instrum. Methods
A293(1990)145.

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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN09

Interface to the equipment is defined by the
implementation of the specific part of the electronics.
Because of the lack of any final decision made abouthousing of different parts of the electronics, only somepreliminary consideration may be fixed. We assume thecrate implementation of the electronics. Inside the crate thecontrol path may be physically separated from or joint withthe data acquisition or trigger data path. Each crate for thecontrol node is a station on the inter crate bus with themulti-register access and geographical addressing
possibilities. The controlled crates are described by uniform
table, accessible for the read/write operation.
For the communication between local nodes we plan touse commercial equipment like Ethernet or Token Ring.
Some experience of the development of such a
separated control and monitoring system has gained during
the development of the data acquisition and control system
for the Big liquid ARgon Spectrometer (BARS) of the
Tagged Neutrino Experiment (TNE) at IHEP. It consistsof:- 18086 based microcomputer housed in a CAMAC crate(analog of a control node), works under specialized
operation system,- interface to the controlled equipment, housed in a
CAMAC crate, implemented as an auxiliary controller,- star interconnection network to the main control computer(IBMPC).
The task for this control system is calibration of QDC
cards, testing of digital modules and control of the dataacquisition and triggers module during the experiment run.
In a reduced configuration such a system is used fordebugging and testing the electronics modules.
Several prototypes of special equipment for the userinterface have been developed at IHEP.
ACKNOWLEDGEMENT

The authors would like to thank Doctors A. Sytin and
V. Senko for the task definition and Yu. Simonov for the
fruitful discussion.
REFERENCES[1] A. M. T. Lin, Spectrometer Design for High Energy Spin
Physics at UNK, Proc. of a Workshop on Science at the

S05SRN09
234

Status Reports: Non-Accelerators234

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

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, Japansorting according to users requires is provided on
software level in the supervisor system.
System SW1 contains 32 scale-time digitizers
UPN-92 producing signal waveform measuring withtime step 1 nsec. Fragment of SW1 system is shownin fig.3.
System SW2 includes 32 measuring channels witha different types of real-time waveform digitizers.
Measuring step on time is from 10 nsec to 50 nsec.
Characteristics of digitizers basis types are shownin table 1.
Table 1
Characteristics of digitizers basis types

CAMACBUS
fromccinst.a ationfrom SSUNI:SUS

A.

c

D E

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN10

PCAT

Types

Bits

Time step

Steps number

UPN-928

1 nsec256

BPN-937

15 nsec

128

F-4226·

850 nsec

1024

System SG contains less expensive digital devices
for pulse general parameters measuring and includes
64 channels of pulse start time measuring, 64
channels of gated time integrals measuring and 16
channels of peak amplitudes measuring.

ETHERNETCC : crate controller
WD: we. veform diaitizer
CS: commutator
AD: adapter PC-UNIBUS

to oomputer
oenter

CE: controller ethernet
Figure 1. Typical schema of local system.

It's possible to measure ·technological parameters on
256 channels and to regulate pressure in 128 volumes.
Technological parameters slow change allows to use
CAMAC blocks commercial s~t.
Synchronization system SS organizes work of all
measuring systems in the same time scales "attached"
to installation work cycle. The set of VECTOR blocks
allows to generate starting signals at different
moments of cycle. Time scales is determined by 100
MHz frequency generator. Timeseting blocks"attachs" synchronization pulses to cycle with accuracy 2,5 nsec. With purpose of universality the system is equipped of blocks for multiplication andamplification of synchronization signals.
Fast processes measuring are produced by systems
SW1,SW2,SG. These systems contains fast analog-to-'digital converters different types and includes bothcommercial CAMAC or VECTOR blocks and special
developed devices. It's necessary to have theinformation about parameters of 200 signals in eachshot . Main installation processes have the duration
10-6-10-8 sec and contain -100 Kbyte (without video
image information). The systems architecture aredesigned according to types of devices. Signals

SD

1upervillor

SSl)'D.Ohronize.Uon

1tert of

1.iute.llaUon

wawformBWl dlptlsen

I
'I
F.
I
Ii
I\
I
'I

av v1deodljitizenSO

11tert Ume

peak amplitude•_"-"!.,.

teohnolopoal

control

Figure 2. Hardware composition.

S05SRN10
236

Status Reports: Non-Accelerators236

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Video image processing system SV is intended forreception of data arrays about load radiation image.
There are used as coding devices:- mechanical density measurement device (AMD)scanning image on photographic film (step = 5 Mkm)and transferring blacken density to digital code,- image digitizer on base of charge transfer
devices.These devices application as positional sensible detectors allows to receive information about allocation of intensity of plasma radiation in different
range of waves lengths (X-rar_ too). In. this c~se
distribution of intensity are registered without him
processing.
.
Physical diagnostics system ,SP serves of devices
complex intended for registration of load radiation(neutron, optical, X-ray and etc.) and includes
oscilloscopes different types. Highest band width is
1.5 GHz. System functions are preparatory operations(service of cameras, oscilloscopes, generation of atest signals), registration and processing of signals
fromneutronactivating analysis
detectors.
Commercial CAMAC blocks are used as control
hardware.
All pulse measurements systems contains
necessary equipment for automatic amplitude-time
calibration. Vertical deflection factors, time basesweep curves and time start reaction are determin~dand stored on disk for each digitizer. The special
electrical supple, careful shielding and grounding of
all measuring and control systems, galvanic isolation
by optic devices are used for electromagnetic
compatibility. As result, a peak-to peak noise level of
30 mV has been measured from cables located in thenoisiest region (6).

Ill.SOFTWARE.
The hardware specific and installation ANGARA-5
peculiarities have required specific software design.
All software blocks are "canned" for users. Special
menus provide users interaction with hard-software.
Main blocks of software structure is shown in fig.4.
Dispatcher program occupies the central place inthe structure. Program supports next tasks:-data reading of experiment description program(DSR), preparation them for transmission to local
systems,.
.
-definition of equipment work regime (cahbratlon,
work shot),-initialization of connection with local systems,
preparation of local systems to work,.
-start of the synchronization system, data readmg
from local systems and transmission them to database,-graphic data presentation.
.
.
Hardware adaptation to concrete experiments is
executed by means of DSR program. The programprovides:-holding and editing of installation sensors parameters,-holdhi'g and editing of synchronization channels
parameters,
description of signals transmission lines including
coefficient of signal fading in cable,-schema of registrars switching.
The information is transmitted from DSR to signals
file of data base by means of D-program in each shot.
Object specificity have required development of
the object-oriented data base DB with progra?1
interface and developing possibilities of graphic
presentation. Data base knows 3 type of object:signals, amplitudes, times. Every signal saved in DB
consist of fixed and variable parts. Fixed part contains
ancillary information about sensor type, measuring
schema etc. Variable part contains signal itself.
Length of the part depends of digitizer type. .
Manager o,f data base allows to look through data baseon different indication, to extract and edit a data.
Local systems during exploitation are the mostevolution part in respect of its composition, because
necessity in substitution of coding device type arises
constantly. That's why programs LS was built so, thatthey could be easy adapted to change of there
compositionally. Local system is divided on s~b~ys­
tems for which was built files of schemas description.
External file describes connections between
subsystems. One can make out next elements insoftware structure of local systems :-the set of system control functions,-the set of subsystems control functions,-the set of blocks control functions.

Figure 3. Fragment of SW1 system.

S05SRN10
Status Reports: Non-Accelerators

237

237

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

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-S05SRN10

tions wtttl signals including addition, subtraction,
multiplication, Fourier transform etc. The softwareinterface provides interaction of processing programsand data base.

.DB

IV. CONCLUSION.

DPThe tests of the hard- and software complex
described in this· paper have shown satisfactory
correspondence to the principal installation
performances. The insertion into hardware fast
analog-to digital convertors is necessary forinvestigation of installation processes. It's desirable
to realize the special corrective algorithms for theincreasing of the measurement accuracy. The
duration of data processing is a few minutes after
each shot. The users can observe and process data at
their working places by means of the ETHERNET.
The struc~ure of software let to adapt the complex forvarious experiments quite easy.

DSR

ST SS SP SV SG SWl SW2
local

stem

Figure 4. Software composition.

-the set of blocks contrql functions.
This elements are basis for local systems software.
Graphic package is used for subsystems description
special program. Changes of subsystems structures
are made by means of screen picture editing. Special
program transmits these changes to local systemdescription file. Documentation about a system
structure is printed at the same time.
Processing programs DP are intended forcorrection of errors arising on each element of ameasuring line (censor-cable-registrator) and forrealizing of users different algorithms. Correction
programs include of "false" points liquidation, low
and high frequency compensation. The example ofdistortion high frequency compensation arising in
cable (length is 80m) is shown in fig.5.
User programs library contains arithmetic opera-

lllHHI

1-UNCOMPENSATED
2-COMPENSATED

V. ACKNOWLEDGMENT.

The main uncommercial hardware have been designed in SNIIP. The authors are deeply indebted toProf.S.S.Kurochkin, Dr. E.I.Rechin, Dr.Ig.I.Rogushin,
Dr. Ju.A. Kruglov, Dr.G.N.Nicolaev for technicalsupport and useful discussion.
VI. REFERENCES
V.P.Smirnov, "Producing of high current electron
beams", Sov. PTE N 2, pp.7-31,1977.
[2] G.Yonas, "Fusion power with Particle Beams",Sci.Am.,
v.239, ,N 5, pp.40-51,1978.
{3) E.V.Gtabovsky et al., " • Angara-5-1" - superhighelectric power generator for investigation on inertial
thermonuclear synthesis", "BEAMS-88"- In: Proc.7-th
Int. Ccinf. on High Power Particle Beams-Karlsruhe,
EC-5, R.333,1988.
{4) Z.A.Albicov, E.P.Velichov et al., "Pulse thermonuclear
complex "Angara-5-1" ", Sov. Atomic Energy, vol.68,
part.1, pp.6-35, 1990.
(SJ S.S.Kurochkin, CAMAC-VECTOR Systems, Moscow:
ENERGOIZDAT, 1981.
(6] V.I.Zaitsev et al., "Suppression of electromagnetic
noise of pulse thermonuclear installation with power
9TW", Sov.PTE, N 4, pp.150-152, 1990.
{1)•••-tlHHJ

Figure 5. Example of high frequency compensation.

S05SRN10238

Status Reports: Non-Accelerators

238

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

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.~ configura.ticn'lbe whole system configuration is shown in Fig. 2. All· the experiment equipnent is connected to host machinethroi.Jgh t100 main interfaces: Asynchronous coommtlcation
port RS232 and GPIB pgrt.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN11.Software struature
Software system can be divided into the following
function blocks as shown in Fig,3: Input module, Filemodule, I.mage display module, Kernel· processing module
and Interface control module. The functions of each
module are described in the following:

B

Input

Kernelp·-......

Fig.3 Software function blocks

Input module
It accepts user's input and belongs to User interface
layer of manager level structure.
File module
It JllNlal!leS data files, generates or retrieves image ifiles, builds or executes repeatedly OOlllll8lld files. Itj'belongs to F\lnction layer.
Image module
It includes various technical processing such as tobuild man-machine interface windows, to display theacquired data, to form li!llQ?eriment spectrum, etc. 'lhis
layer belongs to User interface and F\lnction layers.
Kernel module
It executes user's COllllllUld and implE!lllllnts concreteFig, 2 Hardware configuration
experiment task. It is permeated into all the layers in
RS232 serial interface
Fig.1 except for Software/Hardware interface layer.
All devices of the photoelectron spectrometer andInterface control module
re.W!!-r light source are connected to the special
It belongs to Software/Hardware interface layer.
interface ll'8CA provided by VSW Co. and COlll!lllllicated with
Besides transmitting common colllllL\\nds and data, it
IBM-PC/~~] via RS232.
ESCA is an intelligent
controls the two interfaces as follows:interface• It contains CPU, RlM, RAM, converters,
ESCA Interface: Spectraneter control including to set
controllers, COlllllUllication port and other I/0 boards.
up electrons' kinetic energy for energy analyzer 1
The advantage of ESCA interface is to separate theoperation parameters, x-ray gun par8.llleters, start
software associated with hardware fran data analysis atenergy, scan range and scan step, channels, dwell timehigh level, so that users can cut out and extendof the detector for each channel and so on.
software or hardware on the basis of different demands,
GPIB Interface: Beamline control inclu:ling to set up
The photoelectron spectrometer has two kinds ofelectron energy analyzers: Angular Resolved HA50 whichparameters for each stepping motor, i;hoton initial scanenergy, scan range and scan step size, zero-scan, statusis equipped with HA5000 and HA300 controllers andAngular Integrated HA150 with HA5000 controller. 'lhedisplay, photon intensity monitor and other. analog·
systen provides Single Channel Detector (BCD) and Multi- ·signal measurement.
Channel Detector (K::D} to acquire data. According to'lbe layout of interface control is shown in Fig,4,Both INI'ERl?REl' and TmMINAL drop menu are man-machinedifferent conditions, MOD can be divided into threeinterfaces associated with interface control. INI'ERl?REl'modes: Multi Slit Mode (MSL}, pulse counting
function dictionary belongs to kernel module.
·
electronically variable slit mode (FNS} and ModulatedAuger electronically variable slit mode (Auger)l 3 J,
!1GPIB interface
All the devices concerned with beamline control,mea.suI'E!l!Jilt and data acquisition are connected via GPIB
interface. 'lbe essence of bee.mline scan is to control
four different spherical gratings and entrance/exit
slits by multi-channel stepping motor. 'lbe rotation of
the ltl'&ting and translation of the stepping motor driven
entrance and exit slits follow the Rowland Circle toassure that the bea.mline ha.s higher resolution overwhole energy range, Besides, the mass anal;rzer also
works via GPIB interface.
'lbere are four CPUs in the whole systen, 80286 in hostcomputer, Motorola 6809 in ESCA interface, 8088 instepping motor controller and CPU of multi voltmeter.
'1hese CPUs work in cooperation with each other and in
charge ·of -.in control or sub control respectively,

Fig.4 Structure of two interface control levels

S05SRN11
240

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.Data processing
Users can process experiment data off line by aseparate dat.a process software.
The methods provided
are the following: Dat.a analysis (Smoothing, Back:groundsubtraction, Peak area measurement, Addition/Subtraction& Data re-scaling), Curve fitting and spectroscopy
resolution, Deconvolution (Deconvolution by FFT or
Iteration, Spin orbit partner removal by Deconvolution,
X-ray satellite removal by deconvolution 1 OJ:rve fitting
by deconvolution)

OperatingMode
Electron Density OJ:rve with fixed photon energy
EDC
Constant Final St.ate with scanning photon energy CFS
Constant Initial State with scanning photon energy CIS
Experiment Teclmigue
Synchrotron Radiation Photoemission Spectroscopy SRPEB
Angle Resolved Photoemission Spectroscopy
ARPE5
Near F.dge X-ray Absorption Fine Structure
NEXAFS
Photoelectron Diffraction
PED
Auger Electron Spectroscopy
AES
X-Ray Photoelectron Spectroscopy
XPS
UV-Photoelectron Spectroac.opy
UPS

All sOl.ll"Ce files about 200 in number, are written in
Microsoft C 6.1 and C 6.0.
4.Software fee.tures
The system adopts the following software techniques:.Windows

Experiment Queue'J'o not'lllllize experiment course, the system provides
standard experiment queue t.able (Table 1) and experimentscan regions table (Table 2) •Table 1 shows Experiment Queue and its legal options.

All man-machine interfaces adopt advanced window
techniques. The whole user layer can be located by
keyboard and mouse. Users can input parameters, display
status or execute action by main menu, drop menu,
sul:menu, parameters input menu, cooma:nd line and cOlllllBlld
file as shown in Fig.6, Generating, overlaying, saving
and retrieving windows are implemented byreading/writing video memory directly.

.... al,yaer

7/D

!DC

11•

crs

7/n

I

CIS

7/n

XPS

,;;,

UPS

7/n

ilS

Controller
BJ.C6000
or BJ.C300
BJ.CGOOO
or BJ.C300
BJ.C6000
or BJ.C300
BJ.C6000
BJ.CllOOO
or BJ.C300
BJ.C6000

JlGtrotor

Somoe

KCD(llSL,IVS) SJI
or Scaler
KCD(IVS)SR
or Scaler
KCD(IVS)SB
or Scaler
KCD(llSL,IVS) XllAY
or Soaler
KCD(llSL.IVS) UVor Soalor
KCD(llSL,IVS, l.G.
Aupr)
or Scaler

Main Menu Bar

-

Drop
lleau

Table 1. Experiment Queue
Table 2 shows Scan Regions ( take CFS mode as an
example),-- -.. --Fig.6 Henu levels.File processing
File system has the functions of ti save ti and
crs
llod•
Aottre table Swoop•
Start Span Step Point.I UFbod Dwell"retrieve".
There are three kinds of files in thesystem.
BJ.C
6000
KCD
Detootor
The first one records experiment technique, experimentllode Pur +I- Lonr Ka, Ila Controt llod Silt.I llode Th.re1holdcondition and experiment data. It can be further
processed by a separate professional dat.a processing
SR
SoUJ'Oe
GraU..,No Photod1uor11
software.
The second kind is an image file which displays real
Table 2.
Scan Regions
time during an experiment course. It ignores experiment
Scan Regions t.able is composed of five parameterconditions but preserves image attributes (screen color,
blocks. It will display a different parameter block
image style, point coordinate ••• ), It can be turned into
according to the selected operating mode or experimentimage at any time but couldn't be processed by otherteclmique and experiment cornition (in Table 1).
data processing software.
The last one is a carmarxi file. The system can record
Experiment procedure
cOlllllBlld lines input by users and form a COllllll!lfJd file,
Users can set up parameters in the two tables above
then reserve it in order to run the experimentfor different experiments and input cooma:nd to start therepeatedly at any time.
system, then the whole experiment procedure will be run
All the three kinds of files have one thing in C<llllllOJl!
autanatically, The acquired data are real time displayed · the course of building, retrieving or executing files ison the screen, then are saved into memory, The dat.a in
implemented autaoatically, Users can input file name·memory are written to data file automatically after
when message occurs.
finishing scan for further processing later. If users.Real time displ.q and 1-ge processing
have set up several experiments, it will run to next
The acquired data are displayed on the screen inexperiment as soon as finishing the last one. In
separate (point) or continuous (line) style. The results
addition, the system provides multi regions and multi
are that a dat.a file is formed and saved to disk
scan functions to satisfy different user's needs. Users
autanatically, · The picture on the screen is a spectrum
can deal with dat.a in a special region repeatedly, so
produced in the experiment course. In order to deal withthat the ratio of signal to noise and experiment result
wave peak or for other .purposes, users can display theprecision are improved,
whole image, enlarge any part of the spectrum to full
It is convenient to build sane non-standard experimentscreen or move any part of the image to any location oftechniques at INTERPRET and TERMINAL man-machine
screen. ·or course, users can abort experiment andinterfaces.
display course at any time.

I

I

I

I

I

I

I

S05SRN11
Status Reports: Non-Accelerators

241

241

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.F.xperimlnt course

The system supports the following modes & teclmiques:

AoUYo Filo llopom Toohnlque

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S05SRN11

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-S05SRN11

I
schedule functions are at high level in .soft"Ware and· don't involve low level 'at which function.8 relative tohardware are located. So, if you want to build a newcontrol system with different hardware, just modify thefunction layer, insert Software/Hardware function layer,· which matches new devices into the system. A new control
and data acquisition system with different f'lmctions butof the same style will be cniated. We have designed anddeveloped a new system for a photochemistry station at
HESYRL with the lilalDe structure and have made a great
success in this field.

.Prot.ection measures.
To avoid abnormal phenomena caused by mis-setting
parameters and COllllllU'lds or unreasonable steps during anexperiment course, some protection measures are adopted.
'lbe protection measures are as follows:
Protecting against mis-setting parameters
If users set incorrect parameters because of being new
to the instrllrlent, the SJStem will match hardware set
and correct it, so that the hardware can be well
protected.
Lona jump from error sites
Ei:Tor sites, such as device error or device not ready,mismatch of experiment technique and experimentcondition will make machine dead and abort experiments.
In that case,apart from displaying various warning
messages in time, the system can save sites and stackenvircrlment at 8rl)" position Where errors may occur. Whenan error is detected, the system restores stackenvironment and jumps back to the original site.

Ad!.nowledpient
The authors gratefully acknowledge Mr. W. J, Ellwordof VSW Co, U.K. who wrote the original .commercial
software for his helpful advice on general design andsoftware technique. '1he thanks will be also extended to
Ms. Jin Liu of IHEP for her part in work on motor
control, Mr. P. Xu and J, Li of HESYRL for theirinformation about concrete experiment demand ••Data structure
Among source files, all variables and data structures

such as pointer, dimension, structure, union,
en1.1111eration, table, chain, tree are used alternately andflexibly, Thus, source files not only have good. readability 1 but also support the modular design for thewhole software system. For example, INTllRPRET drop menu,
one of the man-machine interfaces, accepts Fmlti stylecolllllland and parameters and matches professional·
dictionary to control .devices connected to ll.SCA and GPIB
interfaces. '1he data structure relative to this pa.rt is: a table, F.a.c:h table item is a structure, whose structure. ~ are cauposed of cama:nd names and corresponding·function pointers •. References[ 1] • Yunwu Zbaiig

Construction of Beamlines and Elcperimental stations at
HESYRLOn Proceedings of the International Conference on

Synchrotron Radiation Applications.
May 1989

P305[2], VSW Scientific Instruments LTD.E5CA Interface Unit Hardware, p4-7
[ 3] • VSW Scientific Instruments LTD.E5CA Interface Software Manual, 1989•!b!l.tlarization design
In spite of the soft"Ware system composed of about 200
source files, the structure is succinct and wellreadable. '1he method is to concentrate the functions
which implement a certsin kind of function, construct·one or a few source files and form independent function
modules. 'lhe external interfaces of such modules areminimized and the implementation details for othermodules are transparent. For example, the window JOOdule
includes· all the necessa.cy functions. When you would
like to make a window, you just call the interfacefunction of window module and pass attributes such aslength, width, coordinate, color, title label, without
considering implementation details such as video mode,
window overlay, the location of video memory etc. 'lbe
same principle is adopted in real time display, filesystem, exciting source control, analog signal measureand SR experiment modules ••Portability
AlthDugh the control & data a.oquisition system has
professional experiment techniques and was designed
specially as a synchrotron radiation photoelectron
spectroscow experiment station, it can be referred toin other control & data acquisition systems.
Especially, the structure parts of the software such as
experiment course, image real-time display, data file
generation, interface control levels and strict
protection are important elements in a large data'acquisition system, 'lhe system can be applied to other·conditions if modified sanehow according tc hardware
configuration and experiment demands.
Modularization structure and flexible data structurein ·software improve portability of programs, Users cancut out or extend the original software in the light ofdifferent demands. Most function modules can be
1Jeparated to insert other software systems. Thus,
progJ.'tillllllin work is reduced and efficiency incree.sed,
Portability is shown in the Software/Hardwareinterface layer too. This is because the analysis

S05SRN11
242

Status Reports: Non-Accelerators
242

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

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, Japantransparent to the application programmer. The cachedinformation exists for the life of the program run. The
database is updated so infrequently that stale cached data is not
a problem.

These windows may be moved or resized by the user and/or
under the control of the application program. Routines werealso created to make it simple for existing nonwindowed
applications to make use of the new windowed routines. In
the future this transition may be made seamless by modifying
the underlying 1/0 routines.

The programmer and end user can peek at the dataacquisition activity through an application that polls embedded
statistics modules in the data acquisition routines. This peeker
program runs on the console concurrently with the program tobe analyzed. The peeker will display counts of function callsand errors. It will also show the number of devices and lists ofdevices being read and set as well as the frequency of retrievals.
Additionally, timing statistics are shown for the data accesses
being performed.

IV. FILE MANAGEMENT
There is a large group of applications that use shared
read/write access files. A set of routines was created to help
the programmer manage opening, reading, writing, and closing
files in a simple, convenient fashion. As with the dataacquisition routines, file operations were simplified by
reducing the number of function calls required to accomplish
them. A file peeker program was written that is similar to thedata acquisition peeker. It displays numbers of function callsand errors. It also displays which file and record was last readand last written and any error associated with the access. In
addition, timing information is displayed for communications
with the central file server process.

V. SCREEN MANAGEMENTThe VAX console environment provides three X windows
for each application program. These windows are managed by
two manager processes that perform all the direct X protocol.
This was done for compatibility with existing applications.
The main window permits only character cell access. The
other two windows allow pixel addressing and are usedprimarily for plotting. Screen management facilities werecreated for each of these types of windows.

The previous interface routines for the alphanumericwindow provided little in the way of managing subwindows.
There were window create and delete routines which simply
saved and restored blocks of text on the screen. Anything
beyond that was handled directly by the application program.
This led to crowded and confusing displays and a myriad ofuser interfaces as programmers grappled with the problem ofdisplaying a great deal of information in a limited space.
The new routines support input and output to multiple
tiled or overlapping windows. Input and output is clipped to
the window being addressed. In the case of overlapping
windows, text written to an occluded character cell is saved andis refreshed when and if that character cell becomes exposed.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA01

Support of windows with vertical scrolling capability wasprovided to release the application programmer from the limitsof the size of the alphanumeric window. Routines exist to
create and manage a scroll bar and draggable indicator requiring
no support code from the application program. Lines scrolled
out of a window are buffered, freeing the application fromneeding to remember scrolled text.
In addition to the basic window support, higher level screen
management tools have been added. Menu and menu bar
routines, numeric and textual input dialog boxes, logicaldialogs, and message windows have been provided. There arealso utilities to create and manage logical switches as well as
to handle highlighting of text regions.

Since the pixel addressable windows are used primarily forplotting, a suite of plotting interface routines were created.
The routines allow the programmer to define a plotting
window in terms of fractions of the background window. Afterthe region is defined, the scaling function and scaling limits
can be selected for both axes. Plot labelling and plotting
attributes can also be defined. An application program wasalso created to allow the user to enter window definition
parameters and view the resultant window interactively. Oncethe desired window is constructed, the program can be
instructed to generate the source code to create the plot window
displayed. Additional routines have also been created to saveplotted data and then to perform statistical and fitting
operations on the saved data.

VI. PROGRAM TAPE RECORDING
One of the primary applications which had to be created forthe operation of the Collider was the Colliding Beams
Sequencer. This program carries out all of the steps to load
the Collider with particles and bring them into collision.
Some of these steps are simple and are contained within thesequencer, but some are more complicated and require thesequencer to invoke other application programs to perform thetask. Modification of applications to run under sequencer
control in the past has often been complicated and time
consuming. It was felt that a more flexible means was needed
for running programs under the control of another program. It
was also important to have a method which would allow foreasy modification. The facility implemented was a software
tape recording system. A user enters the desired program in a
special recording mode and then proceeds to perform the desiredtask manually. All the steps are recorded automatically in afile and are assigned a unique file name. The file can then be

S06SA01
244

System Architectureniggered by the sequencer (or the application itself), and theapplication program will perform the same steps originallycarried out by the operator.

VII. ERROR HANDLING/LOOGING
Checking and reporting error conditions is one of the mostimportant needs for application programs used for accelerator
control. Operators need to know if settings and readings ofdevices are successful. In addition, it is useful to be able toreconstruct events that have occurred. The error handlingroutines check error codes, expand them to give text
descriptions, and save errors encountered during execution of
the program. Logging to circular log files can be done
automatically by the error display functions. A program user
can examine the log history in a scrollable window with manydifferent text filter and search modes. The programmer canchoose to incorporate a separate log for each instance of the
program or a single log so that all ·uses of a program areshown in one log. Separate programs working together canalso share a single log with time-ordered entries maintained by
the logging utility.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA01

X. CONCLUSIONS

The results of recent accelerator studies indicate that the
CBS approach has been successful thus far. The sequencer,
orbit smoothing program, and the Tevauon ramp calculationand loading programs have been used successfully and havebeen well received by the user community. The consistency inuser interfaces has allowed users to learn to use thesecomplicated programs in a short period of time. In addition,
programs have been developed using the CBS tools to create
other applications not directly related to collider operation.
Inexperienced programmers have b_een able to constructinvolved applications not only successfully, but also in shortperiods of time. The Collider applications have also been able
to be extensively modified in response to user needs in a shortperiod of time with little debugging.
The work continues on this project. There are many more
topics to be addressed such as better handling of the dataassociated with the accelerator clock system and complicatedtable devices as well as context sensitive help. Ultimately, thegoal is to bring all of this under the umbrella of a resource
editor or code generation system to allow for even more rapid
and error-free creation of accelerator applications.

VIll. INTERPROORAM COMMUNICATIONXI. REFERENCES
To support the CBS utilities peeking activities and theColliding Beam Sequencer communication, a set ofinterprogram communication routines were created. These use
VMS mailboxes to allow queues of AST deliverable messages
between indpendent processes. One simply creates a mailbox
with an optional AST address and then sends or receives
messages from that box. Programmers can now create
program suites that can work independently or communicate
directly with each other. The program used to smooth theTevatron orbit will, if needing a lattice, start a program togenerate the lattice. In turn it can then poll for the results.
This allows large amounts of data to flow between cooperating
programs at a high rate.

[l] Cahill, K.J. and Smedinghoff, J.G. (1989). Converting the
Fermilab Accelerator Control Consoles to X-Window
Workstations, Proceedings of the International Conferenceon Accelerator and Large Experimental Physics Control
Systems, pp. 442-445[2] Cahill, K.J. and Smedinghoff, J.G. (1991). Exploiting lhe XWindow Environment to Expand the Number, Reach, andUsefulness of Fermilab Accelerator Control Consoles, lhese
proceedings

JX. UTILITIESOne of the CBS tools that demonstrates the integration of
all the utilities is the Utilities Window. Through a menu
driven interface the user can make screen copies, start plotting
packages, invoke log displays and set timeouts for dataacquisition and file accesses. The user can also interact withthe error reporting buffer by clearing or viewing pastmessages. A window that allows display, reading and settingof accelerator parameters is also available. This parameter
window is customized by the user for use with a particular
program.

S06SA01
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

245

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

local area networks and the VAX cluster toEthernet. Ethemet-UTI-NET gateways have been
installed to allow communications between thetwo different networks.

The display program is driven by a graphicaldatabase derived from the slow control one using·
the ALEPH graphics package [1].
2.2 The DELPHI Slow Control (2)5) A large relational database describing thecorrespondence between the physical detector andthe slow control system has been implemented on
the VAX™ cluster. It is used extensively by theserver to translate requests coming from theapplication programs given in terms of thedetector high level commands into commands
which will be understood by the microprocessor
programs (low-level commands). The connectivity
and the essential elements of the slow control
systems are illustrated in figure t.
The gateway software is written in C and runs on
a Motorola 68010™ processor under the 05-9
operating system. Its role is to synchronize thetransfer of messages between the two data
networks which have very different physicalcharacteristics. The program is loaded on
resetting the system from files residing on the.. VAX™ cluster Network disk.
The central element of the ALEPH slow control
system, as indicated before is a relational
database which describes all the aspects of thesystem. It is one sub-section of the online databasewhich also contains the descriptions of the
Fastbus system and the readout configuration. The
entity-relationship model is used in the design of
all the databases [1]. In such databases, elements
in a system are represented by tables. A
particular instance of an element occupies a row ina table and each attribute which describes theelements occupies a column. Furthermore, thedescription of each element may be supplemented
by specifying its relationship with other tablesin the database or in other databases. The
advantage of this type of structure is to avoid theneed of repeating information unnecessarily andthus to reduce the possibility of conflicting entries
and enhancing the data integrity. Entityrelationship diagrams have been used during thedesign phase of the database and provide aconvenient means of displaying the databasestructure.
A graphic status color display showing thecurrent status of the system i~ running on a colour
workstation in the VAX™ cluster. In addition it
allows inconsistencies in the database to be
spotted more easily. The display has been madeinteractive and layered to cope with the large
amount of informations involved.

The DELPHI slow control system is composed ofthree major logical components. The G-64
microprocessor systems, very similar to the one of
ALEPH, provide the interface to the hardware to
be controlled or monitored. The intermediate levelsoftware running on microV AXes and VAX™
stations, called the equipment computers, whichhandles all the low level processors belonging to asingle detector. And finally the high level software
which performs the overall control is running on thecentral control computers (VAX™8700 and
VAX™4000).
1) The G-64 Systems

Each system is equipped with a Motorola 6809™
processor, RAM/ROM memory and conunercial cards
like ADCs, DACs and HV controllers. The
communication with the intermediate layer isperformed by a G-64-cheapernet interface board
which has been developed at CERN. The mainfunctions of the standardized software running inthese systems are the following: at startup, thesoftware sets the value of all physical channels topreselected ones which are stored in the VAX™
and downloaded to the G-64. During normal running
operation, it monitors the values of all the channels
in a tight program loop and reports the significant
anomalies and the alarms to the program running inthe VA)(TM equipment computer. Also during normal
operation it receives and carries out instructions
coming from the equipment computer like, ramping
up or down the high voltage of a given device.
2) VAX equipment computer software
The software running in each sub-detector equipment
computer handles all the aspects of the communication between the G-64 layer and the master central layer. It receives actions from the top layer anddistributes them to the interested G-64 system. It
also collects all the alarm messages and anomalies
from the bottom layers and forwards them to the
top layer. Finally it updates the central DELPHI
database with the values of the parameters andtheir status. At startup this program also performs
the downloading of the preset conditions of eachparameters from the database to the G-64 targets.
Standard software has been developed by DELPHI
to perform these functions. Its form was determinedby the choice of the automated control system based
S06SA02

System Architecture

247

247

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 DOIICALEPS'91 KEK, TSUKUBA November 11 - 15
3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991-S06SA02

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 DOIICALEPS'91 KEK, TSUKUBA November 11 - 15

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

ICALEPCS1991, Tsukuba, Japanon a CERN package called the State Management
Interface (SMI) of the Model software [3].

3) The central Slow Control Layer

3) Central Control and Interfacing SoftwareThis layer also uses the SMI package but applied
at a higher hierarchical level than before. This
SMI single program interacts with all thedifferent sub-detector control systems. No fortranprocesses are involved. A central operator's
display allows the overall state of theexperiment to be viewed from a VAX™ station
3100 using the MotifTM Graphics system. On thebasis of the information displayed the operator
can decide to start or to stop the run. The messages
generated by the sub-detector control systems arealso displayed on this graphic interface. A
general view of the system is presented in figure
2.
2.3 The L-3 Slow Control [3]The L-3 system is also modular and is composed offour different layers (fig. 3), each of them
performing very distinct functions:1) The BBL3 Layer
This a non-computer controlled hardwired layer
dedicated to the high level alarms whose
consequences would be of major importance for theexperiment if the necessary actions were not taken
on time. Each of these hardware box offers amaximum of 48 isolated inputs and 32 outputs
specially designed to perform important actions
as to power off a control room or a piece ofequipment which is not operating well. A
manually programmable matrix allows any input
combination to perform any number of distributed
actions. The all system is being independently
read out by the computer of the detector whichowns the box and by the second layer of the slow
control system described after.
2) The local Slow Control Layer
This is a typical local control system which reads
out the parameters of a given piece of hardware,
performs a local analysis of its behavior, reports
to the central layer for alarms or new data andtakes local actions which are within its range.
Depending on the equipment this software is
running either on a VAX™ computer or on a
dedicated PC or a VME 05-9 system. It has been
designed to be as little equipment dependent as
possible and is reasonably data driven.
S06SA02248

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA02

For safety reasons, this very important layer isrunning on a standalone microVAX™3200. It houses
the database which describes all the parameters
the L-3 slow control is responsible for. Its mainfunctions are to collect from the network all theinformations related to all the equipments likealarms or digital monitoring data blocks. Afterevery update of the shared memory which holds
the present status of the experiment, an expert
system is triggered to analyse the situation. It takes
actions when necessary. These actions will bebroadcasted to the lower level computers where
they will be physically executed. In case of time out
due to network problems or to other reasons theexpert system may take higher level actions if it
has been foreseen in the database. Otherwise, theserious situation in which the system is, will be
immediately reported to the operator. In case of
hardware alarms where the actions are taken
independently of the software, the system willreport the new status of the equipment of concern
and will not proceed any further. At each
modification of the content of the shared memory, a
trace of what happened is written on a daily file. It
will also appear to the operator as a structured
message which has been preprocessed from theinformation contained in the database. A graphic
display system running on various Macintosh™
computers located in the main control room and invarious places at CERN will immediately be
informed of any changes.
4) The Color Graphic Display System (4)This sophisticated graphic display has been entirely written in Object Oriented C making use of the
THINK QM library of the SYMANTEC company. It
allows an operator to view the status of the entire
experiment just by clicking into sensitive boxes
whose colour represents the worse status of all theparameters or windows they give access to. The allwindow tree mechanism is housed in the databaseof the third layer as well as the description andlocation of all the parameters to be displayed. At
startup the application inquires to the central slow
control the date and time of the last modificationsin the database. If they differ from the ones
corresponding to its local copy, it will request an
update over the network. It will then build theapplication objects from these new static data. It is
important to mention that this graphic system isentirely data driven and does not need any
maintenance. The application software is itself
available on a Macintosh™ server if needed anddoes not have to be resident in the macintosh™.
248

System ArchitectureICALEPS'91 KEK, TSUKUBA November 11 - 15
3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

2.4 The OPAL Slow Control [4]3) Applications

Unlike the three other systems, the OP AL slow
control system is not a layered hardware system.
A series of VME OS-9 creates all connected via
Ethernet constitutes the backbone of the system.
Each of them is dedicated to various tasks
regarding a part of the experiment. A
Macintosh™ using the Hypercard™ software of
the Apple Company is directly connected to the
VMEBus and allows a local graphic display ofthe parameters under the control of a given crate.
The software which performs these tasks isorganized in three layers presented in figure 4 anddescribed below.

An important consequence of this clean separation
into three layers is that the same application
programs can run in both stand-alone mode (e.g., fordebugging) and in an integrated mode with theentire system. They can be written in any language.
The application programs are also supervised by
SC_PROC, which starts and stops them on request.
A typical example is the program which reads the
ADC of common controls. This program is driven bya table which gives the characteristics ofindividual channels such as their description,
warning and alarms limits, actions to take, etc. It
compares all parameters with their nominal values
every 5 seconds. Asynchronously, it also accepts
commands to show the status, change default
values, disable actions, etc.

There is a variety of possible interactions withthe control system, such as sending a command andretrieving an answer message. A comprehensive
and powerful human interface to handle thewhole OP AL detector has been implemented on an
Apple Macintosh™llx, using the Hypercard™
tool. It uses graphics to interact with theoperator. SC_MENU is an alphanumeric menudriven interface which runs on a terminal. Run
control is a dedicated data acquisition program,
while SC_ALARM displays warnings and alarms
for the whole system. Any computer on the
network can be used as a sending or receiving node;
however, a clear separation is made between"harmless" commands (e.g. to get a status) andactions on the detector. The later are normally notenable from remote sources.
2) Skeleton
At boot time, SC_PROC starts all the programs inlayer 2 and supervises them. They are all written
in C language. Commands are sent to the program
SC_FILTER, which checks their validity, writes
them in a log-file if required and passes them tothe appropriate application in layer 3. This
program executes the command and may themsend an answer message back to SC_ROUTER
which has already been notified where theanswer should be sent to and which passes it on.
Unsolicited output of the application programs,
such as errors, is accepted by SC_ERROR, whichlogs it in a file and, if required, passes it on.
Automatic corrective actions are handled in thesame way and sent to SC_FILTER.

3. Main characteristics of the 4 systems
Due to the large number of parameters to becontrolled and their wide distribution, the 4 slow
controls have adopted the layered and distributed
system principle. For the same reasons dedicatedand unspecialized slow control programs have been
written to reduce redundancy in the code. In mostcases special efforts have been made on the design
to provide systems as close as possible to an ideal
data driven slow control. But unfortunately, in mostcases it has not been possible to achieve this goal
all the way down to the lowest control layers. The
importance of databases in such systems have beenclearly understood and will be the key part of futureslow control systems. These four systems have beenrunning since the LEP collider started in July 1989
and are expected to operate until late in the decade.
In the four cases major upgrades of the hardware of
the detectors in the experiments are expected. These
will force every slow control system to follow up
closely. But due to the limitations of some of thesoftware and hardware, and also due to the lack ofmodern software engineering tools when thesesystems have been created, it is to be anticipatedthat major maintenance efforts will have to be done.
4. A possible Generic Control System

To satisfy fully the data driven constraints, such asystem should entirely be based on large relational
databases where tools like CASE tools and entity
relationship models would insure a full coherency
between the different tables.

S06SA02
System Architecture

249

249

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

1) Human Interface

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA02

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 DOIICALEPS'91 KEK, TSUKUBA November 11 - 15
3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

As illustrated in figure 5, a set of external
software engineering tools like a Configuration
Manager and a Coherency Manager could be
implemented to help the user to perform thedesign and the upgrades of his slow control system
by following strict and formalized rules.
Furthermore, with no extra efforts an up to dateformatted documentation would be readily
available. The data blocks and their definition
would then be extracted from the database anddistributed over the network to the target
computers where the necessary updates would beaccomplished. At every level of the system, tools
would be provided to allow an automatic
implementation of the newly received data
blocks. An acknowledgement mechanism inrelation with the Configuration Manager would
also have to be designed. to reduce the systeminstability during these transition phases.

4) The communication layer

The internal organization of the database andthe corresponding software layers are presented
in figure 6. Five main layers can be identified.
1) The Local Acquisition and Command Layer
This layer is dedicated to perform the typicaland basic operations of any local control systems.
Namely, read the data from the hardware,interprete them according to the local Acquisition
and Command database content and take theactions which could be requested by the
Hardware Control layer.
2) The Hardware Control Interface.
This layer takes locally the decisions which arenecessary to keep the lowest layer in operationaccording to the Hardware Control database, fortrivial decisions, and to the Software Control
laye_r for more complicated ones.
3) The Software Control Interface
All the actions which can be internally taken andwhich are independent of the other control
systems will be handled at this level.
Furthermore this level is responsible for thesynchronization between the communication level
and the three bottom layers during the updates ofthe system.
These three layers are completely autonomousand can perform a full local control of a piece ofequipment in a stand alone mode. A optional
expert system could very well be included in thethird layer when needed by the designer.
S06SA02250

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA02

All the data and alarm transfers to the central
control system is taken care by this layer. It is also
responsible for the temporary storage of the newdata blocks issued by the database until the full
update mechanism has been completed.
·
5) The Central Control Layer
This layer holds a copy of the values of all theparameters controlled by the experiment. It will
forward the actions requested by the operator to all
the sub-systems involved and later report for successor failure. No actions issued at this level will takeeffect at the level of a local system, if if has notpreviou~ly been implemented in its Software
Control Interface layer. Since this can only be doneby the person in charge of the equipment, this avoid
spurious and not commissioned actions to take place.
A distributed color graphic system will display
either the global status of the experiment or the
local status of a piece of equipment by interrogating
the central control Layer. The same format andphilosophy should be provided for both local andglobal displays. The upgrades of this system should
be handled through the configuration manager.
5. Conclusions

In this paper, it is not possible to go into moredetails into the organization of this genericsystems. But we believe that with the support ofindustrial software products like CASE tools andothers it would be possible to provide the slow
control designers with a set of tools which could
help them greatly in the setup and maintenance of
their systems all along the years of operation.
References[1] The ALEPH Slow Control System, S. Wheeler etal., ALEPH 90-67 DATAACQ 90-08.
[21 The DELPHI Slow Control System, R. Sekulin atal., DELPHI Internal Note.
[31 The L-3 Slow Control System, J.M. Le Goff et al.
Paper presented at the Conference on Software· Engineering Artificial Intelligence applications in. High Energy Physics, LYON March 1989.
[41 The ARGUS graphic system, J.M. Le Goff et al.
Paper presented at the CHEP91 conference,
TSUKUBA March 1991.
[5] The Control system of the OPAL detector at LEP
A.K. Amundsen et al. NIM A293(1990)145-147.
250

System Architecture

E1illm.J.: The ALEPH SLOW CONTROL ARCHITECTURE
3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ISBN: 978-3-95450-254-7
ISSN: 2226-0358

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

OC.ON - - - - - .

THE ALEPHSLOW CONfROL
ARCHITECTURE

DC OFF----.

AC. INHIBIT+---...

F.qUipment

MAC-64
StatiO'I

Ull-NET/'---:::;po~......,-.---'I

Miucp™
System:\k:..'·'MAC-64.

:::~::·!} Staticn· ·VA.'<
System-Operator
Display

Canmanic:it::iai mechanism

Broadcast to selecteduser terminals

Expert's
Display

Database

MicroVAX
EqtJipment
ComputerCalibration
Database

G64 systems
accessed via
elhernet

CAEN HV
Controller

temperature sensors,
switches etc •.

.El.§.:i: DELPHI SLOW CONTROLS SYSTEM

251
System Architecture

S06SA02
251

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-S06SA02

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

l3 SLOW CONTROL

La~r I:

U.urum lacerface

HARDWARE AND SOFTWARE LAYERS

MAC U X Console

MACllX(REMOTE)..J~......

OBJiCT 01111!11'110 C

MACITCP

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA02

MACllX(P)(REMOTE)•••••••• Spy Dala Display

Dala, Dlaplly,

I

I

Main dlagnoela!

··.. eI!

lpVAX3200

VMS, ORACLEI· EXPERT SYSTEMSLOW CONTROL KERNEL
Central system
50Z4 parameters hanl r. soil origin

I

24 Mb RAM, 3 lC 159 Mb of hard Dlslc

I

I

YME/orl YAXH

Jffl....

YMEOS9Cl ASSEMBLY

SLOW CONTROL
Harllwllre
READOUT SYSTEMSI.
~I
VME tor I VAXH

.J!!L. ,OETECTOR "N"______,,'Data Talolng
Sp!O!m•1•

Y1'!1'l:Skrlrlon.•'"'"' ,~,.t"',,{::-:,"","'';*

La1er.J:.,"

Applicaliom

I

I
I

!
BBL3 HARDWARE
15 x 48 Hmfware Input
1S lC 32 Herdwete AcUoM

I
I

fl.aum...!l: The OPAL SLOW CON'IROL SOFrWARE LAYERS

S06SA02
252

System Architecture

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

..

> ...

"c.,,
t: "
"' c

..<: ..

~:;:

Ne,.. Dol:i llloclcs
tnul

IJl:;lrihulcd o•cr v.:11iu11~ ·pfolfnrms ,ind syr.lcms

Deflnllion'
Targcl An

J\ SLOW CONT!lOL l'OSSJIJLE
CONCEl'TU/\L DESIGN· Duwnlnoili:dt:>411110 the lari:cl <.:ompulcr

1011 ';". llala Driven
So(hvarc Eni;inccring Conccpl5 lmplcmcnlr.I
J.111.l.ll CitlfF I CEllN·ECr

f'.iIDJ.U:_l: 111c GENERIC CONTROL OffLINli Configuration

The 5 Typical SOVJ'WAHg LA YEHS or :m
INTEGRATED CONTHOL SYSTEl\·1
Fjgyre 6:····--·-····i···-··INH:RLOc:IC(llAHIJ\\'A llf:J

l.OCA I. cm-;·1 l\Ul
CO~ll'UTERCEX: ill UOl\~l

It. HAlm.1.1:1u·: ECl'/l'r

J:\I. L~: C:OFF F;CJ'/l'T<.:o"' 1•1rrr::n!]·:X: MA<:Nl·:T

II. 11111.C.:l:N"r l'l'l:Ji\llr
IUiTM•ll'Ff,I r:<:l'/l'T

S06SA02
System Architecture

253

253

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-S06SA02

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

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

ICALEPCS1991, Tsukuba, Japanthe Proton Synchrotron Division at CERN [I], did develop,
and continues today.
2. Throughout the design and implementation of the alarmsystem, close collaboration was maintained with the groupresponsible for the safety system in the experimental woes,
namely the General Surveillance System (GSS) [2]. Bothsystem designs were exposed to the conventional approach,but early on in the GSS project, an ES shell developed at theElectricite de France, called Genesia [3], was evaluated andfinally used. The alarm team decided against its use for thefollowing reasons: original lack of portability, lack of internal
control of inferencing, limited interface to the outside world,
constraints on the use of variables, rule set generation timevery long and no temporal reasoning facilities. One conclusionof this work was the realisation that such an approachencouraged the use of 'rules' to define logical relationships butthat the maintenance of a large interrelated rule set is by nomeans trivial.
3. The environment in which the alarm system had to run was
also a strong influencing factor. At the equipment level,
equipment groups built their own ECA's containing different
processors and operating systems. This included the 4 GSS
systems, which for connection purposes were considered as
ECA's. UNIX was chosen as the operating system for thecontrol system with 'C' the programming language. To-datevarious elements of the alarm system run on 5 different
platforms covering 2 operating systems including 4 flavours
of UNIX.
4. The LEP machine falls under the jurisdiction of the Frenchauthorities which consider accelerators as nuclear installations.
They must confonn to strict safety regulations with respect tosafety of personnel and particularly to radiation exposure. This
meant that the design of the alarm system had to provide thenecessary features required by these regulations, including
formal FS definitions for safety, redundant FS transmission
paths and the use of a fail-safe power supply network.

local networks that the third level of processing exists in theform of consoles for control and the display of FS
information.

IV. FAULT STATE CHARACTERISTICS
A FS has been defined as something wrong with theprocess. It is described as a triplet: Fault Family (FF); Fault
Member (FM); and Fault Code {FC). The FF is a collection ofsimilar parts of the process, exhibiting similar FS's. A FM of
this FF is an instance of one of these parts of the process. The
FC describes the problem. For a perfect FF, all FC's will
apply to all FM's of that FF. As an example, in the services
environment consider the fire detection system. All fire
detectors are grouped under the FF 'FIRE_ZONE'. The FM
defines uniquely each fire detector or circuit The FC descn'bes
the problem: smoke-detected alarm level; smoke-detected
warning level; detector under maintenance; detector out ofservice; and detector fault For the machine, consider the power
converters. They are all grouped under the FF'POWER_CONVERTERS'. The FM is the name of eachindividual power converter and the FC descn'bes the problem:
faulty; timing error; local mains variation; tune loop control
enor, ECA system reset: spike deaet:ted; etc ..
Although this triplet definition defines the FS uniquely, it
is not sufficient for alarm management or operators receiving
these FS's. For this reason a 14 field, character string wasformally defined. The first 7 fields are obligatory and consistof the following: a string version number; the triplet; a flag
indicating whether the FS has just become active, or that it
has now terminated; description of the problem: and a priority
indicating severity. The remaining optional fields enable a user
to define more precisely the FS. A formal name was given tothis string namely: User Ascii Version 1 (UAVI), which isused to describe FS's in ECA's , PCA's and any othercomputer performing surveillance.
An important aspect of a FS is time. A FS is considered to
be 'active' during the time it has a status 'true'. Such a statehas 2 times associated with it: the time at which it became
active; and the time it terminated. During the interval between
it is referred to as an Active Fault (AF) and is added to a list
containing all AFs, this list being called the Active List
(AL). An AL is maintained at each level of the alarm software.
It represents the ClJllent state of the process as surveyed by thatsoftware level.
Not all temporal aspects of problems are covered by theconcept of an AF, since there are very important 'events'
which take place at an instance of time, and thereafter have nofurther meaning. Examples of these are: an ECA
microprocessor 'resetting'; a spark in an electrostatic separator,
and a software task 'timing out'. These situations are treateddifferently by the system. They are descn'bed as 'Instant Faults'
and have a corresponding identification flag in the UA V 1
string. Since they only have 1 time stamp associated withthem, they cannot be part of an AL. Instead they are passed
through the system and finally offered for display.

S06SA03
System Architecture

255

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

ill. CONTROL SYSTEM ARCHITECTURE
The control system [4] is based on 3 levels of processing.
At the lowest level are the ECA's of the equipment groups.
They are connected to the next level using the MIL-1553-B
multidrop bus. The controls group is responsible for theinterface between the ECA's and this level, including: thehardware and software interface; a command/response protocol
for control; a local name server, and an alarm channel for
passing alarm information. The intermediate level consists of
Personnel Computers (PC's), 386 machines, known as
Process Control Assemblies (PCA's). These act asconcentrators of processing power both for equipment control
and alann handling. There may be up to 10 such machines at
one LEP site. Each machine is either connected to a local
Ethernet segment and then a Token Ring (TR) (IEEE 802.5)
or directly to a TR which in tum connects to a Time Division
Multiplexer (TOM) (CCIIT-G700) system for long distancetransmission. The TDM connects the various PCA's to local
TR networks in the different control centres. It is on these

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA03

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

database, the LLAS directs the FS to its corresponding SSP at
the SP level.

V. HIERARCHICAL S'IRUCTURE OF THE ALARM
SYSTEM
LEP has 8 access points distributed equally around its
circumference. These areas are used for personnel access,concentration of general services, and points of localisation forthe control system; in addition the even points house the 4underground experiments. Control centres for LEP are
distributed widely over the CERN site, with the machine
control room situated on the Prevessin Site, and the Technicaland Safety Control Room (SCR) situated on the Meyrin Site,
some 3km away.
This geographical layout lent itself to a hierarchical alarmsystem approach both in tenns of hardware and software. At
the lowest level, ECA's provide either FS or status
information to the PCA's; the 4 GSS systems of theexperimental zones mirrors this behaviour. Included at the
PCA level are computers responsible for the surveillance ofsystems, not connected to ECA's. This layer then passes the
FS's to the CAS, where they are centralised and grouped
according to operators' areas of interest, such as machine
operation, safety etc.. Finally, if a console has been initialised
to receive one or more of these FS areas of interest, the CAS
will send all corresponding states to that console, where alarm
software will display them.

VI. ALARM SOFIWARE WITHIN THE PCA'S

A. General Structure
There are 3 layers of software within a PCA [5]. At thelowest level there is the Low Level Alarm Server (LLAS).
The middle layer concerns Surveillance Programs (SP's) which
can be divided into 2 sub-layers: that dealing with Standard
Surveillance Programs (SSP's) which always exist, and that
dealing with User Surveillance Programs (USP's). Finally at
the top there is the Local Alarm Server (LAS). All theselayers communicate in a standard way using meSMges and allprocesses are either active, or waiting for a message and or atimer: they never die.

B. Low Level Alarm Server
The LLAS receives FS's from 'intelligent' type ECA's via
the alann channel of the multidrop bus. They may be thecomplete description of a problem detected and transmitted by
the most intelligent class of ECA's, or a pseudo FS from aless intelligent ECA simply indicating that a change in state
has taken place. In the latter case, the pseudo FS may containthe current state as data, which must then be interrupted at the
SP level. The role of the LLAS is fU'St to transform thereceived FS into a standard UAVl string, then to extend it intoa Standard Ascii (SAVI) string through the addition of thecomputer name, SP name and arrival time. Finally, using the
FF and an internal correspondence lable, generated from the

C. Standard Surveillance Programs
A SSP deals with all instances of one type of equipment
connected to a PCA. This allows logical analysis ofFS's
concerning a particular equipment area, which is usuallycompletely different to that required for another equipmentarea. This leads in some cases to dedicated software withincertain SSP's which is well separated from the standard

software.
To improve the maintainability, the ability to accept
changes, and to provide a 'template' for a SSP, each SSP isdata driven using 2 standard flat files generated from thedatabase. These files are used to build internal tables atinitialisation. One contains all possible FS's considered valid
for that SSP, together with a 'LEP Mode Mask' for each FS
which indicates the applicability of each FS under eachmachine mode. This table is used for: the reduction of FS's
within or across FFs; the treabllent of oscillating FS's; andthe possibility to inhibit, on request from a control centre
console, the transmission of particular FS's. In all cases it ispossible for operators to view remotely the underlying FS
details. The second table contains command/response
information necessary to contact the attached ECA's, and insome cases the correspondence between bits in an equipment
status word and their FS description.
SSP's attached to intelligent ECA's use these tables torequest periodically the state of each relevant ECA to verify
the consistency of their AL's, rectifying any discrepancies
found. If an ECA does not respond, it is considered a problem,
and a corresponding FS is generated. For those SSP'sreceiving pseudo FS's, indicating only a change in state, theECA must be accessed to retrieve the true equipment status foranalysis. ECA's which have no alarm 'intelligence' are only
capable of providing the status of their equipment and have no
notion of what defines a correct as opposed to an incorrectstate. Here the corresponding SSP uses the tables not only topoll the state of the equipment every few minutes, but also todefine the relationship between the data received and the FS
definitions.
The aim of the SSP is to arrive at a description of the
problems concerning the equipment for which it is
responsible, using FS descriptions. This result is stored in its
AL and all changes are passed to the next software level, theLAS. All software concerning flat files, maintenance of theAL, acceptance of FS's from ECA's and passing the result to
the LAS is contained in an alarm library. This, together with a
SSP 'template' is offered to assist in building SSP's.

D. User Surveillance Programs
A USP offers users more independence to survey theirsystem and often concerns equipment not connected to ECA's.
This approach is used in compute.rs dedicated to surveillance as

S06SA03256

System Architecture256

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

ICALEPCS1991, Tsukuba, Japan

well as in PCA's. Wherever it is used, the strategy is thesame. Each USP surveys its system and arrives at a result
which is transmitted as a SAVI string to a corresponding
SSP. Periodically, contact is made between the SSP and USP
to align the AL of lhe SSP with that of the USP and to verify
that the USP is still functioning.

database by grouping each FS into one or more 'categories',
which represent areas of interest of the various users of thesystem. Examples of category definitions are: one for eachequipment group, safety, machine operation, technical services
etc. A maach of a FS to one or more categories will return 6fields of independent infonnation for each maached category.
This infonnation concerns: description of the problem; action
to be taken; priority, very serious, serious, and warning etc.
All infonnation is tailored to each category. For example a fire
alarm attached to lhe safety category would have in its 'action'
field: 'Immediate Intervention', since it is the safety services
which deal with that type of problem, whereas the same FS
1WOCia1ed with the machine operation category would be more
for infonnation or in some cases require the beam orequipment to be switched off depending on the location of thefire. Naturally FS's associated with machine operation would
not be attached to the safety category.
As a result of this database access, a list is made of all thecategories associated with the FS. It contains the SA Vl andboth parts of the static infonnation for each category. This
represents all infonnation known to the alarm system for thatFS.
Any user who would like to receive alarm infonnation at aconsole must run an initialisation which asks what categories
of information are required. This operation infonns the CAS
and thereafter any FS received by the CAS which is associatedwith any of these categories will automatically be sent to that
console. All communication between the CAS and consoles ismade using RPC's.

All FS's generated or dealt with in a computer will finallyend up in the LAS, having passed via a SSP. The contents of
the AL of a LAS represents the overall state of all equipment
surveyed by that computez. This is in conirast to the contentsof the AL of a SSP which only represents the state of theequipment monitored by that SSP. To ensure that the contentsof the LAS AL equals the sum of the AL's of all SSP's in thatcomputer, the LAS periodically demands the state of each
SSP, correcting any discrepancies found.
It is the LAS which provides the external connection to theCAS, via a Remote Procedure Call (RPC) [6]. All changes ofstate in the LAS are immediately sent to the CAS.
There were 2 reasons for introducing the LAS level. The
first was to reduce the number of physical connections to theCAS, as there were multiple SSP's at the level below.
Secondly, it was to perfonn logical analysis on the FS's
concerning all the equipment connected to that computer. For
the moment no further analysis of FS's is perfonned at thislevel.

VII. THE CENTRAL ALARM SERVER
The CAS [7] represents the hub of the alarm system inthat it receives FS's from all computers perfonningsurveillance tasks via LAS's and distributes them to thevarious control centres for display to interested parties. Within
the CAS there are a number of processes running, allcommunicating in a standard way using messages. These
processes are concerned with: the management of the AL,
which represents the state of the whole process; providing a'backup' to each LAS to ensure AL consistency; access to thecentral alarm database which runs on-line within the CAS;archiving all FS's received; and finally dispatching relevant
FS's to consoles.
It is the database which is the centre point for theprocessing within the CAS. All FS's known to the alarmsystem are present in the database. Any FS arriving from a
LAS which is not known is placed in a trace file for further
investigation.
When a FS arrives at the CAS it is in the Conn of a
SAVl. The triplet FFJFMJFC is the key used to access the
database, the remaining infonnation in the SAVI representing
the dynamic part of the FS description. A number of relational
tables are accessed and 2 types of static infonnation are
retrieved. One concerns FS details such as: person responsible,
location address, inslallation concerned, in all, 10 fields. The
second concerns information relating to who might beinterested in the FS. This organisation is done within the

VIII. REcEPTION OF ALARMS AT A
GENERALISED CONSOLE
For the 'Injection Tests', a vecy simple, dedicated console
was built using a 286 machine to receive FS information. It
was soon found to be inadequate l!Jld it was decided toincorporate FS reception into the generalised console manager
which was under development for workstations used in thecontrol centres.
The Console Manager (CM), completely manages aworkstation from 2 dedicated lines of 'icons' at the top of thescreen, referred to as the CM banner. They provide infonnation
about LEP and allow the execution and control of multiple
application programs, including the reception and display oferrors encountered by these programs. To interface to the
manager it was decided to dedicate an 'icon' within the CM
banner and deftne it as a toggle with 2 states described by'icon' texts: 'SHOW ALARMS' and 'HIDE ALARMS'. Whena console is first initialised, only the .CM banner is visible
with the alarm 'icon' indicating 'SHOW ALARMS'. In thisstate no application programs are running.
To initialise the console to receive FS's the 'SHOW
ALARM' 'icon' is selected which brings to the foreground 2
alarm windows and changes the 'icon' to 'HIDE ALARMS'. If
the "HIDE ALARMS' 'icon' is selected, the CM removes the2 alarm windows, but keeps them active in memory. One
window has a single row of alarm 'icons' at the top and

S06SA03
System Architecture

257

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

E. Local Alarm Server

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA03

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

displays the AL; the other displays the instant faults. An
alarm 'icon' called 'configuration' is used to configure theconsole for FS reception. This displays all the categories
existing in the CAS. A selection of categories is then madewhich corresponds to thoSe FS areas of interesL An 'apply'
function then sends this request to the CAS, where a search ismade for all AF's corresponding to that selection. All
information concerning these FS's is then sent to the console.
Thereafter any FS changes within these categories willautomatically be sent to the console.
Alarm software within the console receives these states,
places them in an AL, displays them in the active FS window,
and manages a local archive. Information displayed is the date,
FF, location address, FM, and fault description, all of which
occupy 1 line. FS's are displayed in order of priority and time,with each priority having a different colour. The default is todisplay the most recent, highest priority FS's, but scrolling ispossible.
Using the alarm 'icons', various operations can be
performed on a displayed FS such as: display the dynamic andstatic information relating to that FS; acknowledge a FS by
displaying it in inverse video; inhibit a FS, which sends acommand to the appropriate PCA and SSP to flag andterminate that FS; etc. Another set of alarm 'icons' allows
FS's to be re-enabled; the screen to be printed; scanning of thelocal archive; and creating a Test' alarm which checks mostelements of the alarm system, finally arriving as a displayed
FS in the active alarm window, and terminating automatically
20 seconds later.
Periodically the console alarm software requests a 'backup'
to the CAS to verify its AL. If the console cannot access the
CAS for any reason, it colours the alarm window blue andprints a message that the console has lost contact with theCAS. This is the final link in the chain which verifies thecorrect functioning of all parts of the alann system from thepoint of generation of the FS in an ECA. right through ID thedisplay of that FS in the control centres.
To allow an operator to use the console to run otherapplication programs, but at the same time be informed of any
FS changes, the SHOW ALARMS 'icon' is used to indicate
the arrival of any new FS.
Instant faults are not categorised. A console can either be
initialised to receive all or none. The display is again 1 line
per FS and works in 'roll over' mode with a scrolling facility.
Any console in the system can run the CM and initialise
to receive FS's. This provides a very flexible method toconnect to the alarm system. In practice we run with 6
permanent connections and up to 6 temporary ones.

including all static information used to describe these states,
are contained in the database. Relationships between FS's andcategories, LEP states and equipment states are established. To
enable all this infonnation to be maintained, and at the sametime use it in a coherent fashion, 2 relational databases withthe same internal structure are used, one running on a centrally
maintained VAX and the other in the CAS. It is the VAX
database which is used for maintenance and interfacing to theequipment groups and is considered the 'master'. Archiving of
all FS's arriving at the CAS is also maintained using both the
database on the CAS and VAX.

IX. THE ALARM DATABASE
A. Overview
The database is the key to the overall system. Without it
management of the system and interfacing to the equipmentgroups would not be possible. All FS 's that can be generated,

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA03

B. The Master Alarm Database
Each equipment group interfaces with the alarm systemthrough a standard flat table called the 'Interface Table' (IT),which was defined by the alann team. It contains a complete
description of all FS's generated by the equipment group.
Roughly 90% of the column definitions are common for all
equipment groups. The rest concern equipment specificinformation Jike data and FS relationships which differ widely.
A set of scripts has been built by the alarm team which checks
the consistency of ITs both with respect to themselves and thealarm database. The scripts must be run by the equipmentgroups before the IT's are used by the alarm system.
Responsibility for these tables and the way they are interfaced
IO the equipment databases, lies with the equipment groups.
Preparation for a database update consists of: verifying any
changes made to IT's; using these tables to generate allnecessary flat files for those SP's affected by the changes; andupdating the master database from the !Ts. At this point the
CAS is stopped, the database loaded, and restarted. All affected
SP's are also stopped, internal tables initialised from flat files,
and restarted. This operation takes about 15 minutes.

C. The CAS Database
The database running in the CAS is used only in 'select'mode. For each FS arriving, the database is accessed to: checkits existence in the database; append all static information
known about the FS; and classify the FS according to the user'categories' of interesL

D. The Central Archi.ve
Each FS that arrives at the CAS is archived. The archived
information consists of the elements of the SAVI string
which is stored in a flat table. This means that to complete thedescription of a FS in the archive, access must be made to thealarm database. To avoid the management problem of storingarchived information, a minimum archive is stored on theCAS. Each day, the previous day's archive is automaticallytransferred to the VAX, and removed from the CAS. The VAX
manages 2 alternating archive tables which are 'record' limited.
When the current table reaches its limit, it is copied to a fileand the other table becomes the current archive. In this way a

S06SA03258

System Architecture

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

ICALEPCS1991, Tsukuba, Japan

continuous archive is available on-line. Facilities to accessthis archive from consoles initialised to receive alarms areavailable.

facilities either did not work as described <X' did not work at all.
Subsequently we found that the product was no longer on themartet This concluded our work in this area to-date.

XI. EXPERIENCE WITH NEW TEcHNIQUESAs a continuation of our efforts to explore the possible
uses of ES's within the LEP alarm system, a pilot project [8]was launched to build a prototype surveillance system for the
power conveners of LEP. This work followed a thoroughinvestigation of the commercial market for products whichwere suitable for our environment, and which could do as well,hopefully better, than our running conventional system.
We were looking for a modular, 'real time' ES running in a
UNIX environment with the ability to link to standard
commercial software. The 'real time' aspect was not so muchthe response time, although that was important, but rather the
possibility to reason over time using temporal constructs.
Modularity was important because we already had equipment
data acquisition, networking, etc.
Finally we found a system which seemed to have alldesired features, as well as an interface to a graphical package
which we were already using. It was an American product andperhaps because it had no established European agents, wefound it impossible to get the necessary technical support toallow us to continue with the productThis was a major set back, but we decided to visit, for thesecond time, a commercial exhibition of ES's in France. A
European product which seemed ideal was found. Training was
arranged for 2 of our personnel, and a prototype prepared for
the LEP power converters to be used in an evaluation of the
product for one month. The first month was spent in trying toload the product, and thus little work was done on the
prototype. An extension of 1 month was arranged for theevaluation and when work finally started on our prototype itsoon became clear that the product was not operational and,apart from numerous bugs, a number of the advertised

XII. CONCLUSION

The LEP alarm system today provides an important,reliable facility for machine operations, and for technical andsafety se£Vices. It has shown itself to be flexible to equipmentchanges and capable of accepting upgrades gracefully. The
components from which it is built are well interfaced and canbe independently changed. ('.apacity of accepting new FS's has
been demonstrated recently by connecting the complete
technical services of the Meyrin Site, some 5000 states,
representing 6% of the current CAS total.
The decision to pursue the conventional approach wascorrect and there remains doubt that the system would havebeen ready in time if the alternative approach had been taken.
Xlll.ACKNOWLEDGEMENTS
I would like to thank the many people who havecontributed to this project, especially: Tuanhua. Huang*,
B.Marchal*, and L.Mantegazza for the database; J.M.David*,
F.Rodor*, and J.M.Ortholand for the CAS and MMI;
J.P.Forestier* for the PCA; and C.A.Cameron for research
into new techniques and continued development on the PCA.
• people no longer at CERN.
References:[ l] J.Fuchs,P .Skarek,L. V arga.,E.Wildner-Malandain,lntegrationof Generalised KB-Sytems in Process Control and Diagnosis,'SEAS' Conference, Lausanne, Switzerl1111d, April 8-13, 1991.
[2] F.Chevrier, Safety Conuolled By An Expen System On
Experimental Sites In High Energy Physics, Pergamon Press,
Operational Expert Systems Applications in Europe, 1991.
[3] J.Ancelin,J.P.Gaussot,P.Legaud, A Real Time KnowledgeBued Alarm System EXTRA, Al & other Innovative
Computer Applications in the Nuclear lndusuy, 1987
Snowbird Utah, Plenum Press, New York & London.
[4] P.G.Innocenti, The LEP Control System, Conference on
Accelera.lor & Large Experimental Physics Conuol Systems,
Vancouver, BC, Canada, October 1989.
[5] J.P.Forestier, The PCA Alarm Software Environment &Surveillance Software, CERN/SL/CO/Note/91-15(unpublished).
[6] P.S.Anderssen,V.Frammery,Tools for Remote Computing in
Accelerator Control,Conference on Accelerator & Large
Experimental Physics Control Systems, Vancouver, BC,
Canada, October 1989.
[7] F.Rodor,The LEP Central Alarm Server & ConsoleInterface,CERN/SL/CO/Note/91-7/8,(lDlpublWted ).
[8] C.A.Cameron,LEP Alarm Group Expert System Project Status
Repon,CERN/SL/C0/90-122,(unpubli.shed).
Trademarks:
UNIX is a rrademark of AT&T Bell Laboratories.

S06SA03
System Architecture

259

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

X. SPECIAL REQUIREMENTS FOR SAFETY
In order to satisfy the safety requirements, 3 main areas had
to be considered. First, all FS's associated with the safety of
personnel had to be categorised according to the action
required. These actions were: immediate intervention by thesafety .se£Vice, approximately 500 FS's have been defined forthis category; immediate intervention by the technical service;
and intervention by the technical service during working
hours.
Secondly, the transmission of FS's to the SCR had toconsist of 2 independent paths: one using the control system
to transmit details; and the other, called the 'redundant' channel
consisting of I summary state per LEP point transmitted via a'hardwired' line to a synoptic panel in the SCR.
Thirdly, all the active components in the computer andhardwired transmission paths to the SCR had to be powered by
secure electrical power. To reduce this equipment to aminimum, 2 computer networks around LEP were installed:
one for the machine and one for safety including the services.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA03

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingin Physic1 mode, and it has to be performed only on the
Wide Band crates.
One can note here that if the BOM •vatem periodicallymeaaured the Cloud Orbit, the aame data could alao be
wed to perform thia meaaurement.

of beam to be observed.
2. The hard.wit.le lleUing of the pickups is common for all the
pickups in a given DSC and for both acquisition memories.
3. The BST meaBage received at each LEP beam turn will
always be the Ame for all the DSCs.

• Contlnuoua Recording (for Post Mortem Beam Historyor other) "Every n turns, acquire 1 (or m) turn(s). On request, or on a special event, stop the acquisition." Theaim of thi.a operation mode is to be able to reconstruct the
behaviour of the beams before a given event (e.g. beamloss). The data processing will depend on what the user
is looking for.
One should note that, since for the Wide Band only one
beam can be acquired at a time, the information coming from those pickups will be incomplete. Note also thatunless an automatic mechanism like the BST "service request" is available to stop the acqnisition in real time, thisoperation will not be really useful. In fact, if the acquisition takes place every turn, the memory will be completely
overwrlUen every tenth of a second.
This mode of operation is plt.lticullt.lly important during
LEP Machine Development.

4. Two other possible limiting factors It.le the data processing
capacity of the BOM CPUs and the data transfer capacityof the network connecting the BOM crates to the Apollo
BOM Server.

Requirements :what the BOM should do
The stlt.lting point of the new BOM softwlt.le design was theanalysis of the requkements. This implies the definition of theoperatiollll the system is expected to perform, and of what is
important to the users who perform the different operations.
Several different operations can be performed by the BOM System, by acquiring dift'erent sets of turns and by extracting different information Crom the acquked data. We briefly describe
each of them.
• Closed Orbit Meuurement. "Acquire a given numberof turns and, for each pickup, compute the average beam
position. "The user must be able to specify the number of turns, andto tell the system if data coming Crom the two beams haveto be mixed or not.
The average is made over all bunches of a given beam,or over all bunches of both beams if the result has to bemixed. This is the most important oC the BOM operations,because it is used for correcting the orbit. It is therefore
very important that the BOM System should be able toperform it quickly and reliably.
This operation requkes synchronization between the 40
BOM crates : we need to acquke data Crom the aame turns
all lt.lound LEP. Therefore the stlt.lt of the data acquisition
must be triggered by the BST.
• Beam Trajectory Measurement. "Sdect a beam. Acquke a given number of turns. For each pickup computethe beam position of each bunch at each turn. "Again, this operation requires absolute synchronization
between the 40 BOM crates. In this case it is plt.lticularly important that every pickup acquires data Crom thesame turna
The Trajectory Meaaurement becomes very important
when, for one reason or another, the beam does not aurvive
iruide LEP. In thi.a case the acquisition will be triggered at
the injection of plt.lticles into LEP, so that the behaviourof the beam im.mediatdy after the injection can be analysed.
Typically one is interested in a very few number of turns(8 turns It.le enough to get the first revolution for eachbunch).
• Beam Poaition Monitoring at Experiments. "Every
60 seconds, acquire and average the beam position in the
pickups closest to the intersection points with experiments(Wide Bands), and derive the beam position at the interaction points"
This operation is only important when LEP is running• 1000 Turns A.cquiaition. (for Harmonic Analysis of individual Pickup Data, or other). "Select a beam and aparticullt.l bunch. Fill the memory with comecutive turns,
for each pickup compute the positions ofthe selected beamand bunch at the dift'erent turns, and store them in a table. "The table is then available for whatever analysis is requiredon the data. It must be possible to stlt.lt the acquisition
after a specified event.
It could also be convenient to be able to acquire a turnevery n turns, to observe the beam over a longer time interval. In fact, 1000 consecutive turns represent only 89
milliseconds.
• Calibration and Simulated orbit.
"Calibration: With no beam in LEP, use the ad-hoc BOM
hlt.ldWlt.le to determine the gains and the offsets for eachpickup. Save these values, and detect suspicious piclcups.""Simulated Orbit: With no beam in LEP, use the ad-hoc
BOM hlt.ldWlt.le to shnulate an orbit with predetermined
positions. Check if the measured values match the predicted ones."
The Calibration was normally used by the BOM hardwlt.lespecialists, but making it more automatic, it could becomea routine procedure for the operators. The Simulated Orbit is used to check the quality of the Calibration.
Some of the operations described are performed on demand,
others are executed continuously in background, others are repeated at fixed intervals. The most hnportant operation is the
Closed Orbit measurement, which is needed to correct the orbit.

The strategy of the new software
All the described BOM operatiollll consist of two main plt.lts :the acquiaition and the proi:eaaing of the data. The acqnisition
includes also the preparation of the system (hardware setting).
The data processing includes also, in most cases, sending thede.ta to the BOM Server, which baa to collect the data from all

S06SA04
System Architecture

261
261

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-S06SA04

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, Japanthe DSCs and to make them available to the users of the system.
To syntheme our analysis, we have to find a convenieni solution to uploit the flexibility of the system (two independent
memories in the DSC11} in order to satisfy the requirements (ondemand and automatic operations), keeping in mind the overall constraints (only one hardware setting , and only one BST
task executable at a time, that mean11 only one dafo acquiaition
operation performable at a time).
Solving this problem in temu of software means finding a natural subdivision of tub between different computer processes,
both on the DSCs and on the BOM Server.

ing for it, if any. All these processes are started by a Starter
process, which surveys them, and communicate through •haredmemories (MOPS} and message queues.

Processes on the DSCs

On the DSCs we have 4 main processes : one to Prepare logice.lly
the DSC for the following operations, one to Set the Hardwareof the DSC to the required conditions, one to Proceu the Main
Memort1 and one to Proce11 the Secondart1 Memort1. These
two latter Data Processing proceues are two instances of thesame one, acceuing respectively the Primary and the Secondary
Memory. All these processes wait for BST messages, and thenperform the specified actions, Typice.lly any of the BOM operations will consist of a ce.ll to the Prepare proceH, one or morecalls to Hardware Setting followed by acquisition of data in oneof the two BOM memories, and eventually a ce.ll to the corresponding Data Processing Process, which will read the datafrom its memory, will produce the result and will send it to the
BOM Server if needed.
Other two processes perform WJeful tasks : the Auziliary process and the Creator. The Auxiliary process performs e.ll sortof miscellaneous operations (setting the DSC time, loading new
calibration factors, doing ofHine analysis on data already acquired) on rec:eption of the corresponding BST action code. In
particular, it performs the harmonic analysis on the table produced by the Main Memory process as a result of the Multiturn
Acquisition. The Creator process starts all the others, restarts
them if they die, and creates the shared memory areas via which
the other processes can share information.
An additional independent process is an RPC [8] server for diagnostic access to the hardware of each BOM crate from PCs andApollos (The RPC is used in this cue because the Xenic PCs
found close to the equipment do not support TCP /rJ> sockets).

Processes on the Apollo BOM ServerOn the Apollo BOM Server two processes , the Automatic
server and the Demand server, share the BST resource via a
semaphore. While the Automatic server executes periodice.lly
conunanda from a command table, the Demand server is activated by the Interface server. This latter process constitutes
the interface between the BOM Server system and the wers.
Vie a library of functions they can, among other things, trigger
a new closed orbit meuurement, ask for the result of the latest or the next acquired orbit, enable or disable the automatic
server. Two other processes, the Collector and the Receiver,complete the building blocks of the BOM Server. The Receiverreceives data from all the DSCs directly into a shared memory,from where the Collector can read and treat them. The Collector is also signalled by the Demand or by the Automatic servers
every time an operation (e.g. Closed Orbit) starts, and tells theInterface every time the results of an operation are completed.
The Interface will then deliver the result to the wer(s) wait-

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA04

Implementation Problems
The implementation of e.ll these ideas required a considerable
amount of work. We had to find our way through several foreseen and unforeseen problems. Some have been solved satisfactorily, others not yet.
• SPEED.
In order to improve the performance of the DSC software,
special care has been taken to avoid repeated calls to subroutines with high number of arguments. Also "register"
variables have been Wied in an effec:tive way. By following these prescriptions, it wu possible to save an order ofmagnitude in the DSC processing time.
• PARTICLE IDENTIFICATION.
The Narrow Band Pickups acquire signals coming fromeach bunch of each particle. The soRwere analysing thesesignals should be able to distinguish between electrons andpositrons. For this reason, the relative arrival time of eachbunch with respect to the LEP turn clock signal is re<:orded
in memory together with the data. This time (called "finetime ")is measured in units of 400 nanoseconds, and it ce.n
be compared with reference tables for each pickup, to identify the different bunches and to reject parasitic signals.
When e.ll the bunches ere present, the particle identification is easy, becawe the arrival order of the bunches if
predetermined. When some bunch u missing, the identification becomes critical for the Narrow Band pickups
closer to the intersection points, because the time interval between bunches of the two perticlu is only around
660 nanoseconds, and the turn clock signal arrival time
can be wrong by up to 200 nanoseconds. To try to solve
this problem, we first analyse the data for a pickup far
from the intersection point. From this, we produce a table containing the different bunches in LEP, together withthe difference between the theoretical arrival time and themeasured one. This table enables the program to correctly
identify the particles even in the most critical pickups.
• INSTALLING THE NEW SYSTEM.
The transition between the old and the new system was nota single step one. It had to be done progressively, keeping
the whole system operational, and replacing old perts withnew ones as soon as they were ready. Therefore it has beennecessary to make all the new software produce resultscompatible with the old one. This ha been achieved by
WTiting a process (the BOM Li1tener) on the Apollo BOM
Server. The BOM Lutener receives from the Collector all
the messages that should have gone to the Old Collector
on the PC, and sends these messages to it. Another point
where compatibility with the old system was taken into
account was in writing the new BST tasb, becaWJe they
had to be understood by both systems.
• NETWORK TROUBLE.
The most seriow problem was the network communication
between the DSCs and the BOM Server Receiver. We ere
currently wing the TCP /rJ> communication protocol, connecting each DSC to a Receiver program on the Apollo.

S06SA04
262

System ArchitectureWe do not have a large amount of data to send (typically leu than 500 bytes per DSC), but we meet serious
limitatiom. To make a long story short, we need to run
8 Receivers on the Apollo, so that they will receive datafrom 5 DSC1 each. We found that if we tried to send all
the data packets from the DSCs at the same time, a luge
fraction of the packets were arriving with luge regulaz delays (typically 13, 26, 40 and 92 seconds), and occasionallysome packets were lost. The regularity of these time interval.I implies that we were observing some "wait and retry"mechanism implemented inside the TCP /IP software. In
our set up this effect 1tarted to manifest itself when morethan 15 DSCs were installed. Our first attempt to circumvent this problem hu been to introduce additional delaysin the DSC1,
that they do not try to uansmit all at thesame time. Our best result has been achieved by spreading the transmission of the DSC packets over around 10
seconds, in which case most arrive in a spread of 12 secs,
with only a few arriving after around 25 secs.
To improve this performance, an alternative data trarumission has been developed, based on a simple protocol
sending raw Ethernet packets from the 40 DSCs to a central collector 05-9 system on the same Token Ring. A
single TCP /JP connection then connects this system tothe BOM Server Apollo. This system seems to reliably
deliver all 40 replies within at most 12-13 seconds, and often quicker (the best observed performance was 1 seconds); we are gaining operational experience with it.

"°• INVOKING THE BST SYSTEM.
The BST system is currently activated through a remote
procedure call to a dedicated PC. Up to a few seconds arelost in establishing the connection to this system. Moreover, occasionally the calling program never returns fromthe RPC routines, and it has to be killed.
We are currently porting the BST system to the OS!I environment.

• NETWORK FILE SYSTEM FOR THE DSC.
Our DSCs are diskless and boot from a centralized fileserver, Initially, a reduced version of the Network Disk
server developed in the LEP Aleph experiment [6] was developed by D. Mathieson to run on 05-9. This support
work was essential, because it allowed tests with a full
40 DSC system to be carried out during the 90-91 wintershutdown of LEP, before a usable NFS was available forOS-9. This system was also used in LEP operations until
June, when the NFS on OS-9 seemed sufficiently stable totransfer to using it.
This latter system is far from being perfect. In order not
to overload the fileserver and the network, we have to wait
around 10 seconds between the boot of two DSCs. With
40 DSCs, this meana around 1 minutes to boot all of them;
yet not all succeufully reboot at the first attempt. A more
serious problem is that the onllne use of the system is almost impossible; if a few DSCs want to a.ccess file1 atthe same moment, very often the NFS gets stuck and it
is unavailable for about 30 minutes. A better configured
fileserver, closex to our DSCs and more dedicated to theBOM , is planned to be installed.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA04

Results
The transition from the old to the new system has taken placein several steps. First, in mid April 1991, the first version of
the Apollo BOM Server was installed, together with the first
OS9 Wide Band DSC. At the begimiing of May the remaining 1
Wide Band DSCs were installed, and since this time data fromthe Wide Band systems has been sent to the Apollo, which forwarded it to the old BOM Collector PC. The next step was
to use the first Automatic Server to periodically produce thedata needed to determine the position of the two beams at theinteraction points [T]. This was accomplished in May, Also in
mid June the 16 Narrow Band DSCs which share the same network infrastructure with the Wide Band DSC1 were installed
during one afternoon. At the begimiing of July, profiting fromthe laat access hours during a short shutdown, the remaining 16
NB DSCs were rapidly installed and connected to the LEP Token Ring, using the freshly arrived IBM Ethernet-Token Ring
Bridges. In August the new Multitum Acquisition and Humonic Analysis facility was first demonstrated. After the holidays, work went into improving the Calibration procedure andproducing a second version of the BOM Servers. Currently the
Automatic Orbit Acquisition is running, producing a new orbit every 60 seconds. The latest orbit produced is available to
the LEP operators within seconds. Applications based on therepeated orbit acquisition have been written, for example tomonitor and display continuously the position of the beams at
all the Wide Band Pickups in the Experimental Areas.
To summarise the results• Thanks to higher performance DSC CPUs and to software
better optimind for speed the data processing time hu
been reduced by a factor of 25 • This means that it is nolonger impractical to average the Closed Orbit Measurement over a luge number of turna. This turned out to bevery weful when we discovered, via a Multiturn Analysis,that there ,was strong 50 Berti noise in LEP ( generatinga typical peak to peak oscillation of 0.5 millimeters). The
period of this oscillation is 224 turns, so, in order to average it out, we now measure the orbit over 224 or 448 turns.
The processing time takes only a very few seconds. The
overall time from when a new orbit measurement over 224
turns is asked to when the result is made available to theoperators is now around 22 seconds (using the above mentioned alternative data transmission schema). We plan toreduce it to 15 seconds next yeu.
• A new algorithm has been implemented, with good results,
to distinguish between electrons and positrons in the Nurow Band Systems. This makes it possible to acquire an
orbit of a specifi.ed beam. It was possible in this way toehow the saw_tooth effect due to the beam losing energy
when emitting synchrotron radiation.
• The Multiturn Acquisition, together with the Harmonic
Analysis facility, has been used succe111fully to measuresome physics parameters of LEP (phase advance, dispersion,..). The effect on the iajection kick on the orbit canalso be examined, and instability in the beam detected
and studied. A Fast Fourier Transformation can be also
performed on each pickup's data , to show possible perturbations.
By analysing data from the Multiturn Acquisition it waspossible to localize the source of the 50 Berti noise.
This facility also enables us to check the quality of the

S06SA04
System Architecture

263

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
data coming from the different pickups, and makes the detection of bad pickups easier. By examining results Cromsuch an acquisition , we were able to detect a pickup which
wu wrongly cabled (the vertical and horizontal positions
were interchanged), and another where two cables wereshort-circuited.
• The Automatic Orbit Acquisition, by which a new orbit
meaaurement is produced every minute, makes lire easierfor the operatou. It also constitutes the base for any LEP
orbit statistics program. By a simple call to a function,
any program can get all the data coming Crom the latest
acquii:ed orbit within seconds.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA04(6] T. Charity OS-9 Network Diak Server, Uicr Guide andReference Manual. CERN/EF/ALEPH 89-194.
(7] A. Belk. Interaction Point:=' Software for LEP. IPoptica
and IP1erv. CERN/SL/CO 91-29(8] P.S.Anderssen et al. The Network Compiler Uier Guide.
CERN LEP Controls Note 97(9] W. Herr M.O.P.S. Uau Guide for "C" Program1.
CERN /SPS /88-43(AMS)• The Calibration, which in the past waa not very user
uiendly and required hall a day or work, now takes 10
minutes and does not require any specialist intervention.
It also updates a database, through which pickups whichwere not correctly calibrated will be marked as bad in theorbit data provided to the Operators.

Future Improvements
OC all the initial requirements, only the Continuous Acquisitionof data baa not yet been implemented.

Acknowledgements
Despite the (a.ct that the BOM software described in this paper
has been written essentially by one person, the project owes its
success to the fruitful collaboration of many people. In particular, I would like to thank very much my colleagues: J.Borer who
had the necessary patience for explaining the BOM system tome, C.Bovet, A.J.Burm, D.Cocq and A.Manarin for their precious collaboration, J.J.Gras for the BST receiver server anddriver used in the BOM DSCs, C.David for improvements to
the BST Master software, and D.Mathieson, who contributedin an essential way to the project by providing the network
disk system used until June, by designing and implementing
the raw Ethernet communication software mentioned above,and by generally supporting the required development environment. In addition, although independent from the software
described in this paper, H. Michel has provided the specialist
BOM diagnostic progr8D1!1.

References(l] J. Borer et al. The LEP Beam Orbit Meaaurcment 1y1tem. Proceedings o!the 1987 I.E.E.E. Particle Accelerator
Conference, Washington D.C, 1987.
(2] G. Baribaud et al. The LEP Beam Orbit Meoaurcmcnt •y•·tern: 1tatua and Running-in rcaulti. Proceedings oCEPAC,
Nice, 1990.
(3] G. Baribaud et al. The Beam Synchronow Timing ryatem
for the LEP inatrumentation. Proceedings of ICALEPS,
Vancouver, 1989.

(4] C. David. The Beam Synchronoua Timing 1y1tem for the
LEP inatrumentation. The Maater Reference Manual :new facilitiu. CERN/SL/BI-SW/Note 91-19(5] J J. Graa. The Beam Synchronow Timing Receiver Utilitiu. CERN/SL/BI-SW /Note 91-01.

S06SA04264

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

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

B.

Consumer Part
A data reading channel scans the valid list until it finds a
new unprocessed buffer and returns the data to its parenttask. When the operation is completed, the buffer ismarked and is moved within the linked lists according tothree situations:

Software Architecture

Even.ta are defined as a set of structured and correlated
data which enter the system at random by interrupts.
Events 1 are assembled into larger, configurable, structures
called bloclu.
A number of tasks can be implemented in the system
to read data simultaneously from data chan.n.ela. A channel is characterized by an acceBB mode: 'full or sample.
Tasks accessing data through a 'full-mode channel readand process all the data blocks. They can therefore leadto a considerable increase in the system dead-time. The influence on the data proceBBing dead-time can be reduced bysample-mode channels which acceBB only a sample of thedata at the task's own processing speed. A data storingprocess works in the 'full-mode, while the sample-mode
suffices for data monitoring. A block type parameter canalso be assigned to a data channel: read operation on thechannel will return only blocks of events of this particu·
lar type.

1. the buffer waits to be processed on another 'full-mode
channel: nothing happens. It remains on the valid list
and is safe from interrupts;
2. the buffer waits to be proceBSed on sample-mode channels only: it remains on the valid list and returns at
the tail of the free list;
3. the buffer has been processed on every channel: it is removed from the valid list and returned to the free list.
If the acquisition produces data at a faster speed thanthe consumers process them, the free list will be emptiedj
event interrupts are then disabled until a consumer proceBB
returns a buffer to the free list.

III.

The Buffer System
The data acquisition system can be viewed as a prod-ucer
task - the event's interrupts - and many con1umer tasks- the data analysis and storage - running concurrently tofill and consume blocks of events. The producer and theconsumer tasks share a common buffer system.
A buffer refers to a block of even ts. They are arranged in
two doubly-linked lists (2] (Figure 2): the free list contains
buffers that can be used directly by acquisition interrupts
to store new events, while the valid list contains buffers
already filled with events but not yet processed. Buffers
can reside in both free and. valid lists. This situation occurs
when they have been proceBSed by all 'full-mode channels
but not by all sample-mode channels.

1

8

2
Figure 2: The two doubly-linked lists

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA05

IMPLEMENTATION

The ideas presented above have been implemented in a
VKEbus system running the V:s:Works 5. O kernel.

A.

Hardware

The VKEbue system consists of three Motorola KVKE147
boards with KC68030 microprocessors. Each board has
SCSI and Ethernet capabilities although they are notused on all of the boards. The system has been used
so far with two different sources of data: CAKAC and
FIC8230 preprocessor.
CAMAC
The CAKAC crate is connected to the VKEbus by the
CES CBD8210 branch driver and the CCA2 crate controller.
The module allows the generation of CAKAC CB'AF cycles
as VKEbus memory mapped addresses. This elegant feature provides a fast access to the CAKAC bus and facilitates
the software writing. The data acquisition system is interrupted at each physical event by CAKAC LAKs.
FIC Preprocessor

Producer PartAt the beginning of a data acquisition, all buffers residein the free list. When the data acquisition process starts,
a buffer is extracted from the head of the free list andbecomes the c-urrent buffer. It is filled with events up to
its maximum size. It inherits the identification of the datareading channels interested to process it and is added at
the tail of the valid and/or the free lists. A new current
buffer is extracted from the free list head and the procedurecontinues.
lThe event definition ia not reatric:tive: an event can be CIJllC
data of a .Ingle ph;yllical event but can abo be a blodc of data preproc:eaaed or filtered by other proc:e•aon.

The CES FIC8230 is a VKEbue board with a KC68020
microproceBSor. It runs a fast, specifically developed, kernel. The processor receives events from a CAKAC crate orfrom a DK.A. channel connected to local hardware. The microprocessor assembles events into blocks which are thenwritten directly to the last stage of the data acquisition ina single interrupt.

B.

Acquisition Software

To reach a high level of flexibility, the data acquisition
system has been layered (Figure 3). The real-time kernel
executes user tasks, which control the acquisition process
and read the data through the kernel I/O system. At a

S06SA05266

System Architecture

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

MP-devices : Device structure has been splitted into a private and a shared part. The private part is the standard VxWorks device structure refered to the local I/O
system. The local structure contains a reference to theshared part of the device.
MP-semaphore: The MP-semaphore has been implemented with a shared flag protected by a apinlock variaThe spinlock is accessed by indivisible
ble [3].
cycle machine instructions to eliminate contentions.
The MP-semaphore has a private, standard VxWorks,
semaphore in each of the participating proceBSors.
Tasks waiting for the MP-semaphore aleep on theprivate semaphore inside their proceBSor. A remote
wakeup has been implemented with the help of the
MVKE147 mailboxes.
Figure 3: Acquisition System Layering

System drivers

lower level, the data acquisition software itself has been
structured in three layers:
1. the aource independent layer comprises the data buffer
system and its integration into the kernel I/0 system;
2. the aource dependent layer implements routines to connect the data source to the acquisition system;
3. the uaer dependent layer implements routines to render
the acquisition proceBB suitable to the user needs.
Real-Time Kernel
The VMEbus processors run the VxWorks 6. 0 real-timekernel. This software has been selected for its:
- clear separation between system development and code
management tasks - on a U?lIX system - and realtime tasks - on VMEbus processor boards - which fitsnaturally in our distributed architecture;- platform independency on both sides: many U?lII platforms and many VMEbus processors are supported;- high networking capabilities with IP family of standard
protocols (TCP, UDP, RPC, IFS, ... ).
The kernel provides all real-time primitives: semaphores, events, meBSage queues, control of preemption,priority-based scheduling, ... as well as the standard C
library. It supports the notion of device driver which
provides a common interface to devices or pseudo-devices
through calls to the standard I/O C library.
MultiproceBBor Extension
The VxWorks 6. 0 is basically a single-proceBSor kernel. To use the full power of the VMEbus system andto obtain the requested scalability, multiprocessor (MP)features have been added. The granularity of the MParchitecture is situated at the task level.
The system has a muter processor and many alave processors. The master creates and owns the shared ressources
while the slaves manipulate them. We have implemented
MP-devices and MP-semaphores.

The data buffer system is accessed by two MP-device
drivers integrated in the VxWorks I/O system. They reflect
the producer-consumer relationship.
1. /dev/acq: The acquisition device controls the production of the data. ioctls are used for example tostart and stop the acquisition by enabling and disabling the interrupts in the master board.
2. /dev/mon: The monitoring device implements theacce11 to the data. Tasks open this device to get achannel and read data.
The lower part of the acquisition device driver is connected to the data source by four routines:
1. acqStartO: implements commands to initialize thesource when starting an acquisition process;2. acqintrO: is executed at each event interrupt;
3. acqRestart () : restarts the data source at the end of
the event interrupt handling;
4. acqStop () : executes commands to finish the data acquisition proceBS.
Each routine has an user defined part, which accesses
the user modules participating in the data acquisition.
Because of the VKEbus limitation of a single interrupt
handler on a given level, the data acquisition proceBS canbe executed only on a single proceBSor, the master, while
the data processing tasks run on several slave processors.
Network Servers
The remote control and data analysis from an user workstation .is executed by Remote Procedure Calla (RPCs)
1erver1 running in the VKEbus system.
- acqS erver: executes ioctls on the I dev I acq device tocontrol the data taking;- monServer: controls the /dev/mon device to grant aecess to channels for remote data reading tasks;- acqSysServer: supervises global parameters and procedures such as system directory, system reboot, ...

S06SA05
System Architecture

267

267

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-S06SA05

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
VMEbueWDrkatatlon

tondatdRPC

Open an acq. dala channel
Open a TCP Poll - - i
Start a data Server _...1

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S06SA05

A workstation process must indicate the VKEbus board
and device it wante to read and the data channel mode.
An example is the ddVME command (Figure 5), based on
the well-known Ulll dd to copy data.
I ddVJIE i1•. .•acq11:/deT/aDD. of-data.01 •Dde~ul.l count•20
Wll%1lingl ob• •et to 1024 b7tea
Connecting to 130.104.3.120(9973) ••• dDne
PrDcesa 18478 atarted
ddVllE: 40/0 blockll ---> 20 bloclta of 1024 bytes
II.ate • 24980 bytea/s
Process ddVXE terminated

LDw lava! TCP
aockel IJO

Figure 5: Example of a workstation task

Workstation Interface
Figure 4: RPC-Less Data Tranfer

Because of their widespread acceptance, SUI 4.0 RPCs
have been selected. To avoid retry problems, RPCs use
the TCP/IP underlying transport protocol. The machinedependent data format problem, unavoidable in a heterogeneous distributed environment, is solved by the Ezternal
Data Format (XDR) layer of the RPC protocol.
The RPC mechanism is well suited to remotely control thesystem, but its layers introduce a time overhead that is toolarge to transfer a high rate of data. For this purpose, we
are ueing a less ressource consuming protocol (Figure 4).
The client contacts, with a standard RPC, the server toopen a data channel on the acquisition side and a data
communication port on the network side. A new specificdata server, receiving both I/O descriptors, is created. The
network port descriptor ie returned back to the client who
can establish a {aster and reliable point-to-point connection (TCP/IP) to the data server to read events.

C.

User Level Tasks

Users can run data processing tasks in the VKEbus
system, they simply access the data through the monitoring device in the same way as for any other device. By
this way the user can analyze data, build histograms, ...
Data can aleo be copied to a disk or a tape cartridge inthe VKEbus crate.
Users may want to access the data directly from processes running in their workstation. They can use a libraryo{ subroutines which takes care of the communication with
the network servers in the VHEbus system. Users must provide four routines:

1.
2.
3.
4.

monStart: begins a data monitoring task;
processBlocll:: is executed for each block of events;
men.Refresh: asynchronous user's request handling;
monStop: completes the data analysis.

Processes respond to the SIGHUP and SIGIIT signals.
The SIGHUP handler executes asynchronously the routine
mon.Retresh() to get intermediate results while the SIGIIT
handler completes prematurely the data reading process.

An X Window interface helps the user to configure
the VKEbus system and to control the acquisition processes. The interface, written in the C++ language, uses
the IIH-CL and InterVievs object libraries (4]. It implements Macintosh-like menus whose items are activated ordeactivated according to the experiment current status. It
uses dialogue boxes to get the data acquisition and monitoring parameters and to show their status. The main C++
class includes a method to dispatch user's requests andsends RPC requests to the VMEbus servers.
The user interface is able to listen to the data acquisition
system and transmit ite messages to the user. For that purpose, we have modified the InterVievs events handler,
making it sensitive to asynchronous messages from the
VMEbus system.

Conclusion
We have developed a simple architecture for a data acquisition system in which real-time data acquisition, monitoring tasks and system control have been loosely coupled.
This provides the flexibility of the system. The syatem ie
now fully integrated within our network of workstations
and is used in experiments around the Louvain-la.-Neuve
Cyclotron.

References[l] G. Bi.Jllard, G. Coate., D. Durand, Y. El Masri, G. Guillaume, F. Hanappe, B. Heuach, A. Huck, M. Mouynalci 1 J. Pe.
ter and B. Ta.main: The Belgian-French Neutron Multidetector
DEMON, Procuding1 on the International Conference on New
Nuclear Phy1ic1 with Advanced Techniquea, Iearapetra, Crete,
June 23-29, 1991
[2] The data acquisition 1111tem and it& buffer ayatem ia inapiredby the UNIX kemel and the buffer c~he, lee: M.J. Bach, The
Deaign of the UNIX Operating S11atem, Prentice-Hall, 1986.
[3] Lawrence M.Ruane, Procesa Synchroniution in the UTS
Kernel, USENIX Computing Sy1tema, Vol 3, 1990.
[4] M.Sibomana, Y. Longr~e, P.Mareachal, M. Nemry,
A. Ninane and F.Somera, Direct Manipulation User Interfaces,in New Computing Techniquea in Ph111ic1 Ruearch, ~d. du
CNRS, 1990, and references therein.

S06SA05
268

System Architecture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

B. The two views

B. The different solutions

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC01

The industrial control market may be divided in two big
Although all these components possess their own processcontrol layer which the operator accesses through the categories.
accelerator control system, a component represents a lot of
The first one includes the Distributed Control System
similar devices geographically distributed along the accelerator.
Therefore the architecture of the overall control system has to (DCS) supplies. They are provided by manufacturers issued
cope with both aspects of large variety of components and from two different origins: big Programmable Logic
wide spread of equipment along the accelerator. This explains Controller (PLC) makers or computer makers. All these
the two views which have always developed in the past. suppliers offer complete control solutions with basically the
People responsible for their equipment like to have an same features:• PLCs and full range of In/Out (VO) interfaces to connect
overview on all their equipment through component oriented
consoles whereas people responsible for the control of theto sensors, actuators, etc.
• redundancy capability for 1/0 interfaces, controllers,
overall accelerator want to operate from an accelerator oriented
console. There is no reason why the accelerator control system
power supplies, cabling, etc.
can not be designed to offer the openness which is necessary to• environmental hardening
many these two requirements.
• local operating facilities• multi-layered communication
III. THE INDUSTRIAL CONTROL OFFERINGS• engineering tools for configuring, tuning anddocumenting•colorgraphic operator interfaces for process control view
A. Domains of applicationor system overview with logging, trending, archiving
and alarm management facilities
Industrial control systems have considerably developed•application support including installation,
since the seventies. They are present in industrial fields like
commissioning, training and maintenanceenergy production, electrical energy transmission anddistribution, phannacy, chemistry and petrochemistry, foodThe other category of supply is aiming at simplicity andindustry, metalworking industry, paper manufacturing,
low pricing. Their manufacturers have limited their offerings
glassworks, cement works, transportation, etc .. From thisto the bottom layers and have in mind the supply of·large variety of fields of applications, industry has gained a lotlaboratories, restricted test facilities, and non distributedof experience. Figure 2 shows the functional layers which
equipment. They offer:
have been identified by industry and on which common• PLCs with restricted capacity in number of 1/0 points
hardware and software is built, allowing the research and• simple communication (RS232, etc.)
developments cost to be shared between the different• limited graphic operator interface for process control
buyers [I).
view, with some logging, trending and alarm facilities• primitive engineering tools for configuring
MANAGBMENT INFORMATION SYSlllM

1
Sup

CBLLCOmROL

Sup

Gate

CHU. CONl'ROL

ARliA CONTROLIn order to fill in the gap between this smaJI scale solution
and the complete one, other companies have developed very
sophisticated process oriented application enablers software
packages on different standard hardware (PCs, Vaxstations,etc.) and software (UNIX™, DOS, OS/2™, etc.) platforms
They provide interfaces to most of the PLCs. They have an
unbeatable openness and attempt to integrate all the possible
features one might expect to help configuring, tuning andsupervising. A lot of attention has been paid to the application
programming facilities and environment with graphics andanimation editors, all kinds of operator inputs (keyboard,mouse, trackball, touch screen), math functions, logic
operations, batch functions, graphic and language baseprogramming facilities, time scheduled events and intervals,
real-time and historical trending, alarm monitoring,supervision and logging, report generation, etc.•

Figure 2. Industrial control functional layers

S07IC01
270

Industrial Control
270

C. The contenders
In the first category there are less than thirty suppliers in
the world and seven of them share more than two third of themarket (see figure 3). The actual solutions they propose arevery much proprietary. both at the hardware and software level.
Due to their size and the commitment to preserve theinvestments of their customers, they have to keepcompatibility during the evolution of their products. This is avery heavy constraint

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC01

IV. LEP ENERGY UPGRADE

A. LEP 200 new equipment inventory

LEP is the latest CERN leptons collider which came into
operation in 1989. Its energy is currently limited to 50 Gev
per beam but provision was made, at the design stage, formost of the equipment to allow for an increase in energy toalmost 100 Gev per beam, in a second round. This energy
increase project [2] is now on the way and is planned by theyear 1994. The major differences with the actual machinecome from the;'new 192 accelerating RF superconducting
cavities, which will be installed in the four even interaction
Honeywell 16%
points of LEP. Each of this even point will be equipped witha cryoplant [3] having a cooling power of 12 kW at 4.5 K
ABB Process Automation temperature. Other modifications concern:12%• the replacement of the eight superconducting low-betaquadrupoles for another set of eight with a higher
gradient (36 T/m-+55 T/m)
Yokogawa 10 %• two additional electrostatic separators at each even
Siemens 8 %Balley 9 %interaction point
Fishers%• new collimators at the end of the even arcs to shield the
Source: ARC 1990 DCS Reportsuperconducting cavities from synchrotron radiation• a few new beam position monitors• forty new power converters, which added to theredistributed existing ones will extend the possible
Figure 3. Worldwide DCS market sharesoperation energy of the magnets from 65 to 100 Gev•an increase in electrical power from 70 to 160 MW and
The second category is much more crowded and is occupied
by hundreds of equipment manufacturers. They could care lessits distribution• eight new cooling towers in correspondence with theabout customers' investments as the cost of their supply ismuch more affordable. The market is covered by equipment
electrical power increase
manufacturers, laboratories and simple test systems. Examples
of such supplier are Satt, Makmodul, SAIA, etc. . The big
B. lndustrial controls/or LEP 200
manufacturers of DCS are also offering products in thatcategory. Industrial control application enablers package
LEP has been completed in 1989. Although industrial
suppliers have names like FactoryLink™, Wizcon™,
controls have been sparsely used in cooling & ventilation and
InTouchTM, etc ..
emerging cryogenics, their general introduction was notsupported at that time by any coordinating body or task force.
D. Use of industrial controls in accelerators
The problem of their integration in the overall control system
was either treated as a single case or neglected. Since then, weAmong the two categories of components in an accelerator, have undertaken to study carefully the problems which will be
the passive components are the one which fit naturally with posed by their wider introduction trying, in association withindustrial control, as they run independently of the particle industry, to find harmonious solutions.
manufacturing process. Their processes do not fundamentally
The first opportunity is given by the LEP energy upgrade.
differ from those of similar equipment currently used in otherfactories, except for cryogenics for which there is not much As may be seen from the above list of modifications, theexperience in the world in the industrial production of very major change concerns RF superconducting cavities andlow temperature refrigerated helium.
cryogenics. The other modifications are either a replacement ora minor extension of existing equipment. Cryogenics is far the
The active components present to the control system very best candidate for a first full industrial control implementationstrong constraints. They are tightly coupled to the beam and, as it has a fair size, it belongs to the well fitted presumed
for an accelerator operator, are real-time process control category of passive components and HERA is making aelements. Those are normally attached to PLCs in an similar trial with it [4]. In addition, time is just right to makeindustrial control environment. Industry does not yet offer this attempt as CERN is facing new economical conditions
solutions matching large geographical spread together with where the budget has to be kept constant while the humantight real-time constraint

S07IC01
Industrial Control

271

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-S07IC01· resources are regularly reducing towards a twenty per centdiminution level.

planned for the end of this year in a joined effort with the
supplier.

A specification was worked out under the responsibility of
one cryogenics expert [5] who had the original idea of getting
the control industry involved. It included the supply,
installation and commissioning of:•the hardware to interface to the different components ofthe cryoplant. i.e. compressors, cold boxes and cooled
helium distribution• the operating consoles and peripherals• the basic system software with the various engineering
tools• the application software to run the processes andsupervise the overall installation. Definition of theprocesses is a joined effort between the cryoplantcomponents manufacturers and CERN cryogenics experts
The dimension of the overall cryogenics control system isin the order of 150001/0 connections. The tender gave several
positive responses, offering acceptable solutions and was
adjudicated in April this year.
Although some guidelines were given in the specifications,
integration in the CERN environment was left much more
open as the best solution has to be found through various
possibilities in a joined effort with the supplier.
The large area covered by the facilities existing at CERN
has imposed the building of a large and well structured
communication network on the CERN site. The basic
communication system is a Time Division Multiplex (TDM)
which runs over either coaxial cable or optic fibers, where thelevel of radiation permits it This. system follows the G703
recommendation of the CCITT [6]. The TDM offers a variety
of services for the operation of the accelerator: computer
networks, timing systems, data transmission, digital telephoneexchange, etc ••The operation team of the particle accelerator sits in the
Prtvessin Control Room (PCR). The specialized cryogenics
equipment will be controlled globally from a central location,
the Cryogenics Control Room (CCR). The processes
controlling cryogenics has to run inside computers situated ina Cryogenics Equipment Room (CER) near the equipment, allaround the accelerator. Figure 4 shows the basic layout

Supervision from the CCR needs reliable communication
between the CERs and the CCR. For this purpose, theindustrial control supplier was given the choice of either using
point to point links via special supplier proprietary interfaces
connected to private TDM channels or to make use of thecomputer network via the IEEE 802.5 (token passing ring) orIEEE 802.3 (Ethernet) standards. The usage of TCP/IP(Transmission Control Protocol/Internet Protocol) has been
recommended. Tests of the different solutions have been

Figure 4. Cryogenics in LEP 200

Cryogenics as a passive component does not need very
Light connection with the PCR. Cryogenics process operatingstates, a subset of the alarms and general diagram displays are
sufficient to inform the accelerator operators of the cryogenics
behavior. But provision has been made to allow for some
restricted and well protected commands in order to get rid of
eventual abnormal process behavior waiting to be understoodand cured.
Industrial control suppliers currently offer solutions basedon standard platforms to connect their system to the plant
network. One µVAX 3100 running VMS and linked to
Ethernet will give this possibility, by means of an accesslibrary available from the supplier, to access any equipment
connected on its control system. Accelerator operation oriented
data collection and restricted access will be easily
implemented. All this is planned for installation before the endof this year.

V.LHC
A. LHC equipment inventory
LHC is the future CERN Large Hadron Collider to beinstalled above LEP in the same 27 kilometer tunnel. Thismachine will accelerate particles and hold them on a circular

S07IC01
272

Industrial Control
272

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC01

orbit by thousands of superconducting electromagnets, cooled decade. The control industry and CERN have clearly adown at a temperature of 1.8 K [7). These will be the most common approach which could well come out into somechallenging equipment as they require a huge cooling capacity. active collaboration in view of the LHC project.
For this purpose, it is foreseen to increase to 18 kW the
VI. CONCLUSION
cooling capacity of the four refrigerators which are to beinstalled for the actual LEP energy upgrade. In addition, newPassive components of an accelerator are the mostrefrigerators will have to be installed in the odd points. An
extension will have to be added in order to lower the promising equipment for which industrial controls solutions
temperature to 1.8 K. The required 16 MY RF voltage will can be easily found. However if this would be rather easy toalso be provided by superconducting cavities.
realize in a free environment, the implementation could prove
much more difficult in the two major CERN projects of this
LHC is a complete new machine and requires the decade, LEP 200 and LHC once approved, as most of theinstallation of a large number of new equipment of the active eligible new equipment will mostly appear as extensions.
component category. The same requirement applies for the Nevertheless the opportunity could also come for LHC fromvacuum in the passive components category, but electricity, aging equipment considerations, knowing the tremendous
cooling & ventilation, cryogenics, personnel protection and speed of evolution in the control domain. Meanwhile, asidesite access will just require some extension to existing ones accelerator prospects, there are other domains of applications
for LEP, if any.
in a laboratory like CERN where the industrial controls fit
naturally. These are all the basic services like heat production,
The big difficulty will come from the sensitivity of the water distribution, general electricity (back-up electricalsuperconducting electromagnets to quenching under beam loss. supply, distribution, etc.), etc. and the large bench test
Some of the active components will have to cooperate rapidly facilities needed to validate the numerous accelerator equipment
through computers to try to prevent this from happening [8]. before installation like magnets, RF cavities, etc. Basic
It is premature to say that industrial control systems will be services are already largely committed to industrial controls
unable in more than 5 years from now to cope with such but their consolidation will need much more homogeneous andrequirements. The question has not yet been debated with integrated solutions. Large test facilities have factoryindustry and has not the first priority in this preliminary dimensions and are very much concerned with the traditional
industrial controls evaluation.
industrial production concepts. Industrial controls will play avery active role in all these domains in the very near future andthere
is no doubt that a huge experience will be gained for the
B. Industrial controls for LHC
benefit of our accelerators.
The extension of cryogenics has already been foreseen in
the contract with the industrial control supplier. A dimension
of up to twice the size of the actual system could be envisaged
without causing any problem.
Supposing hopefully that the cryogenics experience turns
to be positive, the people responsible for other components inthe passive category will have the difficult decision of opting
for the extension of their process control system or for anindustrial one. Important parameters of the decision will be thesize of the extension, homogeneity, maintenance, training,
consolidation, human and material cost, etc .. Replacement ofexisting LEP process control equipment to put the extension
in a global industrial control solution might be even desiredby the process experts but could prove to be difficult in theactual context of budgetary constraint.
Industrial control suppliers are fully aware of theimportance of international standards. In the next few years,
the traditional proprietary approach will be abandoned infavour of standard based solutions for all the products which
will be supplied. This will range from basic hardwareinterfaces to operator consoles, from operating systems tosoftware engineering applications. Openness and Management
Infonnation System will be the magic words of the nextVII. REFERENCES[1] Control Engineering, October 1989.
[2] C. Wyss, The LEP energy upgrade programme, Proceedingsof the 1991 Particle Conference, San Francisco, USA,1991.
£31 M. Barranco-Luque, J.-P. Dauvergne, W. Erdt,
P. Frandsen, D. Gllsewell, F. Haug, A. Juillerat,
G. Passardi, J. Schmidt, G. Winkler, The refrigeration
system for the LEP upgrade, XIIIlh International Cryogenic
Engineering Conference, ICEC13, Beijing, China, 1990.
[4] H.R. Barton, Jr., M. Clausen and G. KeBler, Cryogenic
system for lhe HERA magnet measurement facility, Xllh
International Cryogenic Engineering Conference, BerlinWest, Gennany, 1986.
[5] J.-P. Dauvergne and all, Technical Specification for !heProcess control system for LEP 200 cryogenics, CERN,
Geneva, Switzerland, 1990.
[6] Digital networks: Transmission Systems and Multiplexing
Equipment, Recommendations G700-G956 (CCTIT, Geneva,
1985).
[7] Design study of the Large Hadron Collider (LHC),CERN 91-03.
[8] K.H. Kissler, F. Perriollat, M. Rabany and G. Shering,Controls for the CERN Large Hadron Collider (LHC),
Proceedings of !his conference.

S07IC01
Industrial Control

273

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 Control274

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingconsequences have intensified within the past few years withthe trend towards a higher degree of distributed processing,modem
made possible through the application oftechnology.
In fact, if reaction time is virtually no problem as in ourapplications, distributed processing can largely be replacedby central processing (data 'harvesting'), using sub-systems
mainly as remote 1/0 stations. Local processing can be
restricted to those tasks requiring a really tight control overthe process thus reducing the communication traffic andfreeing the central system, or to mask hardware peculiarities.
This reduces the amount of code to be written for thecommunication between the sub-systems. Softwaredevelopment is also speeded up due to the usually superior
facilities available on the central system.
The facilities for the development of the remaining subsystem code should still be adapted to the amount of code to
be delivered (e.g by using cross software on PCs).
With the distances (and sometimes also the number ofsystems) involved the possibility to download code rather
than to change BPROMs has also become mandatory.

resistors on both ends forming a segment. Such a segment
can have a maximum length of 0.3 km hosting up to 28'nodes' when operated at a speed of 375 kbit/s. Ha speed of
62.5 kbit/s is used, and with 10 repeaters, a maximum lengthof 13.2 km can be reached. The maximum number of slavenodes is 250. The communication is based on messages(order-reply) exchanged between nodes. The nodeconnectivity is master-slave-slave-... with the master node
usually residing in the host interface.

D. Field Bus
The proper choice of a field bus is a key item in that thefield bus constitutes the same for the equipment electronics
as a network for the process controllers and other computers.
To a certain extent it predetermines the type of equipment to
be used. Generally spoken, the adherence to industrial
standards widens the choice for off-the-shelf acquisition ofmaterial.
Besides the obvious criteria like reliability (recognition oftransmission errors), sufficient speed and extensibility, andreasonable cost we consider a good multi-vendor support
essential. The applied field bus should be able to host equallydifferent types of induslrial equipment as well as existinghome-made equipment.

III. THE BITBUS
A. General Remarks
We find that the Bitbus fulfills our criteria for a field bus
in a nearly ideal way and devote therefore some room for its
discussion.
The Bitbus is a high speed serial control bus which wasdeveloped in the early eighties mainly by Intel [l] and which
has meanwhile found a broad worldwide distribution. In fact,
it has become one of the de-facto standards for industrial
control applications. It is already being applied in otherphysics research institutions, e.g. in [2, 3, 4].

C. Data Integrity
A subset of the SDLC protocol (= Synchronous Data
Link Control) by IBM is used as transmission protocol
describing the data exchange and the access rights of thedifferent nodes. For assuring the correctness of delivered andreceived data a CRC (= Cyclic Redundancy Check) method
is employed.

D. Node Structure
Each node contains a 8044 microcontroller built up
around the 8051 microprocessor. These controllers run themulti-tasking operating system DCX-51 contained in
finnware. The communication between the master node andthe slave nodes is performed at the task level, i.e. thecontrollers take care of the communication between nodes
using Bitbus messages. In each node the task 0, called RAC(= Remote Access and Control) task mediates the accesses
from the applications to the 1/0 port of the nodes. The DCX51 permits to run up to 7 user tasks in addition which can beused to perform local processing if desired. This is aparticularly attracting featiire since one is not obliged to write
any node software to read or write 1/0 ports, but provides aproper framework in case one needs to do something more.

E. Software Tools
The software development for the nodes can be done
'cross' on PCs under DOS (or e.g. on a workstation running a
DOS emulation) either in PLM/51, in C, or in ASM/51(assembly language). Afterwards, the code is downloaded.
The allowed code size is typically about 32 kbytes.
For the communication between DOS-~ed hosts and thenodes exist high-level interfaces to the usual languages.
Monitor programs of several suppliers allow to perform allbasic functions on the nodes or to check the actual hardware
configuration on the bus.
A driver to use the Bitbus on PCs running the real time
operating system LynxOS as proposed for the future use in
all process controllers at the CERN accelerators [5] iscurrently under development.

B. Basic Characteristics
F. Multi·vendor Support
Electrically the Bitbus is based on the RS-485 standard. It
uses twisted pair wires for transmission with termination

The widespread support the Bitbus has found is reflected

S07IC02
Industrial Control

275
275

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-S07IC02

ICALEPCS1991, Tsukuba, Japan· in the number of interfaces available to different hostsystems: There exist links to VME, PC, Q-Bus (µVAX),Multibus-II, and the SMP-Bus, partly also from several
suppliers. A SCSI interface developed recently [6] allows toconnect Bitbus based systems also to workstations, forinstance.
On the node level, there is also a great number of possible
choices with different characteristics and fonn factors: 1/0
modules with fixed functionality, modular 1/0 systems
consisting of a crate with a node controller and various 1/0
modules, programmable logic controllers (automata), or PCs
used as slaves nodes. The recent development of a Bitbus
node controller with G-64 interface [7] permits now tointegrate also electronics based on this standard. Last but notleast, piggy-back nodes are available for direct implantation
into special equipment.
This multi-vendor situation is advantageous whenselecting the appropriate components due to the competition
between suppliers.
The recent implementation of the Bitbus protocol on the
newer microcontroller 80C152 (offering enhanced
possibilities, but remaining backwards compatible) indicates.
that this concept will retain its importance over the next
years.

access facilities, e.g. fast data logging and fault detection.
The use of the Bitbus as field bus is envisaged for all subsystems needing few or no specific processing, for others theconnection can be made using RS-232 links between aprocessor in the G-64 crate and the process controller via a
Terminal server (this would have the advantage that no
additional driver software is required). Necessary industrial
measurement devices like digital storage oscilloscopes will
be branched using a GPIB link.
b) In case of more standard requirements (e.g. for the LEP
Pretzel beam separators) the 1/0 hardware will predominantly
been built up using industrial components, preferentially inContent 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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC02

accelerator network
workstation

PC
process controller(diskless),

GPIB(IEEE-488)

~,

C-:'
en ,

file server

measurement
device~.

G. Experience

BITBUS(IEEE-Pl 118)

To test the feasibility of the Bitbus in our environment weinstalled a PC together with a Bitbus node in an equipment
hall and connected them through a non-shielded twisted paircable of 15 m length, with the Bitbus loosely traversing an
area heavily perturbed by fast high current discharges fromone of the SPS injection systems. The system run over
several days without halting or producing transmission errors.
For test setups in the laboratory we simply use flat cable.
The use under DOS is greatly simplified due to the available
good software support in form of high-level language
interfaces, libraries, and monitor programs.

specific I/O(G-64)

standard I/O(industrial)

100-300m

IV. ARCIIlTECTURE
portable PC

The full controls concept actually pursued comprises thefollowing ingredients (please refer to figure 1).
to I from accelerator devices

A. General layout

On the level nearest to the equipment two major cases canbe distinguished:a) In case of dominant specific requirements (as e.g in the
LEP beam dump) the I/O hardware will mainly consist out of
G-64 or Eurocard form factor modules, as practised in thepast for similar applications. Inter-crate wiring is to a large
extent done using coaxial cables. Built-in front panel
elements are used for basic local control. Diskless industrial
PCs running DOS are foreseen for certain applications which
require greater local processing power and better display andFig. 1: Overview of the pursued concept
the form of modular I/O systems housed in Eurocrates andlinked to the Bitbus or also to RS-232. Necessary mck
cabling will be done in front-side cable channels, using
ribbon-type multi-pole connectors with screw terminals. The
indication elements already contained in the I/0 systems will
be complemented by relatively simple control panels to allow
local control in case of malfunctioning of the higher levels.
To provoke actions when servicing in remote areas (e.g

S07IC02276

Industrial Control276

in the accelerator tunnel) portable PCs will be used. The
desired actions will be provoked by communication with theprocess controller via the Bitbus.

B. Node Software
The software to run on this level will be restricted to theminimum. Typical examples are routines taking care of
hardware particularities or the transformation of
measurements into data directly useable by the higher levels.
The software for the Bitbus nodes will be cross-developed in
PLM/.51 on PCs running under DOS (or alternatively on
workstations with a DOS emulation) and then stored on thefile server for downloading. The software for diskless PCs on
the Bitbus can be developed using standard PC tools like
Turbo Pascal or Quick C and will stored in non-volatilememory.

C. Process Controller
All equipment specific electronics will be connected tothe process controller put to our disposal by the SPS/l..EP
controls group as described in [.SJ. This device, an industrial
PC running under the real time operating system LynxOS, isdirectly connected to the accelerator network. This PC will
be disldess, possessing sufficient memory to run, besides thegeneral software, the equipment specific control software
without the need for swapping. The required code will be
loaded at boot time from a file server which will also be
used to store historical data for later analysis.

D. Local Control and Diagnostic Software
The implementation of X Windows on these systems lays
the ground for the implementation of the required goodequipment specific control and diagnostics software
including graphics, to be used simultaneously for local andremote access with interaction possible through workstations,
X terminals, or PCs under LynxOS or under DOS.
Such a software, at the same time aimed at grouping ourvarious needs into one configurable package, is currently
being developed and described in [8).

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC02

V. CONCLUSION
Due to the continuous progress in automation industry,
many different types of I/O systems have become available
which can directly be used for slow controls applications at
accelerators. Home-made equipment can easily be integrated.
The choice of the communication link to these systems isimportant. The use of an open, non-proprietary link like
Bitbus, allows, for many of our applications, off-the-shelfacquisition of a variety of systems from different suppliers.
This permits to concentrate our efforts on system
integration and on the more specific accelerator control
electronics which remains to be designed in our laboratory.
VI.ACKNOWLEDGEMENTS
The continuous support of the SL/CO group and theirefforts for providing the necessary general hardware andsoftware infrastructure are gratefully acknowledged.
Many thanks go also to the DEC Joint Project Office at
CERN for the generous and informal help.
The authors would like to thank the organizers of thisconference for their efforts.

VII.REFERENCES[l] INTEL, The Bitbus Interconnect Serial Control Bus
Specification, Ref. 28064.5-001, 1988.
[2] INFN, Milano, Italy, D. Giove, private communication.
(3) EPFL, Lausanne, Switzerland, J, Lister, private communication.
(4) KVI, Groningen, The Netherlands, P. Kroon, private
communication.
[.5] R. Rausch and Ch. Serre, "Common Control System for
the CERN PS and SL Accelerators", this conference.
[6] INCAA Computers, Apeldoom, The Netherlands.
[7] INCAA Computers, Apeldoom, The Netherlands, andJ. H. Dieperink, CERN, private communication.
[8] A. Aimar, E. Cartier, V. Mertens, "An Open Software
System Based on X Windows for Process Control
and Equipment Monitoring", this confei-ence.

E. Test Setup and Status
The key ingredients of the presented architecture havebeen set up in the laboratory using a disldess DECstation.5000/125 to simulate the final process controller, withanother workstation acting as remote file server. The Bitbus
has been attached using a SCSI-Bitbus gateway. Since thisdevice is conceived to simulate an already existing SCSI
device there was no need for writing special driver software
thus pennitting to advance more rapidly. PCs under DOS areused in some smaller test applications and for development of
node software.

S07IC02
Industrial Control

277

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-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 Control278

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

ICALEPCS1991, Tsukuba, Japan

services. The maximum periodic repetition ratecurrently available is 60Hz. Using interrupt on
end-of-conversion hardware allows for rates higher
than 60Hz. The fully distributed database allows 1/0
controllers to be easily added to take on additionalloading.

any field in any database distributed throughout the
network via the channel access communication bus.
The display manager allows the application engineer tobuild display hierarchies that use the windowing
capabilities of modern workstations and personal
computers.
The display editor and display manager run underUNIX and the X-window system. Running the display
manager on the SUN IPC. display call-up of 1,000
static graphic elements and 100 dynamic graphic
elements has been benchmarked at less than two
seconds with an update rate of 10,000 monitor
elements per second. The SPARC station I and II andgraphics accelerators can be used to provide evenhigher performance. Using a client that is not in thesame machine reduces the performance of the client byaround 3%. The display manager and editor have been
run on X servers on the VAX/VMS under Decwindows
and the 80386AT/MSDOS under Microsoft Windows
3.0 using the HCL-eXceed/W X-server. EPICS
imposes no limitation to the number of operator
interfaces that are on the control network.
The screens for display are configured using agraphic display editor (EDD). EDD can be usedthrough text input or interactively. The X-basedgraphics editor provides a wide range of ·helpful
functions for producing professional displays quickly
and easily. Non-technical people have been trained to
produce displays in les's than 1 hour. Process displays
are produced in hours. The displays are automaticallyconnected to the operational parameters by name. No
knowledge of the I/O location is needed at display
configuration. Display elements are predefined formonitoring and modifying any parameter on the
network, producing display hierarchies, strip charting,and plotting synchronous events. A single display canbe built, then invoked many times for different
instances of a similar device or subsystem. For
instance, a screen can be built for one vacuum stationand invoked for each vacuum station, greatly reducing
the creation and maintainence of the displays. Theease of use has greatly reduced the time to create andmaintain displays.
Many devices have been added to the display
manager. In addition. X applications can be written to
run in conjunction with the display manager. Using the
X windows environment also allows users to takeadvantage of other packages that are available
commercially and through EPICS.

D................

Interface
Consoles(Workstations)D........
........

File
Servers

Input-Output
Controllers(VMENXI)

Figure 2.

Physical subsystem layout of EPICS.

The database for each I/O Controller is configured
oftline, using the Database Configuration Tool (DCT).
DCT is a menu based configuration tool written in 'C'
using the Curses library. Channels are added andmodified either interactively through DCT or througha text file. The commercial database package,
PARADOX, has been used to produce text input to
DCT. A variety of reporting facilities to help document
the application is also provided in DCT. The databasesuccessfully provides data acquisition, conversion,
notification, and closed-loop control without any
applications programming.
The scan tasks and drivers supporting the
distributed database can be easily extended. The
device driver library is continually expanding tosupport new I/O buses and additional modules on
existing I/O buses.[3] A database record is provided
which invokes 'C' subroutines in the context of the scantasks. New record types can be added to supportcomplex device types or new algorithms. Outside therealm of the database, the IOC can be extended bywriting sequence programs or tasks running directly
under vxWorks that interface to the database using
channel access.

III.

THE DISPLAY MANAGER

The display manager provides an interface
between the operator and the control systemf4]. The
display manager is capable of monitoring or modifying

IV.

THE ALARM MANAGER

S07IC03
Industrial Control

279
279

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

Operator

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC03

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

The alarm manager is used to create fault trees for Many instances of the archiver can be run on thealarm presentation to the operator[5]. The warning control network.
The archive requests are currently configured
and alarms are configured in the database. The alarm
manager monitors and groups these alarm conditions using a text editor. The format of the text file isinto a fault tree for presentation to the operator. On predefined. The configuration file is converted to aselecting the highest group, the alarm manager binary file at initialization.
automatically traverses the fault tree until arriving at
VI. THE SEQUENCER
the unacknowledged alarm or the first ambiguous
The sequencer executes state programs[6][7],branch. The groups can be set up to disable on given
machine parameters such as operational mode. The which run on the 1/0 controllers. The user can build
alarm manager provides a useful tool for steady state state programs using the state notation language that
operation, allowing the operator to react to excursions are compiled and loaded into the 1/0 controller atfrom normal operations.
initialization. The state notation language takes the
The alarm manager currently runs under UNIX. I/O controller through modal changes. It can be used
The interface to the control system is channel access. to switch between different operational modes (i.e.
The alarm manager can be run on many workstations warm up, ready, operate, shut down) or to handle
where each instance can run any alarm configuration. exceptions (i.e. vacuum leak detected- go to safe state).
The alarm hierarchy files are currently configured The state notation language has a syntax designed tousing a text editor. The format of the text files is make implementing state transitions easy. The state
predefined. The configuration files are converted to a notation language features transitions for time andbinary file at initialization. The system engineer who events. Connections to the database on the network aresets up the alarm configuration can put in guidance for handled by assigning a database name to a variable. 'C'
the operator. A screen in the display manager can also statements can be placed in the state program. Using
be invoked from the alarm manager to aid the operator the state notation language alleviates the need to know
in'handling the exception.
channel access or vxWorks internals. reducing thesource code by approximately 75%.
V. THE ARCHIVER
VII. CHANNEL ACCESS
The archiver is used to .collect data from the
Channel access is a 'software bus' provided tocontrol system to disk. Data collection for each data communicate between various EPICS subsystems[8].
request is initiated and discontinued based on time or It allows the system components and user extended
the condition of any parameter in the distributed components to perform channel connections, gets,database. More than one request can be active on each puts, and monitors on any field of the distributed
workstation. The archive data retriever allows users to database using the TCP and UDP protocols. Channel
select channels for retrieval and examination. Data connections are performed by connecting a uniquethat is older than one minute is available through the channel name to the IOC containing the channel.
archiver during operation. The archived data can be Channel access provides notification to its clientsplotted against time or as functions of other channels. when a connection is broken and another notification
The plots can be converted to postscript and printed, when it reconnects. This connection management isor they can be converted to encapsulated PostScript used to keep all subsystems informed of the status ofand included in word processors like Interleaf. Data the other IOCs, on which it may depend for parametercan also be formatted as input to either LOTUS or information.
EXCEL. The archiver provides a program interface
Channel access services are available under UNIX
into archived data as well. This feature allows the user on the 68xxx and SPARC series processors, underto write data analysis codes that directly interface to VMS, and under vxWorks on the 68xxx based
the archived data. The methods for accessing archived processors. The interface routines are in 'C', These
data facilitate data analysis for experimenters and routines are used by the I/O controller, display
application engineers.
manager, archiver, alarm manager, and the sequencer
The archiver runs under UNJX and can collect for communication.
5,000 channels per second. The archiver uses channel
VIII. EVENT SYNCHRONIZATION
access to access parameters of interest on the network.

S07IC03280

Industrial Control
280

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

ICALEPCS1991, Tsukuba, JapanEPICS is equipped with a timing system thatprovides event synchronization across the network.
Through a hardware/software solution, events can be
accurately correlated in distributed I/O controllers.
These events provide data with time stamps that areused by the archiver and operator interface toaccurately analyze synchronous data sets in real timeand for historical data. In addition, the timing systemprovides the ability to process data on sub-harmonics
of the base rate of the physics machine. This allows
data taking to occur on the same Nth event acrossIOCs on the network. The timing system is designed torecover from communication failures and IOC
initialization during operation. The timing system has
undergone rigorous testing before being used on the
Ground Test Accelerator.

producing better results with less expense to eachindividual program.

XII.

The initial design and implementation of EPICS
was done by the Controls Group of the Los Alamos
Accelerator Technology Division. In it's previous
incarnations EPICS was known as the Ground Test
Accelerator Control System (GTACS) and the Los
Alamos Accelerator Control Systems (LAACS).
EPICS is currently being co-developed by the
Accelerator Technology controls group at Los Alamos
National Laboratory and the Advanced Photon Source
controls group at Argonne National Laboratory.
Specification, design, implementation, verification,and configuration control has been performed by thefollowing group:
J.B. Anderson (ANL), M.D.
Anderson (ANL), B.C. Cha (ANL), R.A. Cole (LANL),
L.R. Dalesio (LANL), C.E. Eaton (LANL), B.A.
Gunther (LANL), J.0. Hill (LANL), D.M. Kerstiens(LANL), M.J. Knott {ANL), A.J. Kozubal (LANL),
M.R. Kraimer (ANL), F.R. Lenksus{ANL), W.P.
McDowell (ANL). G. Slentz (LANL), M.E. Thuot(LANL), R.C. Zieman (ANL). EPICS continues to
evolve as new perspectives are provided and newchallenges are met. The evolution is directed atproviding better control tools to the experimental
physics community.

COMMERCIAL IMPROVEMENTS

Upgrades to the EPICS hardware and software are
becoming commercially available, and require little
effort to integrate. The IOCwill soon upgrade from the68020 to the 68040 processor. An FDDI backbone forthe distributed network is currently available, but has
not been required at any of the EPICS installations.
Version 5.0 of vxWorks provides performanceenhancements to the network communication, task
switching, and semaphore handling. The standards
upon which EPICS is built, are continually improving
in performance.
X.

XIII.

EPICS SOFT'WARE EXTENSIONS

Upgrades to the EPICS software are underway formaking the system easier to configure and diagnose.
and provide more functionality. Upgrades are being
implemented to provide interactive X-based
configuration tools for the database. archiver, andalarm manager. Extensions are planned for the display
manager to include polygons. The display editor isbeing extended to include object grouping. Devices
and database record types will be added as required.
XI.

ACKNOWLEDGEMENTS[l)

REFERENCES

Dalesio, L. R., "The Ground Test Accelerator
Database: A Generic Instrumentation Interface," inAccelerator and Large Experimental Physics Control
Systems, D. P. Gurd and M. Crowley-Milling, Eds.
(ICALEPCS, Vancouver, British Columbia, Canada,1989), pp. 288-291.

121

Dalesio, L. R., "The OTA Control System Database:Configuration, Runtime Operation and Access," inProceedings of the 1989 IEEE Particle Ace/erator
Conference. (PAC, Chicago, II., USA, 1989), pp.

CONCLUSION

1693-1694.

EPICS has been successfully applied to many
applications[9-131. The tools that are available havebeen used to provide data acquisition. supervisory
control, closed-loop control, sequential control, anddata archiving. All functional requirements have been
met with the existing architecture. Extensions areunderway to make the configuration of EPICS easierand further improve the throughput. The EPICS
collaboration continues to provide useful tools for(3]

Arnold, N.R., Daly, R.T., Kraimer, M.R., McDowell,
W.P., "l/0 Subnets for the APS Control System,"
submitted to Particle Accelerator Conference, San
Francisco, California, May 6-9, 1991..

[4 ] Hill, J., Kerstiens, D., and Dalesio, L.R .• 'it\ Virtual
Control Panel Configuration Tool for X-Window
System," submitted to ICALEPCS, Thukuba. Japan,
Nov. 11-15, 1991.

S07IC03
Industrial Control

281
281

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

IX.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC03

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[5]

Kraimer, M.R., Cha, B.C., and Anderson, M.D.,"Alarm Handler for the Advanced Photon Source
Control System," submitted to· Particle Accelerator
Conference, San Fra11cisco, California, May 6-9, 1991.

[6]

Kozubal, A. J., L. R. Dalcsio. J. 0. Hill, and D. M.
.Kerstiens, "A State Notation Language for AutomaticControl," Los Alamos National Laboratory report
LA-UR-89-3564, November, 1989.

[7]

Kozubal, A. J., ·~utomation From Pictures: Producing
Real Time Code from a State Transition Diagram,"
submitted to ICALEPCS, Thukuba, Japan, Nov. 11-15,
1991.

[8]

Hill, J. 0., "Channel Access: A Software Bus for the
LAACS," in Accelerator and Large Experimental Physics
Control Systems, D. P. Gurd and M. Crowley-Milling,
Eds. (ICALEPCS, Vancouver, British Columbia,
Canada, 1989), pp. 288-291.

[9]

Atkins, W., "Using the EPICS Sequencer Tool to
Automate the GTA Vacuum System. " submitted toParticle Accelerator Conference. San Francisco,California, May 6-9. 1991.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC03[10] Wilson, William L., Marcus W. May, and Andrew J.
Kozubal, "Rapid Development of a Measurement andControl System for the Advanced Free-Electron
Laser," submitted to Thirteenth International
Free-Electron Laser Conference, Santa Fe, New
Mexico, August 25-30, 1991.
[ 11] Knott, M.J., McDowell, W.P., Lenkszus, F.R., Kraimer,
M.R., Arnold, N.R., Daly, R.T., Gunderson, G.R., Cha,
B.K., and Anderson, M.D., "The Advanced Photon
Source Control System," submitted to Particle
Accelerator Conference, San Francisco, California,
May 6-9, 1991. .
[12] Eaton, C.E., Little, C.K., Martz, V.E., Glasscock, R.B.,
Carlson, G.W., "GTA RF Control," Los Alamos
National
Laboratory
report
LA-UR-89-948,
November, 1989.
[ 13] Schindler, J., Bemis, M., Gonder, J., Oberg, D.,
Wright, R., "RF Control and Diagnostics for the
Average Power Laser Experiment (APLE)." submitted
to the 13th International Free-Electron Laser
Conference. Santa Fe, New Mexico, August 25-30,1991

S07IC03282

Industrial Control

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

ICALEPCS1991, Tsukuba, Japan

assigned to the front end while the slower more complex
processes are placed in the back end. This organization
naturally allows the high-speed controls to be distribu1ed
near the 1/0 interface when needed. The interface between
the front and back ends is shown as a database. This will
likely consist of several different types of databases coupledwith data access and communications management software.
Jn operation the front end continuously updates the databaseat a rate which would maintain a near real-time snapshot of
the control points. The back end has high-speed random readaccess to the data as needed by the different applications.
Commands to change output settings nonna11y must passvarious sanity and permission tests before being committed
to the hardware. They are best processed as messages.
A three level architecture is suggested for the front end.
The global level is the central SSC control room. All datafrom the accelerator complex is available at this location.
The global level supports a back end for all process
subsystems and other higher-speed SSC controls. Low-level
functions executed at this level are able to span the entire
accelerator complex. The regional level would cover a partof the accelerator or a major component. A· regional system
would have access to the regions data and would support
back ends but only for hardware covered by the region.
Regionally supponed operator interfaces are intended forcommissioning, maintenance, and emergency backup. It isenvisioned that most of the low-level control functions would
be executed at the regional level. The bottom level contains
the hardware interfaces. Each system can see only the 110
interfaced directly to it. The primary function of thesesystems is to act as a concentrator for control points. They
will support minimal operator interfaces for maintenance.
When needed low-level control functions can be added to aninterface level system. There is I global level system, lessthan I 00 regional level systems, and 2000-3000 interface
level systems.
A basic feature of the SSC control system will be the useof telephone technology based communications in lieu ofLAN based communications. The idea is to provide a large
number of independent point to point communications paths
with dedicated band width over a TDM system. There is nodegradation ofperfonnance even if all paths operate at 100%
capacity. The telephone industry continues to push IDM
technology to higher data rates thus giving rise to the notionthat communications is not a limiting factor in the design ofa front-end system. For a LAN based system this is not thecase. Since performance decreases with increasing load one
must design a system which minimizes communications
usage.

A possible set of communications links between the threefront-end system levels is shown in Fig. 2. Each interface
level system is connected to a regional and the global
systems. Regional systems also connect to the global system.
Thus the interface level delivers the same communications
performance to both the regional and global levels. This
would not be the case if the data had to flow through theregional system on its way to the global system. Dependingon the TDM configuration this scheme allows for redundantcommunications paths. The role of a failed regional
processor could be picked up by the global system thus
providing backup processing without having to supply aduplicate of each regional level system.
The communications protocol over the IDM links may bechosen to minimize data and processor overhead. It bas been
decided to implement communications using reflective
memory. Reflective memory is similar to a shared memory
except that instead of one physical memory being shared by
two processors there are two memories connected by ahardware implemented communications link. When a value
is changed in one memory there is a small delay before it isreflected in the other. Hardware implemented reflective
memory reduces the communications overhead on theprocessors to memory access. Such a link is proposed for theconnection between the global and regional systems. This
would aUow the global system to monitor and change theparameters of the regional low-level function processing andprovide a consistent basis for switching from regional to
global back·up control. Note that this communications linkis only for front-end operation. The regional and global
systems are also connected by LANs for other types ofcommunication.

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

REGIONALMERFH:E

Figure 2. Front-end system communications links.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC04

READ CH.Y llEA.ECTIVE MEMOf!Y

INTERFloCE S'fSTi;M

Figure 3. Communications model for the global/regional
to interface level links.
Communications with the interface level systems uses a
modified form of reflective memory. This is outlined in Fig.
3. Effectively one combines packet (serial) communication
with read-only reflective memory at the upper level end of
the link. The high-end communications interface interprets
some messages as reflective memory updates and others as
serial communications. The link to the interface system uses
only packets. This scheme takes advantage of the above
mentioned message nature of commands and the fact that
control points are more often read than written. Thus asingle link can serve both reflective memory and serial
communications. This provides for program down loading,

S07IC04
284

Industrial Control284

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

ICALEPCS1991, Tsukuba, Japan

remote debugging, and hardware interface testing. Finallythe communications interface is simplified for the front-end
level which has the most systems.
The global and many of the regional systems will
integrate controls from several process subsystems and/or
higheMpeed accelerator subsystems. Exact details of the
hardware and software for these systems are beyond thescope of this paper. Of importance to the process controls
front end is the need for a database and software to manage
the configuration of and access to the reflective memory
data. A second database would provide a repository forsystem run time parameters like set points or alarm limits.
The former database is a constant of the hardware
configuration while the latter could change dynamicallyduring accelerator operation. These databases are extracted
from a central configuration database and must be
maintained consistent between all systems. This will beaccomplished using communications links and softwareoutside of the front-end system.

integrating with reflective memory and parameter accesssoftware to minimize execution overhead.
The hardware and software at the interface level would beentirely within the front-end system domain. It is envisionedthat interface systems would be based on an open, industrial
standard bus supported by a number of vendors supplying
inexpensive industrial interface cards. An interface crate
would contain a IDM communications card and a minimal
110 processor, IOP, whose task was to manage
communications. When needed a second processor could be
added which provided PLC functions and had its own
communications capability. The IOP would provide data for
the PLC at the same rate as the regional and global levels.
Fig. 5 shows a schematic of systems with and without theoptional PLC. Interface level systems would allow direct
terminal attachment for bench testing and/or emergency lowlevel interface maintenance. Part of the general control
system architecture is an operator station network thatconnects the global and all regional level systems with
opera1or stations. This network will extend to all technicalareas. With a ponable operator console it will be possible totest the entire control system linkage to a given device while
being at the device location.

ON OEMAHO EXECUTION:

COMWoHD PERJ.llSSIOll I
NTEll..OCI< CHECKNQPAAAMETER~T!ON

a..EUED EXECUT!Cfol:
CONTRCl. LOOP$REFLECTIVE IO

Al.ARM MONITOANGOTHER l()W{.EVEI. fl..WCTIOHS

MEMOll'I

MAAMETER
0.0.TABASELOCALYEMORI'

CODE
11.0CKS

Figure 4. Components of the global/regional level server
process for low-level control functions.
The global and regional systems support the front-end
system process which provides a server for the low-level
control functions. A schematic idea for this process is shown
Figure 5. Schematic of interface level systems wilh andin Fig. 4. It would contain a large number of more or lessindependent code segments each of which carries out some without an optional PLC. Connections to upper levelspecific control function. The code in these blocks Oikely systems are also shown.
tokenized) could be executed by an interpreter which
The proposed front-end system is a combination of bothsupported several specific languages for different types ofand software. Care must be taken in designing the
hardwareblocks (e.g. ladder logic, control loops, alarm logic, data
softwareforseveral reasons. First there are a large number
transformation, etc.). These blocks would have access toreflective memory data, parameter data, and local data which of 110 processors, regionaVglobal level code blocks, andwould be reflected between regional and global systems. A perhaps interface level PLC systems. Secondly, this software
block manager would be able.to dynamically add and delete is very dependent on the configuration of the interface
blocks from the list, schedule their execution, and monitor hardware. Next the system levels are linked through theblock memory access. It should be possible to safely modify layout of the reflective memory. Finally, considering thecontrol strategies for various devices without shutting down wide variation in controls at the SSC it is unlikely that there
the whole system to make the changes. Blocks could be will be the uniformity between systems which would allow
scheduled for repeated execution in various queues thus programs to be used in a large number of systems with only
fonning a kind of PLC. Other blocks could be run on minor modifications.
For these reasons it is impractical to consider
demand to provide interlock/pennission checking or
programmingeach system separately in traditional ways.
transformations from raw values to engineering units. This
process should be maximized for efficient block execution by The software generation must be automated to a large extent.
perhaps running on dedicated hardware and closely One way to accomplish this is shown in Fig. 6. Here themain technical database which holds the configuration of the

S07IC04
Industrial Control

285

285

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 DOIREGIONAi.. / CJ..OIW. LOWUVEI. R..tlCTICW PROCESS (PLC)~~

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC04

ICALEPCS1991, Tsukuba, Japan

accelerator and control system forms a data source toautomate the program generation. This database provides theconfiguration of the renective memory to the regional/global
systems and provides crate configuration, 110 anachment,
and reflective memory update message fonnat information to
an intermediate compiler which generates the IOP code.
Code blocks and PLC programs could also be captured in the
database through macro statements again with the code being
regenerated through appropriate translators. As suggested in
the figure, users would not directly modify programs but
rather change the database which in tum modifies the frontend software. Such a scheme can effectively enhance code
reuse, simplify programming, and provide a single data
source for describing the system. Some of these ideas havebeen successfully used in an earlier cyclotron control
system{2].

Figure 6. Possible method of automating front-end
system software development through the use of aconfiguration data basekbit/sec communications band width and a crate with 128
analog input signals attached to standard 32 channel
multiplexed 12 bit ADC cards, an 8 Mhz 8088 processor
could update 256 bytes of renective memory in both aregional and global system at 20 Hz using only 34% of the
cpu. The output link is saturated to about 70%. This example
was chosen to show worst case throughput since the cpu must
manage the ADC multiplexing. Quantity one pricing for thissystem consisting of 4 ADC cards, cpu card, communications
card, crate, and power supply is on the order of $4000.
Several STD-bus manufacturers produce slave processors
which have shared memory on the STD-Bus but cannot
initiate backplane data transfers. These systems have ISBX
110 connectors and the communications board can be easily
modified to become an ISBX daughter board. This
hardware configuration could support the local PLC shown in
Fig. 4. PLC software which is portable to any INTEL 80xx.x
embedded system is available commercially{3].
The initial regionaVglobal system TOM interface will becommercial communications processor which directlyinterfaces with a Tl communications line.
Enhancedcommunications interface cards capable of connecting tohigher rate TOM lines will be developed as part of thegeneral SSC controls system .
Initially the 110 processor will be directly programmed to
produce an embedded system without an operating system orreal time kernel. One option is to embed a FORTH kernel inthe processor and program it over the communications line.
Other options include more traditional embedded codedevelopment using assembler, C, or C++.

IV. TEST IMPLEMENTATION

V. CONCLUSION

A prototype of an interface level of this system is underdevelopment at the SSC. The initial system will be based on
STD-Bus, IEEE-961, which is an inexpensive, open,
industrial standard bus that has been used extensively forcontrol applications in many areas. It is a well establishedbus supported by a large number of vendors. While initiallyan 8 bit bus, recent extensions to 16 and now 32 bit protocols
give indications that the bus will not quickly fade or be
replaced in the time scale of the SSC control system. The
bus specifies a straight forward interface to the backplanethus greatly simplifying the construction of custom interface
cards when needed. The bus nonnally uses processor cards
having INTEL 80xxx or equivalent cpu chips. This gives. direct access to the large amount of excellent andinexpensive development software available for the PC
platform.
A dual channel STD-Bus communications card which can
extract a 64 kbit/sec data stream for a Tl communications
line has been designed, constructed, and is undergoing tests.
This will allow up to 24 STD-Busses to be connected to asingle Tl line.
An estimate of the ability of an STD-Bus system toprovide communications has been made. Assuming a 64

A scheme for providing highly integrated process controls
for the SSC has been described. It makes use of a different
style of communications based on telephone technology,
supports a high-performance centralized architecture whileallowing regional systems to exist for commissioning andmaintenance. System prototypes are being implemented.

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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC04

a

VI. REFERENCES
{I J

{2)

{3)

D.R. Haenni er al., "The SSC Field Bus: A HighPerfonnance System Front End for "Slow" Accelerator
Controls", SSCL-391, 1991.
D.R.Haenni er al.,"Personal Computer Control System
for the TAMU K500 Cyclotron", in B. Martin and K.
Ziegler eds., Twelfth lnremarional Conference in
Cyclotrons and Their Applications, World Scientific,
1991, pp 264-267.
CPI Industrial Software, P.O. Box 1046, Bettendorf, ra.
52722, USA.

S07IC04
286

Industrial Control286

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·or interrupt routine (AST) execution with a parameter. Change
notification can be requested on the change of any field in the
database. The library of access routines handles the network in
a manner transparent to the user. Network access can be synchronous, leading to simpler but slower code, or asynchronous, leading to code a little more complex but up to 15 times faster [l].

quirement for run-time support for trackballs and the options
necessary to restrict or completely eliminate the possibility ofmodification of the system at run-time. For another application,
flashing colon were added as an option to the Vdraw color
palette.

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

In physics data acquisition and control systems redundancy isquite rare and problems are fixed as necessary. In some industrial
systems, spare senson and sensor channels are maintained andwhen wiring changes are made these changes must be reflectedin the software at the closest level possible to the hardware
change. Access routines incoiporating redundancy issues havebeen added to Vaccess for future release to all customen.

Another industrial testing project required complete, networked
program control of the Vdraw windows displayed on a workstation and control of several of the tools in each window. Thus, theVscript process (Vsystem scripting facility) which was sequencing the test could also detennine the windows being displayed toan operator. 'Therefore, in this case the workstation or X-tenninal
has no requirement for a keyboard or mouse.

B. Complete Graphic Toolbox

m. CREATING GRAPmc D1sPLAYs
It is fair to say that there is a broader range of people who will use
industrial systems and that the operator interface has to reflect
this. In industry there is often a strict categorization of jobs withthe result that a system that requires the use of a keyboard to operate it is unacceptable. These considerations also added the re1Vc., Vdraw Toolbov V2.3 beta

Vdraw, under Xwindows, contains a complete set of drawing,editing and windowing tools. Usen can create both prototype
control screens and control screens ready for application. Vdraw
features an intuitive, easy-to-use graphics toolbox, Figure 1,
with which users can create data acquisition and control windows rapidly, without programming.
·

copyright Vista Control Systems, Inc. 1991

f;1s,1ays I New

TEXT

0 1

NormalEll D Left Med Ru. . /II Tuols
ControlrD.., "'"\
L:..i

Courie~.'0 12. /.. ·r\

Clip Art/Symbol\~
Builder. ··\Pr.sft.
/ChannelListing

~

'··

'

./

!~
5

Wlndowf£.~~~L~ine~=:-::~~F:.ll~l~~:==:~=re=~~~~~~~LB

BDu

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S07IC05&J-. , Control Tnn•box
Bars

Buttons

Dia lsGraphsMetersMultiplexors

Polar Plots

Sliders

Std Objects

Strip Charts

Symbols

Text

Time stamp

User Links

User Menus

ICloselFigure 1. Vdraw's Graphics Toolbox and Control Tools Menu
In draw mode, both passive graphics and interactive graphics(known in Vsystem as control tools) are placed in the window.
Control tools can display data from the Vaccess database, allow
for changes of data in the Vaccess database, or both. The exact
fonn of the control tool and the database connection(s) are defined with a Vdraw generated fonn. Vdraw also has full window
editing capabilities.

When a window is placed in active mode, Vdraw connects thecontrol objects to the Vaccess ~abase and they immediately
show the current state of the Vaccess database and hence theapplication.

S07IC05
288

Industrial Control288

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

C. Flexibility

D. Rapid Prototyping

Because in industrial systems the same window could be used indifferent applications-except for the actual configuration ofsome of the tools, such as menus--the definition of a menu can
now be defined by a file rather than be hard-coded in the window.

Many industrial systems are implemented by a vendor for the client. With a toolbox like Vsystem, it is possible to develop a realistic demonstration as part of the sales effort. 1bis has been doneon several occasions with good success. An example done inhouse is shown in Figure 2 on the following page.

Primary Treatment Plant for Oil-Water-Sludge Wastewater

11

73.4804I

CFM I

Clean Water

Dlocharge
Reeycl• F'U1'111

I

Aerallon Tank

az.e531 icFMI

Skimmed OU
Dlocharge

I

Bacl<pret1ur• Vmve
(releuea bubble•) )I1114.8400 ICFM :Oil-Water-Sludge Influent

II 74.411118 I

CFM

200.0000

200.0000

0.0000

0.00

I

-~1

Figure 2. This control screen was created in one day by an experienced Vdraw user. It illustrates the text,
bar, and strip chart control tools used to monitor and control the flow of the process.

IV. CONNECTING TO THE lIARDWARE

V. LOGGING AND PLAYING BACK DATA

Connecting the Vaccess database to the CAMAC or any otherhardware is as simple as including the name of a handler whendefining the Vaccess database and supplying the hardware address (branch, crate, station and sub-address in the case of CAMAC). An example handler is provided in source form with
Vsystem. From this template, handlers are easy to develop.

Vlogger, Vsystem 'sdata logging component, reads data from the
Vaccess database and writes the data to standard output devices
such as disk files. Vlogger will also play data back into the Vaccess database. This playback function can include all the channels logged in a log file or just a selection of channels. Data canbe logged at specified time intervals, on changes in channel value, or by an event defined by a binary channel. Logging can begated by a binary channel. The list of channels being logged by
Vlogger can be increased or reduced dynamically.

Vscan, a generic reader for input channels, is also supplied insource form so that it can be used as a basis for application specific needs. One of the advantages of the change notification featureofVaccess is that the real-time database can maintain an interest
count and then readers like Vscan can change the scan rate of achannel depending on the level of interest in the channel.

Vlogger includes facilities to take a "snapshot" of all or part ofthe channel settings in a Vsystem database and restoring thosesettings at a later time.

S07IC05
Industrial Control

289

289

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

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 Publishing

Vlogger is based on the client-server model and is fully networked so that a user can connect tologging process in thesystem without logging on to that system and obtain the status ofthat logging task or modify the logging in any way.

Vdraw display update rates have also been dramatically increased for some of the key tools. Here, similar performance increases have been achieved by careful use of X-windows and in
one case offering the user a choice of X-window display
techniques.

doi:10.18429/JACoW-ICALEPCS1991-S07IC05

any

VI. MONITORING ALARM;WARNING STATES
F. Reliability

AND ERRORS
Valann, the interactive alarm module of Vsystem, monitors
channel alanns and exceptions. Val arm will monitor all channels
in an application or a defined subset. Users acknowledge and reset alanns simply by clicking with the mouse.
Alarm data can also be logged to a printer, to a disk file, or, as theresult of a recent industrial requirement, to a DECtalk unit.

The tolerance to software and other errors in industrial applications is much lower than in the research environment A comeque nce is that industrial applications are more fully tested andproblems are reported for correction. This has resulted in a con·tinuing decrease in the number of errors in the released softwareand an improvement in the error handling.

G. Report Generation

VII. USING SCRIPTING FACILITIES DESIGNEDFOR NON-PROGRAMMERS
The first industrial application required that there be a simple
way to define the sequences of operations required to collect datafrom an experiment or to control a process. Vscript. as describedabove, was the result and it is being heavily used by two indu~
trial customers.
Vscript provides a programming environment in which non-programmers can use scripting facilities to define sequences of operations. Users interact with the Vaccess database using a simple
English-like syntax that allows anyone to develop scripts. The
Vscript syntax is keyword based. For example:
Raise TANK_l2:PRESSURE to 1100 psi

or
TANK_l2:PRESSURE should be 1100

Both these lines are acceptable and would put a value of 1100 into
the channel named TANK_12:PRESSURE.
Vscript supports a full range of mathematical functions, file 1/0
capahilities, control flow constructs and logical operators.
Vscript also contains several error handling facilities and supports an interface'to the operating system command processor for
running other programs or processes.

vrn. INnusTRIAL INFLUENCEs
E. Performance
One would imagine that it would be the research environmentthat would emphasis performance but in our experience so far it
has been in the industrial testing environment where overall performance has been emphasized over function. This has involved
the re-writing of many key Vaccess subroutines for performanceand adding new routines that further reduced the per-update
overhead. We have achieved performance increases of up to sixfold by this effort.

The rep0rting from an industrial system is vital to the corporation. This might be the paper report of the shift or test or the reporting to the company database as part of the manufacturingsystem. To support this we have added mailbox options to someof the tools and we will be extending the capabilities here overthe coming months to provide standard.interfaces to common database/report systems.

H. Port to a Real-time Kerne/, VAXIEI.N
While VAX/ELN is almost unknown in experimental physics it
has many enlhusiastic users in the industrial market. This is because it is extremely well integrated with the development enviromnent on VAX/VMS and well supported by Digital Equipment
Corporation. More recently, the availability of a real_time VAX(rt300) and a component to mount on a controller board b~ re·suited in the rt300 VAX with a VAX/ELN license becoming
available in VME and CAMAC as well as in other 1/0 systems.
It was these developments that encouraged the porting of Vaccess (and soon the other components ofVsystem) to VAX/ELN.

IX. SUMMARYWith the indusbial applications, Vsystem has grown in capability, flexibility, and consistency in ways that benefits all applications, including physics applications. All of the areas of influence described above are of value to the physics community andmost are of considerable value.
1be strength ofVsystem lies in the X-windows graphics, the oetwoddng, the openness and the broad applicability of the system.
The influence of the industrial applications has added considerably to the system. For the future we are developing new automation tools and new ports of the package.

X. REFERENCES[lJ Network Performance for Graphical Control Systems,
Clout, P., Geib, M., Westervelt, R. These Proceedings

S07IC05
290

Industrial Control

290

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

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·Hz cycle rate of the Linac. Each cycle they read data from theoptimize data collection by ordering the wait-type entries sothat lightly-loaded SRMs appear early in the table. The third
entry type is used to map the various data types included in the
SRM's response into the local station's data pool. Status bits
are set or cleared according to whether a given SRM replied inthat cycle. These status bits can be enabled for alarm reporting
if an SRM stops sending replies.

hardware according to entries stored in a data access table,
update a data pool of current readings, respond to requests fordata by returning answers over the network, scan the newly
acquired data for alarm conditions and send alarm messages to a
multicast address on the network.
As with most control systems, the least standard part is theinterface to the accelerator components. Accelerator equipment
is usually sparsely scattered over a large area. The cabling
length should be minimized for reasons of signal quality andcost, but the signal density is not high enough to justify the
installation of VMEbus crates at all the locations where data is
to be acquired. The solution is to collect equipment signals
locally with cost effective interface hardware and to transmit
this data to the VMEbus crates over a field bus. For the Linac
Upgrade, a data acquisition chassis called the Smart Rack
Monitor (SRM) collects data from the hardware ahd transmits itto the VMEbus Local Stations over the ARCNET field bus.

B. System Software
Network software was designed to support the Token Ring
chip set. Network frames are received into a large circularbuffer via DMA, and a pointer to each message contained
within each frame is passed to the designated task using astandard message queue supported by the pSOS operating
system kernal. Network messages to be transmitted are passedby reference through another message queue to the networktransmitting logic. When the queue is flushed, consecutive
messages destined for the same node are combined into acommon frame if possible. This can greatly reduce network
software overhead for both sender and receiver.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC01

IV. SMART RACK MONITORThe SRM is an extension of the MIL-1553 Rack Monitor(RM) used in the DZero colliding beams detector. In that case,
the RM was dumb, so the register-based field bus protocol
MIL-1553 was used. For the Linac Upgrade, it was decided touse the existing digitizers and D-A converters. Operating thesedevices requires that a computer be located close to theequipment thus requiring a processor in the rack monitor.

A. SRM Hardware
The SRM, shown in Figure 1, is a 2U chassis that contains
64 16-bit differential A-D channels, 16 12-bit D-A channels, 8
bytes of digital 1/0, 256K bytes of nonvolatile RAM, the
ARCNET interface and a processor. The processor is on aMotorola Business Card Computer (BCC) that includes anMC68332 microcomputer, 64k bytes of RAM, 128k bytes ofROM, and a serial port. The BCC is marketed by Motorola aspart of an MC68332 evaluation kit. Three BCC sockets were
included on the SRM motherboard: two for expansion
daughterboards and one for the BCC. Daughterboards used in
the Linac system will be for special equipment interfaces andfor the timing system that is based on a 10 MHz serial event
clock. A BCC and a 9-byte digital 1/0 daughterboard are·shown in Figure 2.

ARCNET support was added to the system software
retaining the overall plan described above. Separate 1/0 buffers
ARCNET was chosen for the SRM network for several
are used for each network. The ARCNET interrupt routine reasons: its cost is low, its 2.5 MHz serial bit rate is adequate,transfers the frame between the hardware buffer and system the physical bus/logical ring architecture makes it easy tomemory analogous to the Token Ring's DMA transfer. connect and the token passing protocol eliminates collisions.
Emulation of the Token Ring software data structures The automatic network configuration minimizes processor
permitted much of the network code to be common. A range overhead, the free buffer enquiry and message received featuresof 16-bit node numbers is mapped onto ARCNET nodes so that of the protocol makes the communication reliable. Siliconuser code sees no difference between the two networks. The support for ARCNET is excellent.
task-task protocol widely used in Fennilab accelerator control
systems allows for future protocol additions. A simple data B. SRM Software
acquisition request protocol was designed for use with theSRMs.
At this time, the software in the SRM is limited to dataacquisition and debugging, although future applications may
To support SRM data acquisition, three new entry types include additional tasks such as closed loop regulation.
were designed for use in data access table entries. The first one Software in the SRM is written in C and uses the pSOS real
results in sending a cycle request message, nonnally broadcast, time operating system kernel. Motorola's 332Bug program
to the SRMs. Each SRM that receives this message reads its that is bundled with the BCC is retained for low level
own hardware data according to entries in its own data access debugging.
table and replies with a single frame that includes all types ofdata. The second entry type waits for a given. SRM to reply,
and includes a deadline time within the 15 Hz cycle. One can

S08NC01
292

Network and Communication

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC01

Figure 1. Photograph of a Smart Rack Monitor
When the SRM is reset, 332Bug initializes the MC68332
chip selects and then enters the SRM system code where it
executes a repetitive cycle that collects data and prepares amessage to send to the VMEbus Local Station over ARCNET.
Normally, the cycle is initiated by the ARCNET broadcast
message sent by the Local Station, but an internal M68332
timer is used to trigger a cycle, if no ARCNET message is

received, to permit stand alone testing.
A copy of the system code resides in the 128 kbyte PROM
on the BCC, and another copy may be stored in the nonvolatile RAM of the SRM motherboard. During initialization,
if a RAM version is found, that copy is used. If no system isstored in RAM, the PROM version is copied to RAM . The
MC68332 contains a hardware watchdog timer that requires
refreshing at regular intervals. If a timeout occurs, the PROM
version of the SRM code is copied to RAM and operation
resumes. New versions of SRM code can be downloaded over
ARCNET. Because some version of the SRM program isavailable in PROM, the SRM will function at least well enoughto allow downloading the current version of the software. In
normal operation, the SRM will find the current version in
RAM.

Figure 2. Photograph of a Business Card Computer and a
9-byte Digital l/O Daughterboard

The SRM determines what data to collect by referring to adata access table containing 16-byte entries that describe thetype and amount of data to read. Separate data types are definedfor digital IJQ, A-Ds, D-A readback and so on. After all data isread, the SRM replies to the Local Station's broadcast request.
Note that all SRMs connected to a Local Station, usually threeor four, acquire their data in parallel and the Local Station only
receives one message from each SRM.

S08NC01
Network and Communication

293

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

(

or r

11D1v

2.001111

ARCNET Interrupt Acti11ity
in SRMs 1,2, and 3-E

SRM lTasu-C

J

11' H'<l'

UPDATE
Sl!llMI

SRl1AR2

I ( o urur
At

) (

J

Ill HZ)I

I 8.000IK
Deley II 11•rkm 11 x too I pr10 10 Kj ITrlg too
TIM<l,7201111
6.840M
11.561118
:

I
' II

AAC:NET

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC01

5 to t.JTlftl!119 E ) ( Mov1forM I

Accu.,uteh

Start of a 15 Hz Cycle _....
ARCNET Interrupt in Local Station_.,..
"Update" Task in Local Station _.,..

ICALEPCS1991, Tsukuba, Japan. lJlf1J !
on !.

=1 I

SRMllH!

ARCTSIC:

LI I

111tnT111<
:

_j

lJ.

I
I

u

I

I

u I
u:111I _ ..

•j t I LA•-....

Beginning of 15 Hz cycle
SRMs receive broadcast message
SRMs begin collecting data

:J

--.d

by Local Station
SRM Data returned on ARCNET
SRMs finish collecting data

Figure 3. Logic State Analyzer Timing Display of SRM Operation
Data types are included to read back setting values of digital
and analog output in the message returned to the Local
Station. This is done to allow for future closed loop programs
that modify output settings locally within the SRM.

V. PERFORMANCE AND TIMING
Figure 3 shows a logic analyzer display of the timing
characteristics of a Local Station and its three Smart Rack
Monitors. In response to the 15 Hz interrupt, the Local
Station broadcasts an ARCNET message to the SRMs to initiate
data collection. After 6.8 ms, the SRMs are ready to return
their data. At 11.6 ms into the 66 ms cycle, data from all
three SRMs has been received and processed by the Local
Station. For this test, all SRMs were reading the onboard 64
A-D channels, the 8 bytes of digital I/O, and the readback of
16 D-A settings. Because the SRM activity is overlapped, an
additional SRM would add only the ARCNET serial time plus the
Local Station processing time, about 1.1 ms per SRM.

VI. PRESENT STATUS AND DISCUSSION
The Linac Upgrade is to be carried out in two parts; thereplacement of the existing control system scheduled forJanuary 1992, and the upgrade of the Linac itself, scheduled forlate 1992. The SRM was prototyped and then fabricated inquantity by an outside vendor. Sixty-five SRMs have beendelivered.
The concept of a networked data acquisition chassis thatsatisfies most of the interface requirements of the accelerator
seems to work well. A single interface design that is
duplicated in quantity results in a cost effective solution to the
distributed data acquisition problem. Because of the single
daisy-chained coaxial cable ARCNET connection, the SRMs canbe installed wherever the data sources are located. If newdevices are installed, another SRM can be easily added to readand control the additional equipment.
Data collection by SRMs is efficient because all SRMs
collect their data in parallel. The VMEbus computer
broadcasts a single command over ARCNET to initiate the dataacquisition cycle and then processes the SRM messages as they
are received.
Because it is a widely used network, ARCNET enjoys
considerable industry support. A commercial copper- to-fiber
optic ARCNET bridge is used to connect the VMEbus ARCNET
adapter to the SRMs in the two 750 KV equipment domes ofthe preaccelerators. SRMs in the domes have the ARCNET
copper transceivers replaced with pin-compatible fiber optic
transmitter/receivers.
The connectivity provided by ARCNET allows future tasks
to be handled by the SRMs. Because of the peer protocol of

the network, one SRM could ask for and receive data from other
SRMs. The other SRMs can be connected to the same ordifferent Local Stations. Using this feature, an embedded
control loop could be run in one SRM with data being collectedfrom several other SRMs.

VIl. ACKNOWLEDGMENTS
Several people contributed to the hardware development of
this project. In particular, Robert Florian has been in chargeof the VMEbus systems, and the early SRM design was doneby Alan Jones, now at the SSC laboratory.

S08NC01
294

Network and Communication

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

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

The Multibus II bus with multiple Intel 386s running
MTOS-UX SP (single processor version of the operating
system) is the platform for this implementation. The cratecontains an IBM/PC as the bus monitor which supports
diagnostics, rebooting, and console emulation. Each of theIntel 386 processors has a daughter board supporting the
CAMAC link directly.
Included in the configuration is a Token Ring board
for communications. The board has an 8 MHz Intel 186 witha Token Ring daughter board attached to the ADMA controllerof the processor board. The board implements the
TMS380Cl6/04 chipset at either 4 or 16 Mbps and will becommercially available in the near future.

CPU!, a transport message provides this information to the
Token Ring processor. Another processor, CPU2, can connect
with the same task name, 'TSKA'. Since replies must go to
the originating request's processor, only requests are distributedin this way. The ACNET header's source node is altered toremember the specific processor which initiated the request so
the reply is routed correctly.
ACNET header contains a 16-bit word to specify a
Ian/node number for both the destination and the source of themessage. For this implementation. a set of node numbers areused as a logical nodes. One node number is used as a global
logical node and implies the request can be distributed to anyof the available processors which have the connected task
specified in the ACNET header. For each processor, a specificlogical node enables a request to be directed to thecorresponding processor.
When a task is terminated, a cancel message is sent todelete each outstanding request. Since the requests are
distributed in round-robin order, the Token Ring processor
needs to deliver this cancel to the same processor which
received the original request. Since cancels are infrequent andcan be uniquely matched to original request through the
ACNET header, the Token Ring processor broadcasts themessage to all processors.
The byte orientation on the Token Ring wire wasdictated by early implementations on VME, UNIBUS and
QBUS platforms. The TMS380 chipset enables either
Motorola or Intel logic interface which implies correct text,
while integers are byte swapped. These early controllers used
the Motorola interface and mapped the Big Endian format
directly to the little endian processor bus. The result was an
automatic byte swap. While this appeared to optimize our.
message format, the Multibus II Token Ring board using anIntel interface must byte swap each message.
The ACNET software for Multibus II and VME
processors is written in "C" and is ported between the two
platforms. The portable code is conditionally compiled to
distinguish the use of transport as a vehicle to and from the
Token Ring board.

B. Software Implementation

C. ACNET extensions

To effectively communicate across a Multibus II
backplane, each board contains a message passing co-processor
and a software protocol called "transport" to provide amessaging facility similar to a LAN protocol. The Token
Ring board's software takes an incoming transport message andsynchronously transmits it onto the Token Ring. Upon
receiving a Token Ring frame, a transport message containing
the frame is sent to the appropriate processor. The distributionof a message is based on a connected task name for a given
processor, the node number, and the message type.
ACNET requests are delivered in round-robin order.
When a task called 'TSKA' connects to the network fromThree new calls were added to aid in flow control.
The round-robin scheduling of requests could be madeineffective if requests with greater life-times funneled into thesame processor. The processor could be starved by servicing
these requests with multiple replies while other processors
would be relatively idle.
If such a case can be detected by the user, a NTSTOP
call can be executed which provides a temporary block for
future requests to be delivered to this task's processor. A
subsequent NTUSTP call will resume normal round-robinschedule.
Since Multibus II implements a flexible messaging
facility, a request can be re-routed to another processor based

Control

Flap

Flq:•

Control0
Destination
Node

Destination
I.AN

Sowce
Node

LAN

Sou:rce

Doatination
Node

Deatinalion
Task

SoUICe

Task

Nmno

Namo

P&eket Sequenco

orChccbwn

So= Tulc m

Paclcct Seqµonoo

orOtccbwn

Molaap Length

Reque.t/Unsollclted
HeaderDestination

Task ID

Mm111geLength

Msg

Reply Msg
HeaderFigure I

ill. MULTIBUS II

A. Configuration

S08NC02
296

Network and Communication

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

ICALEPCS1991, Tsukuba, Japanon a user statistic, memory utilization, or idle time. The user
can execute the NTMREQ call which will re-route the message
to a specified processor. It is the user's responsibility toprevent a message storm on the bus.

sent an echoed reply of equal length. A single processor
running MTOS-UX SP generated approximately 200 messages
per second. A single processor running MTOS-UX MP
generated approximately 160 messages per second. A dual
processor running MTOS-UX MP generated approximately
170 messages per second. As expected, the additional
processors should not improve network performance in such anarchitecture, but could provide additional compute power with
ACNET communications.
The VME test was implemented with the ACNET
network task running on the first processor. The same test
was attempted with ACNET running as a global task on two
processors. The result generated approximately 8 messages per
second. The second processor had the Token Ring interrupts
masked off. I believe the tasks were thrashing from processor
to processor, but interrupt delivery to a task could only bedelivered to the same processor which received the hardwareinterrupt. While further investigation is required, the results
caution the user of MP to understand the system architecture or
unusual results could occur.
Improvements in performance can be implemented
with the following techniques:
1. Implement multiple Token Ring controllers.
2. Upgrade processors.
3. Overlap Token Ring 1/0 with transport 1/0.
4. Eliminate unnecessary copy of received frames.
5. Optimize C code.
6. Upgrade the Token Ring to 16 Mbps.
7. Upgrade the TMS380Cl6/04 fmnware.

A. Configuration
The test configuration used two Motorola 68020s
running MTOS-UX MP operating system in a VME
backplane. The platform implements one of the following
three Token Ring boards: a Fermilab designed board at 4
Mbps, a Proteon pl542 at 4 Mbps, or a Formation fvl600 at
4/16 Mbps. All of the boards use the TMS380 family of
Token Ring chipsets.

B. Software Implementation
The same ACNET software package implemented for
MTOS-UX SP is used for the MP version. The operating
system allows multiple tasks to run concurrently andtransparently on multiple processors. A copy of the operating
system is placed on each processor to improve performance.
The operating system allows the user to specify the processor
a task must run on or whether the task can be globally run on
any of the available processors. If the task is global, the user
must make modifiable data accessible to all processors. In thecase of the test configuration, the operating system's tables,
global task's data, and stack was contained in a shared memory
segment accessed through the VME bus. Thus, performance isdecreased due to the multi-processing operating system's
overhead and each global task's data access over the VME bus.

V. PERFORMANCE
In a multi-tasking operating system, many factors
determine the performance of the network to deliver messages
to a task for useful work. Each of these implementations
provide adequate performance with several opportunities for
improvements. The Multibus II configuration can deliver 200
byte messages at approximately 110 messages per second for
one processor and 180 messages per second for two processors.
This measurement is for a task communicating with itself andin the case of two processors the messages are distributed totwo duplicate tasks on separate processors.
The VME configuration was tested with one global
task initiating a 200 byte request to a separate global task inthe same VME backplane. The receiver of the request thenVI. CONCLUSIONSThe Multibus II implementation has been running at
Fermilab's Central Detector Facility. While the system has
limited utilization compared to Fermilab Accelerator Controls,
it has been valuable for detecting bugs and predicting
performance characteristics. In particular, the round-robinscheduling with user invoked flow control appears to beadequate and manageable.
The throughput of the Token Ring board is a concern.
Since the Token Ring software must byte swap each message,
much of the performance is tied to the processor. The board
will soon be available with a 16 MHz Intel 186 and should
improve performance. Further, the software to enable multiple
Token Ring boards on the same Multibus II backplane iseasily implemented. Unfortunately, the ability to allocate
these resources for incoming messages is a management
problem without a stable solution.
Currently, their are no multi-processor
implementations of MTOS-UX MP. While the operating
system provides a high degree of transparency, theimprovement in performance is difficult to quantify. In
general, a master/slave or co-processor configuration withsimple mailboxes is more predictable and manageable for realtime processing.

S08NC02
Network and Communication

297

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

IV. VME

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC02

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

While both implementations use MTOS-UX as its
operating system, the multi-processor version is inefficient forMultibus II. The operating system's global tables implies atime consuming access in Multibus II. The Multibus II
implementation does enable tasks to be statically distributed
across multiple processors. A VME implementation to enable
duplicate tasks distributed across multiple processors requires
mutual exclusion techniques on network structures andadditional software. Thus, these two multi-processor network
implementations provides a non-competitive solution solving
two different problems.

Vil.ACKNOWLEDGEMENTS
Multibus II Token Ring board was designed and built
by Jim Zagel, John Smolucha, and Bob Marquart. Transport
protocol for the Intel 186 was developed by John Smolucha
and transport protocol for MTOS-UX was developed by Mike
Glass and Bill Marsh. Kevin McGuire and Duane Voy (SSC)
generated MTOS-UX MP for the MVME133 board.

VIII. REFERENCES[l] Briegel, C., Johnson G., and Winterowd, L. (1989). The
Fermilab ACNET Upgrade, Proceedings of the International
Conference on Accelerator and Large Experimental Physics
Control Systems, pp. 235-238[2] Glass, M., Zagel., J., Smith, P., Marsh. W., and Smolucha, J.,(1989). The Upgraded Tevatron Front End, Proceedings of theInternational Conference on Accelerator and Large
Experimental Physics Control Systems, pp. 87-92

S08NC02
298

Network and Communication

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-S08NC03

communicates across the network with servers running on eachnode which is sampling device readings. Communication
between the operator interface and the server is done via remote
3.2 An Interim Solution
procedure calls (RPC).
An example of the way in which the distributed system of
One way in which replay has been improved is by the sampling software is used is shown in Figure 1. Samplingdevelopment of command procedures which run a version of programs running on a micro VAX and a VAX 8650 can be
the replay program as batch jobs at regular intervals. Instead controlled from a workstation connected to the same network.
of outputting the data to a graphics screen the device data is Using the operator interface to the sampling program on thewritten to a file which is then sent to a laser printer. This workstation the microVAX is selected and a request to
automates the replay request process, and allows the replay to immediately monitor a list of devices is send to the server on
be scheduled at times of lower CPU usage so that there is less the microV AX. The server sends the request via shareable
impact on beam production. However this is only a partial memory to the sampling program which carries out the action.
solution.
The VAX 8650 is then selected using the same operator
interface, and a request is sent via the server to the sampling
3.2 Requirements for the New Software
program running on the VAX 8650 to start logging thereadings of a list of devices to the local history file.
The requirements for the redesigned software include the
The replay software is also divided into a user interface
ability to control the sampling of device readings from a which can be run from any node on the network, and a server
number of nodes on the network, and the ability to replay running on each node which has recorded device readings at
device readings from any node on lhe network. It was also some time during the production cycle. Communicationnecessary to reduce the CPU load on the control computer for between the user interface and the server is again done withacquiring and logging device readings, and to increase the speed RPCs.
of replay of the device readings. The last two requirements
For example, a user on the VAX 8650 can request device
were met by redesigning the history file. The software readings from a remote microVAX. The data is retrieved fromredesign was accomplished in two steps. The first step was to one or more of the local history files, converted to thedevelop a distributed system, and the second was to redesign appropriate units and returned to the VAX 8650 which thenthe manner in which the history file is shared between the plots the data on a graphics screen (Figure 2).
logging and the replay software.

·becoming slower and consuming too much of lhe cont.rol
computer's CPU and the operators' time.

remote mlcroVAX

3.3 The Redesigned Distributed Softwaregraphics screen

As many of the devices are read through remote nodes it
was decided that there are advantages in storing device readingson the local node to reduce network t.raffic and the load on themain control computer. The design of the software thatinterfaces to the sampling program calls for a user interface
which can be run anywhere on the network. The user interfaceb,.:-

I R1s!!t'1le I
I Rl!!!!!I file I---

I HislDrv file

~

I

t

I

I

-..............

I

Device readings
rell.lrned to userinterface.

USER INTERFACEFOR REPLAY OF
DEVICE READING!':

RPC request for
device readings"I

GET DATAROUTINliI
I-

REPLAYSERVER

VAX8650

Figure 2. Method of retrieving data across the network anddisplaying it on a local screen.
3.4 Changes in the Structure of the History File

Figure 1. Diagram showing commands being sent tosampling programs on several network nodes, from a remote
workstation.

Originally device readings were recorded to a single file forthe complete run cycle, which was typically five to six
months, each year. In 1990, this file reached a size of about
300 Mbytes (ie.25,000,000 device readings). The file wassequential with direct access to the nearest eight hour pointer.
Shared access to the file for both the logging program and thereplay program was achieved with VMS locks, which resulted
in both programs being slowed by lock manipulation.
Another cause of slow data retrieval for replay was that eachrecord read resulted in disk 1/0.
The redesigned logging software opens a new history file
every twenty four hours on each node where device readings are

S08NC03
300

Network and Communication300

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

ICALEPCS1991, Tsukuba, Japan

being logged. When data replay is requested the replay
software maps the relevant section of the history file into
process memory and extracts data for the required devices. As
replay of the most recent data must be available it may benecessary for the replay software to map to the section of thefile being updated by the logging program. To prevent
conflict between the two sets of software the history file issequential and new records are appended to the file.
This method of sharing access to the file has significantly
improved the rate at which data can be replayed because it has
decreased disk 1/0 and does not require any ftle locking. It has
also decreased the CPU usage for logging device readings as
the file structure has been simplified and the need for disk 1/0
to access an intermediate time index file has been eliminated.
Another benefit of the smaller history files is that they areeasier to backup.

for a short time both software systems were running on thesame computer recording the same device readings in seperate
history files. At that time it was possible to make accuratecomparisons which showed that the speed of replaying data has
improved by a factor of six. The average rate of data retrieval
for replay is 200 to 300 readings per second on the main
control computer. Replay of device readings from other nodes
in the system is faster as history files are much smaller.

A high frequency of data sampling (every one or ten
seconds) may be required for one or more devices over a period
to study some effect or diagnose a problem. At LAMPF one
device being logged every one second accumulates more than
1.3 Mbyte (86,400 device readings) of data per day. Thisfrequency uses CPU during the logging process, and adds
significantly to the volume of data stored in the history files
so that it slows data retrieval for replay.
To avoid
unnecessary sampling at higher frequencies, lhe new software
will allow the user to specifically enter the time period forwhich devices are required to be read at the one or ten second
frequency, before lhey drop back to a less frequent samplingtime. If no specific time is entered a default time will be used.

VI. PRODUCTIVITY GAINSThe sampling of device readings is now being carried out
on several nodes on the network. In 1991approximately2,000
devices were sampled throughout the production run. Since
the new software was implemented the amount of data logged
has almost doubled to 40,000,000 device readings (ie. 650
Mbytes) for the 1991 production run. Replay of the device
readings can be done anywhere on the the network.

VII. ACKNOWLEDGEMENTS
The author would like to thank Eric Bjorklund, Dave
Schultz, and other members of the controls section of MP-6
for helpful ideas during the software design phase.

VIII. REFERENCES[1] S. Schaller and E. Bjorklund, "Providing Common Data
Access for the LAMPF and PSR Control Systems", Proc.
1987 IEEE Particle Accelerator Conference, Washington
DC (IEE Publishing. New York, 1987) p 745.

IV. FUR1HER POSSIBLE Th1PROVEMENTS
One possibility which has yet to be explored is whether thedevice readings should be grouped into seperate 24 hour files
based on some relationship such as type of device, or locationin the beam line. This would increase the CPU usage at thetime the device readings were logged but the improvement in
replay speed achieved by the further granularity of the history
files could be significant. Changing to a different history fileorganization, such as an index file is not possible while theretrieval software is accessing the history file by mapping it
into process memory. Another disadvantage of index files isthat they are space consuming. At the moment it is possible
to maintain the history files for a whole year on disk whichallows for efficient replay of device readings over a complete
production run.

V. PERFORMANCE GAINSCPU usage by the new sampling software on the main
control computer has been reduced by a factor of five but thisis partly due to changes in the way in which the LCS Data
System handles requests for device readings (message passing
has been reduced by buffering device readings). It is hard toacquire accurate figures for the improvement in the speed ofreplaying device data, as this depends on the load on thecomputer and the size of the relevant history files. However

S08NC03
Network and Communication

301
301

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

3.5 Other Design Changes

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC03

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

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

ICALEPCS1991, Tsukuba, Japan

Application

6

Presentation

5

Sessionformation to be acknowledged. For this reason, the morerudimentary UDP transport protocol, which implements
the unreliable transfer of datagrams, is preferable. However, the use of UDP requires additional transport layer
functionality in order to ensure the reliable transfer ofdatagrams.

INTERNET
5

Application

4

Transport

3

Internet

2

Network interface

1

Hardware

3.3

4Transport

3

Network

2

Doto link

1 Physical hardware

Figure 1: Protocol Stacks
of message-based operating systems, such as the Harmony
real-time kernel. For instance, the Unison real-time operating system from Multiprocessor Toolsmiths implements
the synchronous message-based semantic using the native
semantics of the Reliant kernel, a commercial variant ofHarmony, or as a messaging layer added to the pSOS+
real-time kernel.

3

Network Architecture

Common to all modern network protocols is the separation of logical elements of the protocol into several layers.
The five layer Internet protocol stack and the seven layer
ISO/OSI protocol stack are illustrated in Figure 1.
Proponents of the Internet suite of protocols, which
has been widely implemented in the Unix and other domains, claim that it is the de-facto network standard. In
the realm of networked real-time operating systems, theInternet protocol suite is almost exclusively used.

3.1

Potential Implementations

Ethernet, the IBM token ring and emerging technologies
such as the Fibre Distributed Data Interface (FDDI), areprime candidates for implementation of control and/or
data bus architectures. FDDI, with its high bandwidthand deterministic response, could perform both control anddata bus functions. In some situations, provided that its
bandwidth and non-deterministic response is acceptable,
ethernet could be used for both functions at a considerably lower cost.

3.2

Transport Layer Issues

The Internet virtual circuit transport layer protocol, TCP,
employs a sliding window protocol. When used for realtime control on an unreliable network, this protocol may
exacerbate non-deterministic response due to the retransmission of unnecessary data segments. In addition, sincea sliding window protocol transmits a number of segments
before waiting for an acknowledge, unacceptable time delays may be introduced in waiting for urgent control in-

Session/Presentation Layer Issues

As shown on Figure 1, the Internet protocol stack has no
session layer. For the reasons described in Section 2, asession layer employing a synchronous message-based semantic is considered desirable.
The Internet protocol stack also lacks a presentation layer. For a message-based session layer, the criticalpresentation layer service is one which ensures that the
representation of data is the same regardless of the platform employed. The use of such a service ensures that a
distributed network of heterogeneous processors can understand each other's messages. The External Data Representation (XDR), which has been designated RFB1014
by the ARPA Network Information Center, provides therequired presentation layer functionality.

4

The Socket Server

During the KAON Factory Project Definition Study, a session layer protocol for network communication was developed which implements network communication using a
synchronous, message-based semantic. In addition, a reliable virtual circuit transport layer which does not employ
a multiple segment sliding window protocol was developed
over UDP. This protocol suite is known collectively as thesocket server[4] and consists of three co-operating objects
which communicate via a synchronous message-based semantic.
The session layer of the socket server is embodied in the sockeLserver task and a reliable virtual circuit
transport layer is embodied in multiple paired instancesof socket-task and recvfrom_task. Socket server clients use
the ss_open primitive to open a network connection and thess-close primitive to close a network connection. Once a
connection is open, socket server clients communicate witheach other via the synchronous, message-passing primitives
ss-send, ss_receive and ss_reply.
The socket server has been successfully implemented
on Unison, VMS, Mach and SunOS 1 platforms. Ethernet
message-passing performance between a Unison platformand VMS, NeXt/Mach and SunOS platforms has beenmeasured. ·Socket server ports to RISC platforms are forthcoming.

5

Performance Evaluation

The hardware configuration of Figure 2 has been used toevaluate socket server performance. The transceiver fanout was used to connect two or more systems for performance measurements. The VMEbus Unison platform consisted of a 25 MHz Motorola 68030 processor board and a
1 Sun 3/60

S08NC04
Network and Communication

303

303

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

ISO/OSI
7

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC04

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

Site Ethernet

•

18

"'+

~ 16 0Cl<flE...._. 14

.•.

ID

I

E

tL __

VAXstotion 2000
VAX 8650
VAXstotion 3100 M76
Next (68040)
Sun 3/60

i= 12

.•·

...

. .r,·

....

ID

x

VMEbusProcessors(UNISON)Sun J/60(Unix)

10

c
0
8
'a
ID
;::!; 6

Test

Platform

Other
computers

40

Figure 2: Equipment Block Diagram

200

400

600

Message Size (bytes)

800

1000

Figure 4: Socket Server Performance

80000-t-~~~~~~~~~~~~~u-n-ix_~o-02_8_6_1r

Sot Apr 13 13:16;15 1991
Elapsed time = 1096 sec
Num xi er s
100000
UNISON timeout = 100 msec
UNIX timeout
100 msec

60000

6Transfer statistics (msec)
Mox = 196.25
Min = 4.25
Meon = 5.033613
Median = 4.75
Std devn = 3.286174<fl§ 40000
0

(..)

20000

0-1-~_.,......!...L.J..,.L..I::::l=.~~-.-.~~~~~~..--~-+-

3

4

5
6
7
8
9
Transfer Time in Milliseconds

10

11

Figure 3: Four Byte Message Transfer Times
low-cost ethemet processor equipped with a 10 MHz Motorola 68010 processor. The Sun 3/60 served as the software development host for the Unison system and was thefirst test platform for the socket server performance.
Round-trip message transfer times were measured
by the Unison client, which communicated with the nonUnison client using the ss..send primitive. The Unison
client also employed ss..send to periodically transfer theacquired data to the non-Unison client for storage in a
file. The one-way message transfer time was taken as halfof the round-trip time. Figure 3 illustrates a typical histogram of one-way message transfer times obtained duringperformance tests for a Sun 3/60. 2
For the purpose of performance measurement, only
the Unison platform used the native synchronous messaging primitives for inter-process communication among thesocket server tasks. The VMS, Mach and SunOS platforms were evaluated using a single-threaded variant of
the socket server which emulated message passing using
message copying and function calls.
2 The 10 millisecond bin of Figure 3 contains the sum of all counts
for which the one-way message transfer time was 10 milliseconds orlonger.

Results

Figure 4 presents graphs of message size versus mediantransfer time for each configuration tested. 3 For each setof points, the data was fitted to a line, which is also shown
on Figure 4. Since the Unison platform was common to allmeasurements, Figure 4 shows the relative performance ofthe non-Unison platforms tested. Figure 4 indicates that
the NeXt platform obtained the best performance for small
message sizes. However, for message sizes greater thanabout 200 bytes, the Sun 3/60 performance was superior
to all others. The VAXstation 3100 M76 and the NeXt
platform were quite similar in performance, despite thelarge difference in their costs.
As only the round-trip transfer time was measured,
it is impossible to separate the Unison and non-Unison protocol overheads. However, the round-trip transfer time wasrecently measured between the Sun 3/60 platform and ahigh performance Unison platform using a single 25 MHz
Motorola 68030 processor with on-board ethernet. The
median transfer time between these platforms showed an
improvement of only 0.75 milliseconds as compared to thetransfer time measured between the Sun 3/60 and the twoprocessor Unison platform which was employed for the restof the tests. This suggests that the low performance ethemet processor in the two-processor Unison platform does
not make a significant contribution to protocol overheads.
The Unison overheads will be established by a forthcoming
measurement of the round-trip transfer times between two
identical Unison platforms.
Table 1 presents the median message transfer rates
for each platform tested. The NeXt achieved the highest message transfer rate of 250 messages/second for 4
byte messages. An ethemet implementation of the control bus would be limited to this i:na.ximum message transfer rate for present day CISC processors. However, aperformance improvement is anticipated upon completionof the forthcoming socket server port to RISC platforms
3 The median transfer time has been chosen 1111 it provides a better
indication of the peak on the corresponding histogram.

S08NC04304

Network and Communication

Platform

VAXstation 2000
VAX 8650
VAXstation 3100 M76
NeXt
Sun 3/60

Data transfer rate
(messages/second)
4 byte1018 byte
messages messages
93
53
148
60
211
82
250
83
211
105

Table 1: Median Message Transfer Rates(SPARCstation, DECstation). Although ethernet is nondeterministic, the histogram of Figure 3 is sharply peakedat the median transfer time. Very few one-way transfers
required more than 6 milliseconds and the maximum transfer time was 196 milliseconds. Provided that the ethernet
bandwidth is adequate and that ethernet saturation can
be avoided, this level of determinism may be acceptable
for some control bus applications.
Table 2 presents the median data transfer rates obtained for each platform. For a 1018 byte message, thedata transfer rate for the Sun 3/60 platform was in excess
of 100 kbytes/second. If ethernet were employed for thedata bus, the maximum data rate would be of the order of
100 kbytes/second for CISC platforms. It is expected thatsuperior data. transfer performance would be obtained if
the socket server employed a multiple segment sliding window protocol (TCP) for data bus transfers and reserved thenon-sliding window protocol for control bus applications.
Since it is suspected that the largest contribution
to socket server protocol overheads is made by the nonUnison processor, the forthcoming socket server port to
RISC platforms may considerably enhance socket server
ethernet performance. However, FDDI is the prime candidate for truly high performance control and data bus
applications. 4 Due to its redundant counter-rotating token ring scheme, FDDI is both reliable and deterministic. Since the FDDI standard incorporates a layered software and hardware architecture, it will easily accommodate change and platform heterogeneity.

7

Conclusion

The socket server is well suited for communication among
distributed heterogeneous systems. For instance, the synchronous message-based semantic has recently been ported
to VMS platforms and this enables a multi-process VMS
socket server. Since the socket server uses Unison messaging primitives, it will function in both the Unison/Reliant
and the Unison/pSOS+ environments. A socket server
port to the VxWorks real-time operating system is also
anticipated.
4
A Unison TCP /IP and UDP /IP port to FDDI is anticipated by
Fourth Quarter thls year.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC04

Platform

VAXstation 2000
VAX 8650
VAXstation 3100 M76
NeXt
Sun 3/60

Data transfer rate
(kbytes/second)
4 byte1018 byte
messages messages
53
0.36
0.58
59
81
0.82
0.98
83
0.82
105

Table 2: Median Data Transfer Rates
If the protocol overheads of a layered network implementation are unacceptable and present day technology
must be employed, the KF CCS control and data buses
must be implemented using custom/proprietary systems.
Such systems may be networked systems using custom
hardware and software, they may be distributed sharedmemory systems or they may be hybrid shared memory /networked systems. In general, such systems are more
awkward to implement and expensive to maintain because
they do not easily accommodate change. In addition, typical custom/proprietary systems do not easily support an
operational environment which consists of heterogeneouscomputing platforms.
The ethernet socket server is suitable for control anddata bus applications provided that its limitations (250messages/second, 100 kbytes/second, non-deterministic)
are acceptable. If these limitations are not acceptable then
RISC/FDDI socket server ports or custom systems are required.

References[l) C Inwood, G A Ludgate, D A Dohan, E A Osberg, and S Koscielniak. "Domain-driven specification techniques simplify the analysis of requirements
for the KAON factory central control system". Nuclear Instruments and Methods in Physics Research,
A293(1,2):390-393, 1990.
[2] E A Osberg, G A Ludgate, S Koscielniak, and D A
Dohan. "Dynamic object modelling as applied to
the KAON control system". Nuclear Instruments andMethods in Physics Research, A293(1,2):394-401, 1990.
[3) Peter J M Baker. "A programming paradigm basedon the send-receive-reply task communication primitives". Master's thesis, Department of Electrical andComputer Engineering, University of Victoria, Victoria, B.C., Canada, 1988.
[4] Neil A. Wilkinson. "Message-based network communication between heterogeneous systems". KAON Factory Project Definition Study TRI-DN-91-Kl64, TRIUMF, 4004 Wesbrook Mall, Vancouver, B.C., Canada
V6T 2A3, June 1991.

S08NC04
Network and Communication

305

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-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

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

ICALEPCS1991, Tsukuba, Japan

stalled in each building in order to transmit the timing signals
around the SPS. These were eventually duplicated in order toreduce the downtime of the machine.

an access point. These filters require tuned circuits which do
not lend themselves to large-scale integration, which require
careful setting up, and which are prone to drift. This, togeth- ·er with the general trend towards digital transmission, led tothe decision to use time-division multiplexing for LEP.

C. The Timing Distribution Standard
The local distribution of the timing information is done
according to EIA specification RS-485. The data format
adopted is supported by integrated circuits from National
Semiconductor (the NS8342/8343 transmitter/receiver set).
These ICs frame the 32 bit event into four bytes. Each frame
is enveloped within a predefined start/end sequence and in
addition each byte starts with a synchronizing bit and ends
with a parity bit. The NS8343 receiver chip contains a sevenbit error register which indicates the detection of a mid-bit
transition fault, an invalid ending sequence and also a parity
error. The contents of this register are used for error detection.
The entire frame is Manchester encoded. This coding
scheme was developed at Manchester University in the U.K.
for data recording onto magnetic media. The principle characteristic of the code is that no D. C. component is transferredto the transmitting line medium. This is achieved by ensuringthat each data bit has an equal negative and positive component, as shown in Fig. 1.

"l

II

"O"

mid-bit_O/transitio~:-u- --o-:bitperiodbit
periodFig. 1 Manchester Encoding
The use of Manchester coding doubles the bandwidth
requirement because each bit period must contain a mid-bit
transition.

III. MULTIPLEXING SYSTEMS
There are two main methods of multiplexing: frequencydivision multiplexing (FDM) and time-division multiplexing(TDM). FDM uses a different frequency band for each signal; analogue filters are used to extract the required signal at

In time-division multiplexing a number of bits are taken
sequentially from each of the multiplexor's input ports andapplied to the output port. The converse operation is appliedin the other direction. 1bis procedure is shown, simplified,in Fig. 2.

Fig. 2 Simplified TDM System

In practice TDM systems are far more complex. 1bis isbecause the high-rate data streams carry extra information,
particularly for synchronization purposes and in order to deal
with clock rates which are only nominally synchronous.
TDM equipment is used widely around the world byPTis and other telecommunications suppliers and users. The
standards for the equipment have been set by the CCITT
worldwide [4]. Since compatible equipment is available froma large number of vendors, the market is very competitive
and therefore the prices are low.
As previously mentioned, it was decided to adopt TDM
technology for LEP [2]. 1bis is used to transmit the machine
timing and also the revolution frequency timing information.
The latter system has been fully described elsewhere [3].

The timing events are transmitted at 512kbit/s over a
2.048Mbit/s TDM link. At the 2.048Mbit/s data rate theG. 703 Recommendation specifies a coding scheme known as
HDB3. The TDM-Timing interface unit makes this code
conversion transparent to users of the timing system.
The interface standard (CCITT Recommendation G.703)
for these high speed connections is being used more andmore frequently. For example, video CODECS, LANbridges, and terminal concentrators are available with G. 703
interfaces. However, one disadvantage of using a standardized approach to interfacing is that, in special situations someinterface conversion is required. As will be shown later thecost of this conversion, in the LEP situation, is outweighedby the economies brought about by multiplexing.
In the case of the interface between the timing systemand the TDM network it was decided to subcontract to industry the design and production.

S08NC05
Network and Communication

307

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

In addition a separate twisted pair cable was used totransmit the revolution frequency (43kHz). Identical amplifiers were used in each building; again they were duplicated.
This latter system is still operational, whilst the SPS general. machine timing has since been upgraded to the LEP system.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC05

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

IV. DESCRIPTION OF THE TDM-TIMINGINTERFACE
Fig. 3 shows a block diagram of the TOM-Timing interface.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC05·1·
Correct code:
Incorrect code:

·o·
1100
0100
1000
1110
1101

Correct code:
Incorrect code:

•

•
•

0011
1011
0111
0001
0010

Table 1 Single-bit Errors

HD83
ENCODERHDB3DECODERICALEPCS1991, Tsukuba, JapanERROR
CORRECTION

DIGITAL
DELAY

fig..], TDM-Timing Interface
The interface unit was specified at CERN but designed
and manufactured externally. The four principle parts of theinterface are described below.

A. HDB3 Decoder/Encoder
The incoming 2.048 Mbit/s data stream is first galvanically isolated and terminated in a 75 Ohm resistive load.
Thereafter, it is passed on to the HDB3 decoder. The HDB3
code is somewhat similar to Manchester coding, in that it has
a low DC component and also contains clock information,
but it is much more efficient in bandwidth usage. The HDB3
decoder generates a NRZ data signal and associated clock. In
addition the decoder generates two alarm signals: "loss of
input• which is activated when the input is no longer present,
and "violation• which is generated when violations of the
HDB3 coding law are detected. Both of these signals aremonitored by the control system.
The HDB3 encoder simply performs the opposite function to the decoder, ie. it converts the NRZ signal to HDB3
code and passes it on to the outgoing transformer isolated
driver.

As can be seen from the above Table, in the event of asingle bit error introduced by the TOM network there is stillenough information to distinguish between a 1 and 0. In fact
the scheme can also correct some double-bit errors introducedby the TOM network. As this network has a very low error
rate ( < 10-12) this means that the error rate seen by the timing
system is virtually z;ero.

C. Transmission Delay Compensation
The SPS/LEP timing system was designed so that any
specified event would arrive at all of the. related equipment
around the machines with a one millisecond resolution encompassing a maximum jitter of two microseconds. Howeverin physically large accelerators such as the SPS and LEP
there are significant propagation and equipment delays. In
order to compensate for this, delays were incorporated in theinterface unit. Each delay consists of a 12 bit register incremented by the 2.048MHz. clock derived from the incoming
data stream. The required value can be Written and read by
the control system.
D. Local 'flming Output
The output of the timing interface conforms fully to theelectrical characteristics defined by CCITT Recommendations
V.11 and X.27 and EIA specifications RS-485. The differential signal is Manchester encoded.

V.REDUNDANCY
It can be seen that Manchester coding inherently introduced some redundancy, as does the superimposition of each
Manchester bit on the TOM links. In effect four 2.048
Mbit/s TOM bits are being used to convey one 512 kbit/s
timing bit.

At the specification stage of the TOM-timing interface it
was decided to exploit this redundancy and incorporate a

simple error correction system. Four TOM bits are taken at atime and applied to the error correction circuitry. The four
possibilities for single--bit errors when transmitting Manchester codes are indicated in Table 1.

Redundancy, or more specifically duplication, has been
installed following invaluable experience gained from theoriginal SPS timing system installation.
The TOM links provided for the SPS and LEP timing
systems have been configured in a double ring topology, onering for each machine. The links on each segment of the ringare inherently full duplex; this feature has been exploited toprovide two independently routed signals, following clockwise and anticlockwise routes around each ring. These alternate signals are used in the interface equipment for added
reliability.
Besides profiting from the full duplex feature of theTDM, the interface units were also duplicated as well as thepower supplies used to power the local line drivers. Switch-

S08NC05
308

Network and Communication

ICALEPCS1991, Tsukuba, Japaning to the redundant system is done automatically when necessary. In addition the selection can be made via the control
system. The equipment is constructed in Euromechanics as
defined in DIN 41914.

IX. REFERENCES[1]

C.G. Beetham, R.J. Lauckner, C.G. Saltmarsh, Overview of the SPS/LEP Fast Broadcast Message Timing
System, Proc. of the 1987 Particle Accelerator Conference, Washington, D.C., Vol. 1, p. 766.

[2]

C.R.C.B Parker, The Provision of Telecommunications
Links for the LEP Collider, 1989 Particle Accelerator
Conference, Chicago, Ill.

[3)

G. Baribaud et al., The Beam Synchronous Timing
System for the LEP Instrumentation, International Conference on Accelerator and Large Experimental Physics
Control Systems, Vancouver, Canada 1989.

[4]

CCITT "Red Book", Fascicle ill.3, International Telecommunications Union, Geneva 1985.

[S]

C.R.C.B. Parker, M.E. Allen, H.C. Lue, C.G. Saltmarsh, A New Data Communication Strategy for Accelerator Control Systems, International Conference on
Accelerator and Large Experimental Physics Control
Systems, Vancouver, Canada 1989.

VI. COST CONSIDERATIONS
It is clear that the cost benefits brought about by the useof multiplexing will be greater as the number of channels ona link increases. In the case described here each link carries
three channels: 2Mbit/s for the general machine timing,
2Mbit/s for the beam synchronous timing, and 8Mbit/s forthe machine control token ring.

A careful analysis of the cost of the installation has been
done, as well as an estimate of the cost involved in implementing the transmission of these three channels in the traditional way on dedicated links. It was found that these twocosts were roughly equal, ie. in this case there has been, asyet, no significant cost advantage in multiplexing. However,there is considerable spare capacity to each of the 24 locations served by the network, and this allows extra channels tobe put into service very quickly and cheaply, as no significant additional cabling is required. This flexibility has already proved extremely useful.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC05

VII. CONCLUSIONS
Although in terms of bandwidth, the timing system is
not a major user of the TDM system it is a vital user, ie. if
the TDM is not operational, the timing system cannot work.
The use of the TDM network for the transmission of timing
information has proved to be more reliable than the previoustransmission system which used dedicated cables and repeaters.
The error-correction features are extremely effective:
since the introduction of this system there has been no lostbeam time due to transmission errors. The cost of supplying
the extra bandwidth for error correction is far outweighed by
the advantages of improved reliability, and error correction
would be an indispensable part of any future system. In fact
studies of advanced error correction algorithms are presently
under way with a view to using these techniques for a pilot
implementation of an integrated fast control and timing system [S].

VIII. ACKNOWLEDGEMENTS
Many people have contributed to the success of the project to transmit timing information in the manner described inthis paper. Particular mention must be made, however, of
B. Amacker and P. Nouchi.

S08NC05
Network and Communication

309

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-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-S08NC06

Table 1 An example of distribution of network load(time interval 4450 sec, trach level 1.5 %,40 machines in the PCR ring)
Input packets
host
abs.
aldev55431
consll1568
cons14
3107
fspcr
22739
piper!
2192
rfsba32263

Output packets
rel.[%]
abs.
13.02 :xxxxx
5096
4.27
x
1673
2928
7.48
:xxx
227239 58.11 x:xxxx:xxxxxxxx
5.19
:xxx
2033
2060
5.26
xx

rel.[%]
12.14 xxxxx
3.51
x
6.95
xxx
53.30 xxxxxxxxxxxxx
4.9
xx
5.06
xxx

Table 2 An example of hosts activity(scan interval 360 sec., trash level 1.0 %)Scan interval/ Activity [%]hostaldev5aldislaldis2colsepconsllcons14fspcr
piper!
rfsba3

1

2

3

4

5

6

7

8

9

10.9

22.5

22.5

33.4

22.7

32.7

7.1

4.8

6.5

1.4

10.7

2.8
42.9
35.0
4.0

6.2
3.8
29.6
9.8

6.6
2.6
47.8
10.1

7.5
1.3
35.6
10.6

5.8
20.3
28.2
9.9

8.4
3.5
31.8
13.7

1.9
2.5
83.6
2.5

5.8

1.7
2.7
84.8
2.5

at the start of my work I didn't know about this paper. The
results from this study are for similar conditions approximately
the same, the main difference is in the method of measuring.
While the measurements described in [6] took many hours, mymethod takes only a few seconds and the load of the measured
object was minimal. It allows these measurements to be madepractically on-line without interrupting normal operations in
the ring or in the host Another new effect which has not been
mentioned in [6] is a problem with ring interconnections.
This is mentioned in [4] but there are only figures for a one
packet pass. From the point of view of a normal user of RPC
this is very important because in normal circumstances theeffect increases with each packet and it is also directly connected with the global topology of the network.
Random timing measurement have shown that the response time is sometimes quite high and more dependent on
the hardware of the computers which are involved in the communication than on other known aspect such as position of thehost in the ring, distance or speed of the transmission system !
The results of RPC response time from one host to several
others in the network are shown in table 3.
Explaining this effect is rather simple. The token ring isbased on the IBM TR system with frequency slightly modified
to 4,225 MHz. And if we assume that the physical level of
the TR system is capable of transferring data at about 4.0
Mbps [3] then the time used for the real physical transmissionof data used in the RPC (< 1 kbyte) are in the microseconds
range which is negligible compared with the time consumed by

54.2
2.3
26.2

all communication software layers implemented under Unix
(including the RPC layers).
Timing measurement were done by a trivial client program
which was running in the selected computers and a standard
program which was running everywhere as a permanent server.
The results from many measurements showed that thefaster reply came if both source and destination were fast computers. The following measurements showed the interesting
fact that the same result was possible to get if both the Client
and the Server program run in the same computer. This allowed simplification of the whole measurement and to define aRound Trip Response Time - RTRT which could be taken as a

Table 3

RPC Response time from the PCR ring

from
ring

(host)

ringto(host) response

per
per
per
per
per
per
per
per

aldev5aldev5aldev5aldev5aldev5aldev5aldev5aldev5

Ima
Ima
lsv
lsv
laa
laa
lbar
ldev

hnagrhnabile28lmgrlsv
eolsr2hngrlaarecpcaaldev4olive

170 ms
190 ms
170 ms
220 ms
170 ms200 ms
210 ms
250 ms

S08NC06
Network and Communication

311

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·reference characteristic for a particular type of machine. The
values include time for connection. This time was about 80 100 ms for the 180286 processors and 60 ms for the 180386
machines (Olivetti M380/C).
All previous measurements were taken in one simple ring.
Working outside simple rings brings another aspect to be taken
into account. The rings are Jinked together by bridges andgateways. These devices (driven by software) need some time
for doing their job. It was surprising to find that the delay inthe bridges is, from the point of view of this measurement,
negligible but the delay caused by the gateways is rather high.
The values for different gateways on the network were
measured for our type of request as being between 15 to 50
ms (worse for 80286 - 45 ms and the best for
CISCVO/DATATRAC-15 ms). It is necessary to emphasizethat these times represented an average case from a not very
loaded gateway. These figures can be much worse and they
will be quite heavily dependent on the traffic through aparticular gateway. Knowing the characteristic of the particularconstitutive elements of the system and also knowing the
topology of the network we could relatively easily synthetically estimate the best response time for the different paths in
the network.
Finally I would like to bring to attention several otherimportant problems which are connected with the use of theUNIX operating system and which put a little more light on
the results.
The first problem is the Task Management. All results
which I have presented here were directed towards the communication area and therefore I always had to use the shortest
response time (best case from many measurements). Thatmeans that they were taken after the server process was firstly
activated. The response time of the first request in which theactivation (fork) is done contains another delay and therefore
the first RPC response is much longer than the RTRT presented in previous tables. In practice it represents a time
between 0.3 - 6 sec. depending on the load of the host. For
the user it means that he must calculate this fact and if heneeds fast response must keep his process in permanent activity instead of starting it repeatedly.
A second problem is more general. Performing short accurate software timing measurements within UNIX is practically
impossible. There is normally a timer running with microseconds accuracy, however the system doesn't update it's software

image fast enough. There is a 20 ms timing quantum which I
couldn't overcome. This limitation was very annoying mainly
in cases of very fast processors and this fact could have an
influence on the precision of the measurements.

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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC06

IV.

CONCLUSION

On the basis of these results and know ledge of the network
topology we can estimate the response time in any part of the
network. This can be useful for future decisions or for reconfiguring the system because other applications will have similar response time overheads. The measurement also showedthat the communication system has enough capacity to transfer
substantially higher load through the network and also showsthat the bottle-neck of the communication system is not in the
hardware level of the TR but rather in the software or hardwareof the hosts and gateways.

v.

ACKNOWLEDGEMENT

The results of that work has been made possible by theclose collaboration within the team. I would like to thanks
particularly P. Lienard, L. Guerrero and A. Bland for their contribution to this work and P. G. Innocenti and K. Kostro forfruitful discussions.

VI.

REFERENCES[1] P. G. Innocenti, "The LEP Control System", International
Conference on Accelerator and Large Experimental Physics
Control System, Vancouver, Canada, November 1989.
[2] P. Lienard et al., "The SPS and LEP Control Network
Architecture", International Conference on Accelerator andLarge Experimental Physics Control System, Vancouver,
Canada, November 1989.
[3] J. S. Haugdahl, "Inside the Token Ring", North-Holland
1987.
[4] K. Kostro, ''Host Performance in the TCP/IP Internet of
SPS", Internal report, CERN-SPS/ACC, January 1989.
[5] P.S. Anderssen, V. Frammery, G. Morpurgo, "User guideto the Network Compiler Remote Procedure Call
{NC/RPC), LEP Control Note 97, May 1989.
[6] P. Van Der Stock "Remote Procedure Call
Measurements", CERN SPS/ACC Note 16/12/1988.

S08NC06
312

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

integrity: the BC sends a receive/transmit command word to
the addressed RT, eventually followed by up to thirty-two datawords; the RT receives the command, receives or transmits
data as directed and responds with a status word. Parity
checking is applied on each word boundary.

In order to provide the necessary flexibility of the control
configurations implemented for ELETfRA, the field highway
must be able to operate over distances up to some hundreds
meters: with the chosen implementation, a raw bit transfer rateof I Mbit/s over about 300 m can be achieved; lower
transmission speeds for longer distances are possible.
The MIL-1553B standard permits to send broadcast
messages, which are often useful for accelerator control:
issuing a special type command word, the BC can transmit to
all the connected RTs at the same time.

u

u
~
=
=
= == =
u u "" ""....
== ~ ~""" ~""
a)

a)

ll'l
ll'l

~

C,)

"1

<'I

ll'l
ll'l

ll'l
ll'l

ll'l

~

~

::E

-----

Derivation Box
.

Stub
cable

ll'l

LPC VME bus crate

MIL-1553B-•.• ·:.">: .·:.·.: .........·-::

MIL-1553 RT

MIL-15538 RT

SBC

SBC

i/O BOARDS

1/0 BOARDSEIU VME bus crate

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC07

EIU VME bus crate

Figure 1. The ELETTRA field highway system.

ill. THE ELEITRA FIELD HIGHWAY HARDWARE
IMPLEMENTATION
The highway physical medium consists of a 100 %shielded twisted-pair cable which has a characteristic impedancezo = 78 Ohm; each branch is matched by two termination
resistors of value zo ± 1%. The nominal attenuation,measured on a 1 MHz sinusoidal signal, is about 15 dB/Km;
the wire-to-wire distributed nominal capacitance is 64.6 pF/m.
Each MIL-15S3B device (BC or RT) connects with thehighway through a so called derivation box and a short (lessthan 2 m) stub cable: the derivation bo.x contains a couple ofresistors which are serially inserted on the two stub cablewires in order to prevent BCs or RTs from damaging in caseof short circuits on the highway.
Both the BCs and the RTs [4] are equipped with on-board
transformers for ground isolation between nodes. They use acommercial type VLSI protocol chip automatically dealing
with the "acknowledged message" exchanging mechanism
described above.
The BCs have been integrated in the multiprocessormultimaster environment of the ELETfRA LPC. Startingfrom a CERN/SL BC design [5], we developed a standard
VMEbus Requester and implemented some hardware
modifications [6] in order to achieve full compatibility withthe other LPC commercial VMEbus SBCs; this.allows future
increases in the LPC performances as more powerful boards
are available on the market. The OS-9 operating system isinstalled on each BC board

C. Deterministic response
Dealing with the accelerator equipment at the interface
level, the undefined network access times associated with the
CSMNCD (Carrier Sense Multiple Access with Collision
Detection (3)) methods of Ethernet cannot be accepted; aIV. BASIC COMMUNICATION SOFTWARE
detenninistic behavior of the field highway is strongly
The communication software allows both MIL-15538
requested. In the MIL-1SS3B standard configuration the BC"polls" (the so called "roll-call polling" type [3] is used) the equipment and VMEbus LPC SBCs to exchange user.
status of its RTs at regular time intervals under software messages.
The communication software for the field highway system
control and checks if new data is ready to be received. On thisbasis, real time operation with pre-configured timings is mainly consists of three layers (figure 2): physical, translation
and routing.
achievable.
D. Cost and peiformance
The price of the single highway interface bOard must be
carefully considered, as a high number of nodes (about 100) areconnected, especially at the RT level. Using commercial typeelectronics, the cost of an RT node is lower then that of astandard input/output interface board. The adopted physicalmedium is also inexpensive and no special installation tool isneeded.

A. Physical layer
The physical layer is mainly in charge of shielding the lowlevel communication details. Since many MIL-1SS3B boards
can be both BC and RT, we decided to split this level into twoparts; the first one is strictly related to the adopied hardware,
while the second part handles the most common functions(circular buffers, fragmented packets, etc.). After defining aphysical number for each board, user applications can easily

S08NC07
314

Network and Communication

314exchange data packets through the network, independently ofthe hardware used. The physical number is fixed by on-board
switches and it is not usually changed after the first setting.
The only drawback of this addressing mode is that identicalboards with different numbers cannot be exchanged without
modifying and recompiling all the user programs.

Application
Communication
Services
RouterTranslation
Physical

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC07

V. THE ROUTING LAYER INTERFACE LIBRARY
A clear interlace library to the routing layer functions isprovided to allow a straightforward implementation of thehigher level services. This interlace consists of a collection of
C language routines which have a common first argument: thecommunication channel number. This is an integer ranging
from 0 to 7, w.hich is associated with a routing path, a service
code and a cirCular buffer for the' incoming user messages. At
present only one channel per process is used. but up to eight
are available to increase flexibility.
The description of the principal library calls follows:
error = OpenRouterService ( channel, bufuum, service )int error;
router error code or zeroint channel;
channel number
int bufnum;
number of circular buffers
short service;communication service code
OpenRouterService opens a communication channel with a
specific service code;·

Figure 2. The ELETTRA field highway software layers.

error = CloseRouter ( channel )int error;
router error or zeroint channel;
channel number

B. Translation layer
The translation layer, built on top of the physical one,
avoids the aforementioned problem. It consists of an OS-9
driver maintaining an internal table of correspondences
between physical numbers and the new logical station
numbers which are used by the routing layer. A logical station
number is associated with each LPC board and with the SBC
managing the EIU RT.
C. Routing layer
The routing layer, or router, perfonns a reliable user
message transmission starting with a configuration file which
describes the logical system topology. All the stations
attached to the same physical medium (V'MEbus or MIL1553B) fonn a so called "subsystem" and the configuration filecontains as many lines as the subsystem number.

CloseRouter closes the specific channel previously opened
by OpenRouterSeIVice;error= WriteMsg ( channel, buffer, len, dest, Service)
int error;
router error or zeroint channel;
channel number
char *buffer;message buffer
message length
int len;short dest;
destination logical station number
short seJVice;
communication service code
WriteMsg transmits a message to the specific destination
station in a reliable way;error= WaitMsg ( channel, timeout )int error;·router error or zeroint channel;
channel number
in timeout;
timeout in system ticks, 0 for
infinitum

Many advantages are associated with the layered
architecture. The software is easily ported on different
MIL-1553B boards; user messages between two stations
attached to different subsystems can be exchanged
WaitMsg waits for a user message to arrive. The type of
independently of the interconnecting physical medium; the service is fixed by the OpenRouterService function.
identical routing interlace is maintained. In order to add new
subsystems and stations, the following steps have to be taken:
VI. COMMUNICATION SERVICES• develop a new dedicated low level hardware driver and
The described communication interlace is the base on
eventually a new address translation driver;which
all the communication services are built. Even if it• assign new logical station numbers to each subsystemrepresents
a flexible and hardware independent interlace, it
SBC;
be
given
to the application programmers for software
cannot• add the new subsystem station numbers to a new line ofdevelopment. A typical user is not, in fact, aware of thethe routing configuration file.
logical station numbers, circular buffers and communication

S08NC07
Network and Communication

315

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-S08NC07~~"·i.•.f ~C\des; he rc.fers to the accelerator equipment only by

i,1p.::al names and uses the communication services without
ial.in£ care of the control system topology details. In order topr,~,·1de a completely symbolic equipment access [7] [8], wehave developed a higher software level, which shields part of
the router library function parameters.
The Symbolic Address Resolution, Command/Response,
lnform, Alarm and Broadcast services have been written. Their
implementation is based on the general concepts of client andserver processes, with clients located on a LPC(Command/Response and Broadcast) or an EIU (Infonn andAlarm) according to the different service types and data flow
involved.
A. Symbolic Address Resolution service

This special service hides the incoming user message
logical routing from the application programmer. It consistsof a server process running on the LPC and an associated tablecalled Equipment Directory Unit (EDU).
When a client request arrives, the server process looks up
the logical equipment name in the EDU and translates it into a
logical station number. Moreover, the server checks theequipment access pennissions and provides for on-line EDU
reconfiguration.

B. Command/Response service
The Command/Response service allows the user
applications to access the equipment. There are two operating
modes: synchronous and asynchronous. In the first case theclient sends a command and suspends its execution until a
result comes back from the server. In the asynchronous modethe client process sends a command without stopping and,after some time, reads the results prepared in the meantime by
the server process.
A typical Command/Response request, including EDU
access, takes about 30 ms.

C. Inform service
The Infonn service has been developed in order to cater forthe necessity of sending data from an EIU to the LPC without
waiting for an LPC data request.
The Inform is therefore very similar to the
Command/Response service: the main difference is that itallows only unidirectional data flow.

D. Alarm service
The surveillance programs have a fundamental role among
the processes running on an EIU; they continuously check theequipment status and detect anomalies or fault conditions.
When a serious error occurs, these programs must act as client
processes sending an alarm message to the associated LPC
server. In this special case we are interested in delivering analann message as fast as possible. In order to increase thetransmission speed, the alann message does not access the
EDU table for symbolic destination address resolution.

E. Broadcast service
The Broadcast service pennits to send the same user
message to all the EIUs attached to the same MIL-1553B
multidrop highway branch. Exploiting the MIL-1553B
standard broadcast capability described above, we are studying
the possibility of using this service to generate a softwaresynchronization among the EIUs: the transmitted broadcast
messages can in fact produce hardware interrupts on the EIUs,
waking up the processes to synchronize.
VII. IMPLEMENTED LAN UTILITIESTaking advantage of our layered software structure, we havedeveloped a special level which interfaces the Translation
Layer with the commercial OS-9/NET [9] communication
software package (figure 3). OS-9/NET is based on the
Network File Manager (NFM) and provides for typical Local
Area Networks (LAN) utilities like remote login andhomogeneous file access. These tools are the basis for the
distributed software development environment we created in
our laboratory: using a single LPC equipped with a disk, we
can download software and start ~sk execution in the diskless
EIUs; moreover, the laboratory LPC. works as a common
remote disk server and virtual tenninals can be opened on the
EIUs for software testing.

Application
OS-9/NetSpecialTranslation
PhysicalFigure 3. OS-9/Net layer implementation.

In the final system implementation, where diskless LPCs
and EIUs are installed, NFM and tCP/IP tools can beeffectively combined. In this way a remote login from thecontrol room can be executed on both LPCs and EIUs; a
UNIX disk server can also be shared by all the field highway
system stations.
VIII. CONCLUSIONS
Starting from the military MIL-1553B communication
standard, a multidrop field highway has been developed for thecontrol of the ELETTRA equipment.

S08NC07
316

Network and Communication

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC07

Despite the low cost of the used communication boards(BC and RT) and physical medium, the typical functionalities
needed for accelerator control are catered for. Compared withexisting similar products, the implemented .MIL-1553B
highway offers one of the best cost/performance ratio
available.
The chosen VMEbus MIL-1553B BC board has been
integrated in the multimaster environment of the ELETTRA
LPC, increasing system performance at least by a factor oftwo.
The layered communication software allows to send data
packets between the LPC SBCs and the dropped EIUs in acompletely transparent way. A data transmission rate of 70
kbytes/s has been achieved with 100 byte packets.
The implemented LAN utilities are currently used for thedevelopment of system and application software.

IX. ACKNOWLEDGEMENTS
We are grateful to the CERN/SL control group who
supplied the first MIL-1553B equipment and software, fromwhich our development started. We thank Luca Barbina andLuca B. Giovannetti for their valuable technical support

X. REFERENCES[1] D.P. Gurd and M. Crowley-Milling, "Preface" in Proceedingsof the /CALEPCS, Vancouver, BC, Canada, October 30November 3, 1989.
[2] M/LISTD-1553B, Aircraft Internal Time Division CommandResponse Multiplex Data Bus, Department of Defense,
Washington, DC 20360, USA, 1978.
[3] A. S. Tanenbaum, Computer Networks, Prentice-Hall
International Editions, 1988.
[4] D. Francart et al., "MIL-1553B Multidrop Bus forControlling LEP and SPS Equipment", LEP Controls Note 56
Rev., August 1987.
[5] C. Guillaume and C. Pignard, private communication.
[6] L. Barbina and D. Bulfone, "The MIL-1553B Bus Controller
Board for the ELETTRA VMEbus Multimaster Local Process
Computer", Sincrotrone Trieste Internal Report
ST/M-TN-91/3.
[7] "The LEP/SPS access to equipment", LEP Controls note 54
Rev., Geneva, March 1988.
[8] M.C. Crowley-Milling, "Naming Conventions for the
ELETTRA Components", Sincrotrone Trieste Internal Report
ST/M 88/13.
(9] OS-9/NEI' Version 3.0, Microware Systems Corporation.

S08NC07
Network and Communication

317

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

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

ICALEPCS1991, Tsukuba, Japan

Table 1
Computer systems used in the present performance tests. An
operating system and a rough estimate of the CPU power foreach comouter svstem is also 1dven.

have found several "small" differences in the socket functions
provided by different vendors, and have tried to include vendordependent parts within the library as many as possible. The
use of the C language is also preferable from this viewpoint.

Oneratinl! Svstem

MIPS

DEC DECstation5000

UL1RIX

24

Sun SPARCstation!

SunOS

12

NeXTNeXT

Mach

10

Mitsubishi MX300011

OS60/UMX(System-V based)

3

SXA(System-V based)

3

Fujitsu A-60

B. Communication Throughput
In order to study the overall communication
throughput, including library overhead, test programs with the
SCLIB functions have been prepared. We have carried out
measurements of the data-transfer times between two computer

(a)
100

o VAXatallonll/GPX -- NEC PC9B01ES
x VAX1tallonll/GPX -- VAXolallonll/GPX+ VAXllallonll/GPX -- FACOM A-60
x VAXatallonll/GPX -- SPARColallonl
VAXalallonll/GPX -- DEC1lallon5000"°

50

DEC VAXstationll/GPX VMS
WIN/fCP installed
NEC PC9801ES(16MHz,80386)

MS-DOSPCTCP installed

.....

«J

10

'V

interactive communication tool (like telnet). The libraryprovides C-language functions. A typical example is shown infigure l, together with the basic flow of the SCLIB function
calls.
The principles that we considered when we starting todevelop the library are the following: The first principle iscommunication availability between different operating
systems. We have adopted an inter-process communication
technique called "stream socket", which is based on the
TCP/IP protocol. It provides the basic network
communication functions with error-handling schemes for C
language. The socket .is one of the standard inter-process
communication methods in Unix-based workstations, and isalso available on other computer systems.
Since the socket functions require various kinds of
network parameters, it is almost impossible to use by those
who are not familiar with this field. Thus, the second principle
is to. prepare easy-to-use functions for application
programmers. As shown in figure l, the SCLIB functions
used in a client process require only two parameters: thedestination of data ("service_name@nodename") and the data,
itself ("message"). In addition, the existence of an errorhandling routine (sc_errend) makes the client program very
simple.
The third principle is to ensure high source
portability of application programs among computer systems
provided by various vendors. This leads to an easy replacementof the hardware of our present control system. Actually, we

6 Lw.'4-~-1-.Ll..LLl.10~1~.L....l-J...LI-Llll0~2__JL-.J....W-LL1.1.!;----L-'--'-'

packet size (byte)

10-l

101

102

packet size (byte)

Figure 2
Measured data-transfer times between the computer
systems listed in table 1.
(a) Data-transfer times between a VAXstationll/GPX
and other computer systems.
(b) Data-transfer times for other combinations ofcomputer systems. Two of them (SPARCstationl andDECstation5000) are the result of the case that two
processes are in the same workstation.

S08NC08
Network and Communication

319

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

Comnuter

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC08

ICALEPCS1991, Tsukuba, Japan· systems (processes) for the seven computer systems listed intable 1. The results for typical cases are shown in figure 2.
The following points can be pointed out.
(a) The data-transfer time takes 0.2-30 ms for 1-1000 bytes ofdata, depending on the CPU power of the computer systems
used.
(b) The data-transfer time remains almost constant as the size
increases from 1 to 100 bytes. It typically becomes twice as
the size increases from 100 to 1000 bytes.
(c) The best record among combinations of computers in table
1 was found in the case that the two processes are at the sameworkstation, DECstationSOOO. The data-transfer time was 0.21 ms for the 1-1000 bytes data.
(d) Assuming a data size of 1 kB, the overall throughput isevaluated to be 400-1000 kB/s for data transfer between typical
workstations (10 or more MIPS).
In addition, the dips observed at around 1000 bytes are
considered to be caused by the buffering scheme of the TCP
protocol.

daemon process in the gateway. The daemon process controls
the power-supplies according to the received message. It thenreturns a reply message which includes the result of thecontrolled power-supply. The SCLIB functions are used at themessage interchange between two processes.
An example of MGLIB function calls is also shownin figure 3. Here, an initializing function (sc_open for the
SCLIB) is not necessary, since initialization is carried out
automatically at the first call of the MGLIB functions.

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

B. Source portability
Some problems concerning source portability havewod<statlon 1r

I ISCLIB
MGLIB
I
I

'-

The round-trip response time between the operator anda local control device was studied in the present control system[l]. It was evaluated to be of the order of 100 ms for our dataof 128 bytes. According to the results of our present
measurements, one or two orders better throughput can be
expected in the next control system. If workstations withgreater CPU power (for example 40-100 MIPS) become
available in the future, further improvement in thecommunication throughput can be expected.
The measured communication throughput seems to be
sufficiently high for most of the applications required tocontrol the accelerator. However, it should be noted that thetime required to open network connection, which usually takes
0.1-5 seconds and is necessary each time to start inter-process
communication, is not included in the values given here.

1-

--1

workstation 2

I

r

,

~

a. Ethernet

lsr~r IPMGLIB I

(TCP/IP pro/OCO/)

I'I

daemon process
I SENDQ I ,J
'Present Control System(MELCOM70130)

ID.MAGNET CONTROL LIBRARY
The development of applications used to control themagnet power-supplies of the KEK linac was possible onlywith the minicomputers used in the present control system(Mitsubishi MELCOM 70/30) and its backup workstation(Mitsubishi MX300011). In order to realize a better
environment for software development, we first tuned theworkstation serving as a gateway between an Ethernet and thepresent control system [3]. We then developed a library called"MGLIB" in order to make it possible to control the powersupplies at any of workstations connected with the Ethernet.
The mechanism of how a power-supply is controlled
is shown in figure 3. When an application process calls a
MGLIB function, an information message is sent to the'Iapplication
process

C. Discussion

A. Introduction

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC08(

300 magnets)
in totalmalnO r appllcaHon process •1

IInt mgO, mg_errend(); r mgllb functions •1
extern Int m11_errno: r error c0de holder of mgllb •;rln •mg( "CUR', •magnet_name•, &curr ): r get magnet current •1
If( mg_errno < O) mg_errendQ: r error m861111ge & exit •1

Figure 3
Example of an application process which controls a magnet
power-supply of the KEK linac. Inter-process
communications between an application process(workstation 1) and a daemon process (workstation 2) are
carried out with the SCLIB functions (see text). Workstation
2 serves as a gateway between the Ethernet and the present
control system.

S08NC08320

Network and Communication

arisen during the development of the MGLIB. The mostserious one is the difference of byte order in the expression ofnumerical values. We have described byte-conversion routines
for each computer system with C preprocessor statements.
Since the conversion routines are described in the
MGLIB library, application sources are expected to show highportability. Actually, sample programs for basic operation of
the magnet power-supplies show perfect portability among
the computer systems in table 1. In addition, the basic
availability of the SCLIB/MGLIB functions is also checked ina Hewlett Packard workstation with HP-UX, and a Force
68030-based VME system with OS9.

C. Discussion
The typical throughput of a single control action is
obtained as 100400 ms. This value is understood to be theround-trip response time in the present control system.
After fotroducing the next control system, we should
re-develop a new daemon (server) process with a VME
environment. It would not be easy since the development ofsuch a server process requires deep understanding of the
network parameters and workstations, even with the present
SCLIB functions. However, the sources of applications
developed so far with the MGLIB functions will be available
without any modification, even in the next control system.

IV. DISCUSSION
One of the problems concerning an Ethernet is
response delays due to network packet collisions, which
inevitably occur in an Ethernet when the network traffic rateis considerably high. An easy answer to this is to replace an
Ethernet with a FDDI (Fiber Distributed Data Interface) fiberoptic network system. It is a token-ring type network and ismore suitable for a real-time purpose. In addition, we would
expect one order better communication throughput since it iscapable of a communication rate of 100 Mbit/s. Moreover, it
is worth noting that a replacement is possible without any
software modification.
The present libraries provide a possibility to use an
Ethernet as a high-speed data-transfer network with low cost.
There exists a plan to use these libraries for the control
system of the TENK0-100, a 100-meter long laserinterferometer aimed for detecting gravitational waves now
under construction in ISAS (The Institute of Space andAstronautical Science) [8,9).

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC08

VI. REFERENCES[1] K. Nakahara, I. Abe, R.P. Bissonnette, A. Enomoto, Y.
Otake, T. Urano and J. Tanaka, Nucl. Instr. Meth.
A251 (1986)327(2) K. Nakahara, I. Abe, A. Enomoto, Y. Otake and T. Urano,
Nucl. Instr. Meth. A247(1986)153[3] K. Furukawa, N. Kamikubota, K. Nakahara and I. Abe,
proceedings (Int. Conf. on Accelerator and Large Experimental
Control Systems, Vancouver Canada, October 1989), Nucl.
Instr. Meth. A293(1990)16[4] K. Furukawa, N. Kamikubota, K. Nakahara and I. Abe,
"Upgrade Plan for the Control System of the KEK e-/e+
Linac", this conference[5] K. Nakahara, I. Abe, K. Furukawa and N. Kamikubota,
proceedings (Int Conf. on Accelerator and Large Experimental
Control Systems, Vancouver Canada, October 1989), Nucl.
Instr. Meth. A293(1990)446[6] I. Abe, M. Kitamura and N. Nakahara, "A Diagnostic
Expert System in PF Linac Control", this conference(7) K. Furukawa, N. Kamikubota, T. Shidara, K. Nakahara
and G. Horikoshi, proceedings (14th. Int. Conf. on HighEnergy Accelerators, Tsukuba Japan, August 1989), Particle
Accelerators 29(1990)245[8] N. Kamikubota, K. Furukawa, K. Nakahara, Y. Ogawa
and A. Asami, "A study of the Control System for Long.
Baseline Laser Interferometer", the proceedings of the Sixth
Marcel Grossmann Meeting on General Relativity (MG6) inpress, Kyoto Japan, June 1991; KEK preprint 91-124[9] N. Kawashima, T. Yokota, Y. Ogawa and N. Kamikubota,"Development of 100 m Laser Interferometer Gravitational
Antenna (TENK0-100)", the proceedings of the Sixth Marcel
Grossmann Meeting on General Relativity (MG6) in press,
Kyoto Japan, June 1991

V.ACKNOWLEDGMENTS
We would like to thank Professor A. Asami, head ofthe lnjector-Linac division in KEK, for his support and kindencouragement We also thank the staff and operators of thelinac for their valuable discussions and assistance.

S08NC08
Network and Communication

321

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-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 Communication322

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

ICALEPCS1991, Tsukuba, JapanThe OBJP preprocessor program has beencreated as a result of a research of program
design of multi-task system. We notice theappearance of similar codes in many programs.
Fig.2 shows that a flow chart of aprogram which runs on multi-task OS
andresidents on memories. In the chart, both
"WAIT or DELAY" part and message select partare required from all our tasks. And almost
all of our tasks must send messages.
Our programmers arenotproperinprogramming, then good programming environmentis required. So, we avoid the method byeditor, so that the method by meansofautomatical formation has been chosen. For
this purpose, the preprocessor called "OBJP"
has been developed. The OBJP makes a PASCAL
source as shown in fig.3.
Simple program of OBJP source is shown in
fig.4, . It works really in our system forrelay-board control. This program is simpler
than one in which all possible items relating
to the network communication functions are
written.

/IHITIHIZER/

IA!T or DELAY
USSAGE

Typical flow chart of resident
tasks for control. Similar codes for
initialize part, wait for events andevent select appear in many programs.

0

B

J

P

OBJP

sources

PAS C A I.

co'" p l I e

LA

module

N

*.
Fig.3

K

L 0

load

Land

sourceconvert.

created.

ERROR := MakeMMIO! S_NAME , L , N )/COMMON/eon st=-PASCAL

Program development flow.
The OBJP is a preprocessor of PASCAL compiler.

pro9ram SOUNDPRO I Objective pascal.

TDELAY •IsomoduleSWITCH • W( Graphics and Oelayw

TASK

to

PASCALI"OBJP" programming/METHOD/TERM:
l:DCLK <:• 'MESS TERM WAAA'
OHHI1
MM := MESSAGEI:= MTOBIN ( MMJ:= MTOBIN ( MM1
K
if I <> 0 thenfor N := l. to I do
K := K * 2'WAAA'

000

I msec l/LOCAL/
const
OOTT
500
DMAOA• 0500
DELAY • 21

msec

·-

>

msec }
Delay for RMS l

for L 1= 1 to J do
begin
ADOR
:• K
1
{ rel.ay on l
ERROR :• TRAPl.X<DELl\.Y,OOTTl1(wait )1{ relay off}
ADDR
:= 0
ERROR := TRAPlX<DELl\.Y,DMADA)1{waitl
end
I

type
MSDATA = string[ 255 I
var
ADDR [ origin 16iDFF502
ADDS [ origin 161DFF500
I
integerJ : integer
K : integer
L : integer
N : integer
ERROR ' integer
MM : MSDATA
S_NAME : CCCC

word ;
word

REST;
MM
I
K
if

Fig.4

:= MTOBIN < MM

K

/EXTERNAL/O.OBJP.MTOBIN.TX/INITIALIZER/
L •• 161DFF400
N :• 161400
S_NAME :• ~ROUT'MESSAGE):• 1
I <> 0 thenfor N :• l to I do
:=

ADDS
ERROR
ADOS
ERROR

::• K

* 2

-;

:• K
;
( relay on },. TRAPlX<OELAY,ODTT>;{wait l:• O;( re1ay of£}·- TRAPl.X!DELAY,DMAOAl;{waitl/END/

Sample of a OBJP source is shown.
A program for driving a relay-board is shown as simple example.

S08NC09
Network and Communication

323

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

III
START

Fig.2

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC09

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
IV

Applicntions

fig. 7.

When the GPAN is used, programmers needwrite
commandrequestfunctionof(
SCREENS

Fig.6

COllllUN I CATE
I

I"-..V'
Applications

Fig.5

MESSAGEII A II N

The communication servers.
Applications which is made by the
OBJP communicate with each otherthrough communication servers.
When MAP protocol requires
connections, the applications
do not have connections. The server
only has ability of the connection.

programs. That simplifies programming.
VI

Typical application task

When the GPAN sends a message to a task,
the message brings about cascade shower of~essages among some tasks. A sample
is shown
in fig.8,
where
many
tasks
work
for
controlling a beam slow extraction of both EPlline and EP2 line. Each task has only one
function, so that it is very simple.
In this case, the one task corresponds toone device similar to an object of the object
oriented programming. Becauseonedevicereplacement
corresponds
to
one
task

llESSAGE

Applications
Panel information
Fl LES

Touch screen management is done by special task,
called 'GPAN'. The 'GPAN' reads "Control Information Files"
and rearranges buttons of the touch screen.
If the button displayed on CRT is touched,
the 'GPAN' sends a message to the target task •.typebutton = record( Button location XY
word;number
J
word;
corr~
I Butt on change style lword;
ccodep
I Color code : normal l( Color code : pushed J
word;
cc oderstrlng[27]; I Letter : normal
In fopl
In forstrlng[27]; I Letter : pushedJtaskname: string[S]; I Receive task nameJ
commmess: strlng[30]:( Message I
Itasknamr: strlng[S]; I Receive task nameIcommmesr: string[30];( Message 2
Iword~
keykeyl Keybord or 2nd pane I}
nextssf
string(S]; ( Next screen
J
end;

Fig.7

&SRV

Standard human interface

Touch screens and CRT displays are used
for the human interface of the accelerator
control. The touch screen system has been
managed by a special task called 'GPAN'.
Application programmer need not write a partof program for controlling the touch screen.
All commands for the control has been
written in files for the GPAN. When thesurface of screens is touched, the GPAN sends
a message to a task of either device control
or information display.
Schemeofthisrelation is shown in fig.6. Data structure of
the input file is standardized as shown innot

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC09

MESSAGE

Servers

The simpl7 description about the OBJP
applications is supported by communication
server tasks. They work on all computers andcommunicate witheach
other.
Simplified
diagram is shown in fig.5.
The task '&SRV' receives the request formessage send, and it passes the message totask 'C37X' which
controls
communication
board. The task 'NANN' is an agency for systemcall on remote node. Then a message from anapplication is placed in a receive task's
communication buffer. There are more servers
for network management or file manipulation.
At
OBJP
level
programming,
any
programmers do not have to know the server's
functions.
V

ICALEPCS1991, Tsukuba, JapanA control data structure forour standard touch screen.
Data size per a touch button isabout 200 bytes. The data areedited by a program for the exclusive
use of data making.

replacement, good program maintainability canbe kept.
The sample is complex case. One programis send to two computers for both EPl and EP2.
But in many case, a pair of tasks works one
job; one task controls devices or takes data
and another task displays the status on a CRT
display.
The
structuredepends
onaprogrammer's conception.
VII

Sample of remaking

As hardwares of accelerators are replaced
often, control program for a replaced hardware
must be also replaced. For example a soundinformation unit has been replaced recently,
as it is hopeful that useful messages for
operators are announced. The step of thereplacement is shown in fig.9.
In this case, there are 3 stages. First,
a relay-board on VME-bus drives talker units

S08NC09
324

Network and Communication

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

ICALEPCS1991, Tsukuba, Japan

ON/OH(DEVICE DRIVER LIKE)
RELAY

VIII

In order to make up the new system by afew persons , a simple programming method isrequired to make many programs. We have madethe OBJP for simple programming as the resultof research of multi-tasking system.
In case of making program with "small andmany" tasks, the one task corresponds to one
device, so that it is similar to an object of
the object oriented programming. But thisprogramming method is not so easy for many
programmers. They makes complex programs whichhave all functions in one task. "The all in
one type programming" seems tobehighperformance, but debugging process is very
complex. The "simple and many"
program's
debugging is simple, because the function of atask is simple. Total performance of the"simple and many style programming" becomes
higher than the "all in one type programming",
because of the simple debugging andits
portability to other jobs.

Al D

TOUCH

DISPLAYPULSESC REEH
PATTER~

1,~,

IX

Acknowledgement

The authors wish to acknowledge
thecontinual and helpful cooperation of the 12GeV
PS members. We wish to thank Dr. T.Kawakubo
for his useful programs and his suggestions
for debugging of the OBJP .

~DIA

Fig.8

Conclusion

X

References[ll

H.Nakagawa, "OBJP," KEK Report 90-20,
Feb. 1991, c in Japanese ).

[2]

T.Katoh, H.Nakagawa, K.Ishii and
E.Kadokura, "VME-COMPUTER BASED CONTROLSYSTEM FOR THE KEK PROTON SYNCHROTRON,"
Europhysics Conference on Control
Systems for Experimental Physics,
Villas-sur-Ollon, Switzerland, 1987,
and KEK Preprint 87-91.

The OBJP applications workcommunicating with many tasks. This isa sample of beam extraction control
system. Each box means a task with a
special duty. These tasks work onsome computers.

@ lST STAGE

INPUT --> RELAY DRIVE PROGRAM --> RELAY --> BUZZER ORFIXED TALK UNIT
@ 2ND STAGEI

A FEW MINUTESv

INPUT --> BIT TO TERMS TRANSLATOR --> TALK PROGRAM --> D/A@ 3RD STAGE

INPUT --> INFORMATION BY

I

SAME PROGRAMv

TABLE --> TALK PROGRAM --> D/A
INFORMATION DISPLAY --> DISPLAYLOGGING PROGRAM --> PAPEk OR FILE

Fig.9

A sample of task replacement.
A new talk information task for alarm announcements is
introduced in the control system.
Stage 1 : fixed talker units were used for sound information.
Stage 2 : a new talker has been introduced into the system.
The relay drive program has been modified for new system.
Stage 3 : a new information system< now testing l.
The program is like a core of any knowledge base system.
The new talk task can be used without modification.

S08NC09
Network and Communication

325

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

which can talk only one message of 8 seconds.
It is very simple, but not flexible.
We introduce a new alarm message system.
We have made the talker of both a D/A board
and its drive program. As the source programof OBJP is simple and many functions does notappear in the source codes,
thesimplemodification has been made.
The third stage in fig.9 is on testing
now. It is a logic table based information
system. We think that it is similar
toknowledge base system. This program calculates
input states relation and it sends a message
when the condition becomesequal
stateswritten in its table. In this case, the newtalker system can use without modification
when numbers of information are increased.

fl LE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC09

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-S08NC10

Messages Message&
Sent
Received

CPUSec

Kbytea/Elapsed Kbytea/
Sec
CPU Sec Elapsed Sec

Kbytes
Sent

Kbytes
Received

Synchronous RPUT

28

16

1,000

1,000

3.73

8.88

7.5

3.2

Asynchronous RPUT

28

0

21

0

0.54

0.57

52

49

Synchronous RGET

20

24

1000

1000

4.31

9.31

10.2

4.7

Asynchronous RGET

20

24

15

17

0.87

1.14

50.6

38.6

NOTE: All measuremente for 1000 calls

Table 1: Performance Measurements for Network Database Access
The colwnn showing the number of messages sent and received
clearly shows the effect of asynchronous calls, and the effect OD
cpu overhead can also be seen in the cpu column.
Figure 1 summarizes the results in tenns of the throughput
against the demand in requests/second. The asynchronous RPUT
perfonnance is improved by the lack of need for replies and that
accounts for the high throughput. Asynchronous RGET calls return the value and hence the approximately halved performance.

The remarkable impact of the requirement of synchronous calls
to wait for a reply is shown in Figure 1. The network overhead
associated with sending each request as a separate message .is
about six times the basic call overhead. The elapsed time is further increased over the increase in cpu time by the need to wait
for a reply OD each call.

Iv. NETWORK LOADING
If one considers the message overhead of 48 bytes in addition to

the 20 bytes in the "RGBT'' request message and the 24 bytes in
the reply, a total of 140 bytes on the netwodc is associated witheach "RGBT''. Allowing an arbitrary 50% network loading andassuming no collisions, one can achieve a total oetwodc throughput of about 4,500 "RGBT''s/second. With asynchronous"RGBT''s this netwodc throughput can be doubled as about SO"RGET" calls can be included in ooe netwodc message with the
48-byte overhead. Using the same arguments, asynchronous"RPUT''s will have the bandwidth further doubled to about
18,000 "RPUT''s/second because there is no reply message.
All the Vsystem tools use a feature in Vaccess by which any process on the netwodc can request notification of a significant
change in any field in a channel Thus, Vdraw will take a local
copy of the value and request notification of a significant change.
It is then the responsibility of the remote database to notify
Vdraw of the change when it happens. This ensures that the netwodc and computer processing bandwidth is only taken with required infomtation. With change notification, the need for polling is removed and while the netwodc throughput will be about
4,SOO changes/second (the netwodc loading of a change notification is about twice that of an asynchronous "ROBT'') thosechanges will all be significant, requested changes rather thanmostly checks on uncl18nged data.
0

1000
Demand (requests/sec)

Figure 1:

Remote Database Access Perfonnance
Between Two VAXstalion 3100
Model 30 Computers

2000

V. GRAPHICS MEASUREMENTS
For these measurements the same VAXstation 3100 model 30
computers we:re used with one containing a Vaccess database anda progaun to generate changes in that database. For the Vaccess
communications measurements, Vdraw was nm in the other
VAXstation 3100 model 30 and the network traffic measured as

S08NC10
Network and Communication

327

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, Japanthe data was displayed with different Vdraw control tools. The
tools used were a text display, a bar displaying two values, thesecond value as a small triangle, and a slider with a readback channel. For the X-window network protocol measurements thesame test was mn but with Vdraw running on the same VAXstation 3100 model 30 as the database and the other VAXstation
3100 model 30 acting as an X-server. In this case, the network
Q'affic was the X-protocol. In this case measurements were madewith the X flush rate set both fast, 0.01 seconds, and slow, 10 seconds. Different flush rates did not change the number of bytes
tr.msferred but dramatically changed the number of messages.
When the flush rate was set slow, the network messages were
full. Table 2 shows the results of these measurements andcompares the number of bytes tr.msferred.

For simple graphic objects, the X-protocol is more efficient in
network usage than the Vaccess AST protocol. One reason forthis is the amount ofdata transmitted with the AST to the requesting process in addition to the changed value. This is to minimize
the possibility that the process will have to access the remote da·tabase further in order to complete the processing of the change.
The diffenmce in network efficiency also reflects the optimization in the updating of text and slider data displays [1]. Bar updates can get considerably more complex depending on the options chosen. The large number ofbytes transferred to update theslider reflects the complexity of the slider and the fact that it displays the data in graphic and text form. Here the Vaccess mechanism is more efficient in terms of network loading.

Text Dlsolav

Vaccess
X-Protoool
Slow Flush Rate
X-Protoool
Fast Flush Rate

Bytes/
UpdateUp dales/M~!,!geUpdates/!'essage

85

16

39

48

28

103

48

1.7

10

Bytes/
UpdateUpdatu/Message
Sent

Updates/
Message

Received

168

8.2

28

Rsar1tVaccess
X-Protoool
Slow Flush Rate

81

16

26

X-Protoool
Fast Flush Rate

81

11

13

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC10

Vdraw offers the user the possibility of displaying information
with objects of arbitrary complexity and the network loading
could become a factor in designing and configuring a system.

VI. CONCLUSION
From the measurements it is quite clear that wherever possible,
asynchronous database access should be used. When data is being monitored over the network, the performance increase in using change notification will of course depend on the number ofchanges but in most systems the increase in perfonnance will bedramatic.
The measurements of the network loading of the X-protocol arequite striking in their efficiency. The setting of the X flush rate
was observed to affect the perceived perfonnance of the graphics.

Further measurements will be made to understand system performance and identify areas for optimization.

VII. REFERENCES[l] Tue Influence of Industrial Applications on a Control

System Toolbox, Clout, P. These Proceedings

Sliders
Bytes/
Update~dates/Updates/!4Jessage

Vaccess

168

8.2

28

X-Protoool
Slow Flush Rate

375

3

3.5

X-Protoool
Fast Flush Rate

375

0.2

0.5

essageSent

Table 2: Network Performance for Vaccessand X-Protocol Communications

S08NC10328

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

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-S08NC11PROBLEM of INVESTIGATION

Respectively , the c~nication network flows aredescribed by distribution functions of activity intervals
First of all the problem of network study for us , inactivity intervals , message reception ( transmission
was the problem of network. traffic research. A ) rates and lengths of messages •The structure of network software for one networks
conventional approach for the message flow description isbased on data flow representation in terms of a node is shown on Figure 3. System receive information
distribution function of time intervals between the two about messages from standard QIO requests. Standard QIO
adjacent messages • The advantage of the approach lies in request issued from user task are directed by operational
the use of the queueing techniques. However
the system to device driver. The ALISA device drivers were
utilization of the approach in real networks traffic edited to contain counters and a program was developed torepresentation seems to meet with difficulties. Thus sample information from this counters every second and toanother approach was used in message flow description for modify distribution functions. In addition a program wasconmunication networks • A pair of counters is associated developed for demonstration of all current trafficwith a network node • One of them is incriminated in the information on user terminal. The size of the program tocase of a message reception in the node whilst the second sample information is about 5 kbyte. The influence of thisis incriminated in the case of a message delivery • Both changes on network throughput are less than one percent.
receiving and transmitting parts are equipped withcounters which have to measure the· lengths of messages •RESULTS of INVESTIGATIONS
Within preset time intervals (e.g. every second) the
counters are sampled • The differences between current and
If we take into account network software andpreceding readings feature numbers of transmitted and hardware delays, the network rate between two adjacentreceived messages ( i.e. the speed) •nodes Is about 15 le.byte/sec for messages of 512 byte
length. It's enough for normal work in the regimes ofvirtual terminal or virtual disk. In this case user don't
see distinction from situation when terminals or disks are• messaae
activity interval
connected directly to computer. Below most interesting
results of investigation will be represented.

c::J -

Fl

l

2

3

i

4

5

6

1··· •

7

i
8

I

9

10

A. Virtual terminal service

Fiaur• 2.
The set of adjacent unit intervals with zero numberof transmitted ( received ) messages is considered asinactivity interval • On the contrary , the set ofadjacent unit intervals with number of transmitted (received > messages more null is called the activity
interval. Figure.2 illustrates our new definitions. Spaces
between activity intervals are the intervals ofinactivity.

RSX

We investigated about 30 users. Users did not knew
about our researches Figure 4 illustrates the histogramsof inactivity and activity intervals and transmissions
rates histogram obtained from one user. The user activity
was a development and debugging of programs (edition
process). Investigations showed that such histograms are
similar for all users who have a little experience withcomputer keyboard and editor. The average inactivity
intervals for this category of users are between 8 · 12

Executive
VDDRV
RTDRV

User
Proera:x:n.

VSDRV
XSDRV
Figure J. RSX ALISA Structur•.
VXP <=> RXP - Virtual SysteM Deuice Processes
UTP <=> TTP - Virtual T•rMinal Procni58's
USP - Network CaMMUnication• Proce..

S08NC11330

Network and Communication

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingseconds. For unskilled users this intervals are about 20 •30 seconds. Figure 5 shows the same histograms obtained
from two users. They used the same line sim..iltaneously.

of activity interval essentially doesn't changed. This
result can be easy explained from Figure 4. The proportion
between average values of inactivity and activity

inactivity intervals histoaram

0.3

T= 10.6 sec.

0.2

0.1

sec.

0.0
1
0.3
0.2
0.1

10

20

40

30

actiVity
intervals
histogram
T = 3.6 sec.

60

50

70

80

90

messages
rates
histogram
V= 16.6

0.15
0.10
0.05

sec.

0.0
1

10

20

0.00
1

30

10

20

30

40

50

Figure 4. Virtual terninal seruice (one user).
0.4

inactivity intervals histogram

0.3

T = 5.7 sec.

0.2

0.1
0.0..j.U..U.Uu.i;l;;l,,,Cl;;i;iiliililiiliillojiiaiililiiWiiiiiiilliilll.....

sec. __-'iili.....,_____________

0.41"

10·

30.

2().

actiVity
intervals
histogram
T = 3.6 sec.

0.3

0
0.1

40.

50.

60·

'70.

8().

90.

messages
rates
histogram
V= 9.3

0.15
0.10
0.05

sec.

0.0~.i.&.&..Mll.j~--~...---

1

10

20

50

mess./ sec.

0.00
1

10

20

50

40

50

Figure S. Virtual terMinal seruice (two users).
As we see the average value of inactivity time interval
reduced practically by a factor of 2 but the average valueintervals are about 3/1 • 4/1. Figure 4.1 illustrates
distribution function for lengths of messages fn the

S08NC11
Network and Communication

331

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-S08NC11

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·virtual terminal service. It' s difficult to represent
this result as a histogram. lie have investigated manycases and we can say that these digits are approximately
the same in all cases.

Lrnoths
Share{158 {288 {2fi0 (300 (350 (400
0.89 B.088 B.994 B.001 8.003 0.01 0.0 B.0
{58

{1BB

Fiour1 4.1.Distribution Function for Lengths of Messages.

0.3

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S08NC11

c. Virtual graphical station
lie investigated many cases of experimental dataprocessing on graphical station. The processing is a
visualization of two dimensional matrix (256 X 256, 64 X
64 and others), graphics drawing, search and generation ofcross sections and so on. It's interesting that theobtained results are analogous to the results for virtual
terminal investigations. In all probability to explain
this results we need take into account the characteristics

inactivity intervals histogram

0.2

T= 23.8 sec.

0.1

sec.

O.O-IJJJ.U.U;J;l~;LJJ;Ci;;Q~;CJ.JtJ..t~~~....i;...i;;1...w;i......-..,....~.a.-------.._----...,_1
10
20
30
40
50
60
'70
80
90

0.4

actiVity
intervals
histogram
T = 5.2 sec.

0.3

0.2
0.1

0.15

0.10

messages
rlilt~sbist.ogram

V= 11.5

0.05

O.O~.w.i.liiiWiil.ioli;l,,,l,,l;---........ilil.li;;.._,.

1

10

20

30

mess./sec.

0.00 """'"&.l.l.l.l.l.l.jpl.l.l.l..i.i..,,...1.1.1.i..i..i;~------1
10
20
30
40
50

Figure 7. Virtual disk service Cone user).
of men's mental processes.

B. Virtual disk service
CONCLUSIONS
Figure 7 shows the set of histograms obtained when
one user used virtual disk service for programs
development and debugging. The average time of inactivity
intervals is about twice that for virtual terminal case.
The situation for two users is similar to the situation
with virtual terminal service. Figure 6 shows thetransmission rate histogram for case of copying one disk
to another through the network. lie can't account for thisresult but we think it will be of interest for othercol leagues.

messages
r=ilteshist.ogram

0.15
0.10
0.05

mess./sec.

0.00
1

10

20

30

40

It was very useful for us to have the system forinvestigations our computer network. lie obtained working
tool for normal work. lie have acquired possibility to makeaccurate decisions and pleasure to understand it. Any time
we need to connect next computer to network we haven 1 t
problems. lie decide problem on the common sense level but
not the level of COlf1'lex theory. Of course such approachis true only for a little computer networks Ca few dozens
nodes). Our investigations have shown that for a little
networks the flows in lines are far from Puasson type. Our
approach can ~· useful for networks with insufficiently
fast lines, when the problem of overloading are vital, but
for users with fast communications lines the problem of
network investigations don't exist. Meanwhile we hope that
our results will be of interest for network experts fromacademic viewpoint and will be helpful for psychology.

Figure 6. Disk Copy through Network.

S08NC11
332

Network and Communication

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

OCCAM allows description of parallel
processes as easy as sequential processdescriptions in a usual programing language. Communicc;i.tions between parallel
processes are made through message
transfer mechanism called channels.
The transputer supports concurrent
processing very efficiently. Its latency
to switch context is less than 1 micro
seconds. And it supports message passing
mechanism by hardware. For external
communication, it has 4 serial communication links called IN MOS links. It is
optimized to execute OCCAM program.
Transputer and OCCAM are based on CF
architecture theory. Transputer executes OCCAM program very efficiently.
In addition to OCCAM language, today
other concurrent languages are available
for transputer. One of them is Par. C
language which is a parallel extension to
the C language and has advantage against
OCCAM on defining complexed data structures.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP01

Control for
MQ04-l X
Read rockdisplay

dS/SQ

.·~\'

Fig. I : Control with macro parameter, Ef(final energy of particle)y
CAMAC 1/0,
accelerator device

Needs for Computing Power
Today. a new particle accelerator isusually controlled by a computer control
system. With an appropriate network, it
offers low cost remote control from theoperator console to the accelerator devices. It also helps the operation with
its programmable computational power andmass data storage. High level languages
and high level symbolic access methods tothe accelerator's data points have been
introduced to emphasize the advantages ofcomputer control as mentioned above. It
has simplified programming of accelerator
for accelerator engineers and physicists,
and makes the role of the control system
more important than before.
But these benefits have been obtainedat the expence of slow response to theoperator's action, even in a very primitive manipulation of the devices. In
larger accelerator systems, there are moredata points and data classes and the
network hierarchy is deeper. So theresultant response has become slower.
To improve the situation, more computing
power and better data throughput withgood real time response are needed. Withlarger computing power, we can add many
functions such as flexible feed backcontrol with digital signal process-ing(DSP), linked control of many data
points with a few macroscopic parametersand so on.
One of the good examples is thelinked control of data pain ts with a few
macroscopic parameters. In the JAERI
tandem, we must tune about 50 beam
optical parameters, to transport theparticle beam to the target. Readjustment
is needed for 30 data points of them,when we change final energy of theaccelerated particle. Figure 1 shows
process diagram of the linked control withmacroscopic parameter, the final energyof particle (Ef) • A scaling rule process
accepts macroscopic parameters, the--final
energy(Ef), mass of the particle etc •• It
calculates particle energy at each opticaldevice position and adapts appropriatescaling rule I 5 I and sends the increment (or decrement) signal to each device
driver process. The drivers output low
level control signals to the actual accelerator devices. When operator turns thevaluator of the final energy, all beam
optical parameters follow it and the beam
current on target is maintained,
For comfortable real time response, thevaluator value must be sampled andprocessed 10 to 20 times per second(orS09DPP01
334

Distributed and Parallel Processing

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP01

faster). Concurrent processing withmulti-processor achieves it, distributing
processes to several processors,

CRT

Design of the Concurrent Control System
for the JAERI Tandem
Figure 2. shows the image sketch of·the new system. The control center ofthe system consists of engineering work
stations(EWS 1s) and a central processorcolony, The colony is a multi-microprocessor system, Each processing
unit(PU) in the colony is atransputer(T800 INMOS Limited) based
processor. It consists of 32bits
transputer with 64bit floating point hardware and local memory, They are linked
with each other through serial communication links.
The colony executes mosttime critical processings. It is programmed with concurrent programming
language.
The EW S's perform several functions.
One of them is CRT display for
man-machine interface. A window systemon the EWS is used for the purpose. The
second is data base. A relational database management system is used. The
third is a host processor for the central
colony.
The front end interfaces to theaccelerator devices are CAMAC modules,
They will be ones working in the current
control system ( 16 crates are working on 5
serial highways). In the new system, theserial highways will be driven by thecentral colony through serial high way
drivers, which also have transputers as
control processors.
Conclusion
The multi-processor concurrent processing is introduced in the particle
accelerator control system. With appropriate modelling methodology, the control
system is programmed naturally in themulti processor and very high speed
processing is obtained. As an example,
renewal plan of the control system for the
JAERI tandem is discussed.

EWS(SUN3)
Control console

CAMAC
crate

0

0 0

Tandem accelerator devices
Flg.2 Image sketch of the concurrent control
system for the J AERI tandem accelerator

References
1. INMOS limited: Communicating Process
architecture, Prentice Hall(l988)
2. INMOS limited: The Transputer Data
Book, (1988)
3. INMOS limited: OCCAM2 Reference
manual, Prentice Ha11(1988)
4. G. Jones and M, Goldsmith: Programming in OCCAM2, Prentice Hall
5. S. Hanashima and E. Minehara: Rev.
Sci. Instrum. 57,5(1986)

S09DPP01
Distributed and Parallel Processing

335

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

II. AIMS FOR THE NEW DATABASE SYSTEM.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP02

Palantiri [Quenya] 'Those that watch from afar', the seven
Seeing Stones brought by Elcndil and his sons from

Because we did built the current system ourselves, used it

Numerior; made by Feanor in Aman.

and maintained it for the past ten years, we had enough!.R.R. Tolkien, The Silmaril/ion, George Allen & Unwin,

experience to define the aims for the new system. As the

1977, p '346.

database system is meant for real-time, on-line processcontrol it is clear that it should be fast enough to meet

Golem n. clay figure supernaturally brought to life (inthe needs for this kind of applications. Furthermore it

Jewish legend); automaton, robot.

must be possible to use the system in a heterogeneous

The Concise Oxford dictionary, 7th ed. 1982, P 426.

environment, consisting of as well as real-time systems(fhcse new names were invented co avoid confusion with theas Unix systems.

terms used in lhe existing system.)

For the database itself we agreed that the new database
On each machine that requires access to the database runs

should:one specific process; not a server, not a daemon, but a• Not duplicate data, i.e. data is only stored in one place

palantir. This is indeed what the name suggests (to thosefamiliar with Tolkien): a crystal ball giving access to all

to avoid inconsistencies.
• Be distributed without applications being aware of theother palantiri in the system. On top of that, palantiri areable to store data that has been declared by their local

distributed nature of the database.
• Be flexible and easily extendable.

agents/clients, which we call Golems.

• Not be aware of its intended use; i.e. not have any

A Golem is a process that typically, but not necessarily

knowledge of the hardware it is intended to control.

controls some hardware. The Golem has knowledge of• Offer as services al least: read, write, lock andthis hardware, and receives the values to steer the hardware
from its local Palantir. All relevant data that must be

subscribe.

known to the outside world are sent to the Palantir by theGolem.
For the third type of process in our system we have notchosen a new name; processes that communicate with
Palantiri, but do not own variables, are called
Applications.
A Golem has a name which is made known to theapplication

Palantir, and owns a set of variables which are also madeknown Lo the Palantir. The Palantir allocates memory forthese variables and maintains their values.
Variables have a name, a type and access rights attached

golem

to them, all of these are specified by the Golem. The
variable name looks like a Unix path name. The first

Figure 1. The Palantir database concept.

element is the name of the golem, all other elements are
given by the golem. But there is a direct relation between

III.WHAT DOES THE NEW DATABASE LOOK

the variable name and the structure of the data. The

LIKE ? PALANTIRI AND GOLEMS.

S09DPP02
Distributed and Parallel Processing

337

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

variable called should in the following C-structure, that

locally are fully servk:ed before looking for a next request.

has been declared by a Golem with Lhe name Al 3

Forwarded requests are maintained in a number of queues
for future reference when the response from the remote

struct magnet
long is;long should;} QI:

Palantir arrives.
All this is quite straightforward, and Palantiri would bevery simple indeed but for exception handling. Machines
may become unreachable through network failure, or
because the machine itself is down. There is no simple

may be accessed by the palh IAJ31Qllshould. The magne1

distinction between the two. Or a process having an

structure can be read at once by accessing /Al 3/QJ.

outstanding lock may disappear, thereby creating a

Access rights arc different for the golem that owns Lhe

Palantiri have an elaborate 'are you there' mechanism,variables and for the rest of Lhe world. The access may bebolh to all other Palantiri and to their local Applications

any of read, write, lock and subscribe. Now, read andand Golems. An application or Golem that does not exist

write will be clear; lock will al leasL give some idea, but

anymore results in all its Jocks and subscriptions being

possible deadlock situation.

what does subscribe mean?

removed. Note, that a Golem's variables will remain

Any application or Golem that has an interest in thevalid, though any action performed on Lhem will result invalue of a variable (either simple, or compound), cana warning message 'Golem dead' to Lhe requester. The deadsubscribe to this variable. This means Lhat whenever Lheof a Golem is also reported to all processes having

variable is written to a report is sent Lo each subscriber

subscribed to any of the Golem's variables. When thestating the name of the variable and the new value. This

Go Iem comes alive again (this is possible) the

allows our magnet steering Golem to get a report of thesubscribers will be notified again.

new should value of its magnet without continuously

When a Golem, and its data, is no longer needed, thepolling the Palantir. Actually, iL is possible to speciry

Golem may be removed. All processes having a

Lhat reports are to be sent only when a wrile action results

subscription or lock on the Golem's data are notified ofin Lhe data being changed.

the removal of the data, and the subscription or Jock

A lock is a flag thaL can be set on a variable, again

ceases Lo exist.

simple or compound, reducing write access to thuL

When a Palantir becomes unreachable, again all

variable to the locking process. It may be used either Lo

subscribers to any variable on that Palantir are notified.

keep data unchanged over certain actions, or to keep all

Locks on that Palantir stay in effect, but obviously, anyother processes from meddling with variables you areaction to that palantir must result in an error message.

assumed to have full control over. A lock exists until it

When Lhe Palantir becomes reachable again, it is possible

is removed by Lhe locking process.

(well usually) to differentiate between network failure andmachine failure. When the unreachability was the result

IV. A BIT MORE DOWN INSIDE A PALANTIR.

of network failure, it is assumed that locks andsubscriptions are still valid. When the remote machine

A Palantir is a process that forever waits for a message tohas been down, Jocks and subscriptions are reestablishedarrive. Each message is processed in order of reception.

as soon as Lhe Golems they are concerned with come to·depending on the type of request and the name of thelife again.

variable with which the request is concerned the Palantir

Other nice problems came into existence by requiring

decides to handle Lhe request locally, or to forward the

Palantiri

request to another Palantir. Requests that can be handledenvironment Lhis is no problem, but we do have

Lo be transparent. In a homogeneous

S09DPP02
338

Distributed and Parallel Processing

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP02

computers of diffcrem types, each having its own dataapplications and then replace the 'old' database by the new

representation. Several solutions were considered, but inone.

the end data is stored in the Palanlir's local format, and issent over the network in the requesters local formal. Thishas one large disadvanLage: When a new type of machine

VI. REFERENCES.

emers our environmenl, we will have to recompile all
Palantiri after adding the appropriate conversion routines.

[1) W.P.J. Heubers and R.G.K. Hart, A Workstationbased Operator Interface to Control MEA. Proceedings of

V. CURRENT STATUS AND PLANS FOR THE

the International Conference on Accelerator and Large

FUTURE.

Experimental Physics Control Systems, Vancouver 1989.

The implementation of Palantiri on Lhe Unix systems has[2] B.J.Tummers, Palantir Functional Specifications,

been compleLed. They have been tested under various

internal NIKHEF document

condiLions and seem to be running fine. Documents areavailable with the functional specifications of the Palantir[3] B.J.Tummers, Palantir Library Functional Specifica-

itself and the Palantir access library (ref [2,3)).

tions, internal NIKHEF document

In a makeshift setup though, perfonnance tests have been
done, and even in a situation with many variables (20000)
spread over 200 Golems running on few machines (4) anda high load in subscription reports (> 100/second) thesystem kept running nicely.
As a nice side effect, it seemed possible, even simple, LO
create a C shell environment in which the entire Palantir
database can be accessed very much like the Unix filesystem tree. Hence we now have commands like pls, pcd,

pget and (slightly more difficult) pput.
The control system of the new experimental facilities will
be based on the Palantir concept.
The control system for the linear accelerator and Lhestretcher ring is based upon the 'old' database concept.
Porting this system with all applications involved to the
Palantiri database is a large projecL Because ofoperational and manpower aspects, it is impossible to do
the port in a short period of time. To be able to convert
and test existing applications, golems have been madethat map the existing control database onto the new
Palantir domain. Doing this, the two domains areconnected and it is possible to convert first all

S09DPP02
Distributed and Parallel Processing

339

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-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

A,

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP03

Assodativity and string features

The ASP consists of associative processing elements(APE) working as SIMD machines, The string can bearranged in a loop: the architecture is reconfigurable byprogrammation. Each APE is an associative memory cellwith processing capability, Synchronous and a.synchronous
communication between APEs is provided through aninter-APE communications network dynamicaUy reconfig.urable. APEs are addressed by content through a common
bus, which minimises data movement, Parallel processing
is performed on active AP Es selected at a given step of the
programme. The architecture is scalable up to hundredof thousands APEs, due to high integration (VLSI/WSI)and low power consumption (- mW/APE). The low target cost (below 5.- SFr per APE) is leading, together withthe low power and high integral.ion capability, to the possibility of massive integration, The system has maximum
application flexibility and computational efficiency. It is
fault tolerant: blocks of faulty APEs may be disactivatedwithout breaking the string . The MPPC-Array machines
will have Parallel I/O capabilities (10 Gbit/s). ASP application programmes can be written in any block-structured
language (Modula 2 is the commonly used language). An
introductory course to ASP, provided by ASPEX, is useful to reach a good level on the learning curve in parallel
algorithms.

Fig. 2 - The basic Associative String Processor

This chip, although slower than expected, is suitable formaking the first prototype hybrid HASP module . This
module is under development at ASPEX for the MPPCArrays and is to be manufa.ctured by the sul>-contractor
Polycon Inc. (USA). For second-level triggering experiments a faster device will be required. It will use a l.2µm
SOS (silicon-on-sapphire) device in order to achieve a fully
working 25ns VASP chip in the summer of 1991 (a highperformance ASP chip presently developed by ASPEX andHughes Company ). It will be the basic stone for the final hybrid ASP module for MPPC.arrays: the HASP /Pl.
This lK APE module, using 16 dice, has a bypass of 64
B. ASP chip and moduleand 256 APE blocks and 2 1/0 ports which can be conThe basic chip for the construction of the compact hy- figured as 2 x 512 APE substrings or a lK substring withbrid MPPC modules (HASP) consists of a programmable a LAC interface and an ADB (ASP data buffer) interface.
VLSI SIMD para.lie! processing device, incorporating 64 The design is targeted to a standard 184 pin paclm.ge (3"associative processing elements (APE, see fig.l and 2): x 3" with leads).
the Aspex Microsystems Limited VASP VLSI ASP chip
The operating system and programming tools are readypresently manufactured with 2µm technology at ES2 (F).
for a test using the controller (LAC prototype) under construction at Saclay.

C.
4Flavs/11t:UVlt~

C.:rryMot(!>

tlnlln•Uon

Machine o.rchitec.ture

Each MPPC-Arra.y will be composed by one LAC and
two ASP boards giving a 16 K ma.chine. In concentrating
all ASP boards in the same machine we will have the 12bit addition). The ASP board will use the hybrid modules.
Each ASP board will contain 8 modules giving a numberof 8192 APE per board. Each module will have its own
data exchange and ADB double port memory to allow afaster feed for dataIII.

APPLICATIONS: STATUS AND FIRSTRESULTS

fig. 1 - Schematic of the associative processing element.

As previously stated, seven applications are studied:three LHC oriented, one SSC oriented, two far fixed target

S09DPP03
Distributed and Parallel Processing

341

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

time for a fit between master points configuration and all
possibilities of track.codes. The number of track-codes depends on the~ binning. This number determines the muonsearch execution time. On t.he contrary, the triggering time
will not depend upon the muon multiplicity because thesearch is done in parallel over all .Po and ¢ values. For
triggering purpose ( PT ~ PT threshold ) a moment.um isdetermined for each track, by assigning to each track·code
a maximum PT value using a simple look-up table. The
preliminary results of the simulation show that the trigger
can be worked out within about 20 µs: S µs for loading, 5µs for preprocessing and 10 µs for tracking. This timing
fits the requirements imposed by the expected first level
trigger rate at LHC.

physics at CERN and one for HDTV.

A.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP03

Muon aelection at LHC (CERN)At LHC single and multi-muon triggers will play a cruda) role in particular for Higgs search through its four leptons decay, An analog first-level muon trigger is expected
to cut down the single particle rate below 106 Hz. In order
to identify the muons, a more sophisticated second-level
trigger is further required. This includes momentum determination, charge assignment. and counting all the tracks
which are above a given cutoff momentum. This task mustbe achieved in le1111 than - 20µ.s in order to cope with therate of the first-level trigger. The solution which is under study proposes to divide the triggering procedure into
three phMeS: the loading of the hit information coming
Crom the muon detector (detector mapping into the ASP),
the preprocessing of the data (determination of the best
hit positions: the "Master point determination") and thetracking (track finding, charge signature and PT determination).

B.

Taking advantage of the rotational symmetry of the

CMS detector model [8}, a (r, cf>) mapping of the fin&-grainmuon detector can efficiently be done in the ASP [9j. A
track is defined in the central plane of projection (planeof deflection perpendicular to the beam a;xis) by the ver~tex of the interaction, positioned with high precision, andby the muon trajectory detected at five radii with multilayer detectors . The mapping is done in a wa.y which
a.soodates one APE to each t:..4': this allow to identify ina single search all the high PT tracks. The granularity
Arp (typically in the mrad range) is a parameter dictatedby the size of the Coulomb-scattering. Aa long as A,P isabove its minimum physical detector pitch value, the mapping is reconfigurable according k> the chosen triggering PT
threshold.
Only the active cells are loaded into the ASP, preserving
the topology of the detector which provides the so-ca.lied"iconic mapping". Then, a "master-point" is calculated
from the multi-layer detector hits, taking into account detector inefficiency and possible multiple hits in one or morelayers. This preproeessing is done using a fast "iconic average'' using data shifting and bit-logic operations acr-OSS
the APEs. For the third step of the triggering scheme,
the tracking, 1oonic algorithms use bit representation of
the image of tracks and the image processing can be done
bit parallel in the ASP machine. The five eonsecutive values of the azimuthal angle ¢ relative to the innermost ¢0value, expressed in unit of f!:.4> is ~d for calculating a"track-code ". The track-code is a unique representationof a given charged. particle trajeek>ry through the muon detector. A preliminary study was to construct track codesfrom the Geant Monte Carlo data and k> explore the feasibility and efficiency ol triggering by the propoaed iconic
algorithm. It c:onsiats of looking for all hits at the same

TRD electron selection at LHC (CERN)

An integrated. tranaition radiation detector (TRD) andcharged. particle track.er has been proposed. for a LBC detector in order to improve the identification of electrons
beyond the level of electromagnetic calorimetry[lO). The
TRD tracker will have about 500 000 channels (straws)
put inside a cylinder installed around the beam a.xis (theHalo model). Electron candidates will be tagged by a surrounding calorimeter and the information will be used k>define planes cutting the tracker detector and defining candidate roads inside the TRD. One assumes limits on both,the number of candidates (no more than four per event)and the rate of candidate occurrence (not more frequently
than every 10 µs average). The basis of discriminating
electrons from hadrons in the TRD tracker lies in the statistical analysis of pulse heights of all digitising belonging
to a track candidate. This allows to measure the probability of TRD X-ray emission (and detection), which isstrongly enhanced. for electrons due to their very high T
values. As for the muons, the trigger procedure ca.n also
be divided into three phases, but each of them is being implemented on a. different type of hardware for optimising
the running of the dedicated algorithms.

c.

LHC calorimetry, jets and shower detedion (Oraa.y)

The use of ASP at the second-level trigger of a barrel
calorimeter model for LHC is under detailed study using
the ASP simulator. It is assumed. that the event buffering
at that level should not exceed 100 Wf on average. Special
care is put on the study of the mapping of the calorimeter cells into the ASP (patching optimisation). The basic
procedure is to aasociate one APE to each cell. The load·
ing time will be of t.he order of 10 to 15 µ11. If the Vector
Data Buffer feature (VDB: a word parallel, bit aerie.I ASP
loading under development at ASPEX) becomes available
on the chip, most of this time will be overlapped wit.h
the processing of the previous event, and the real cost ofloading will only be l µa. A fast rejection of each event
detected. inaide the calorimeter should be done in an aver-

S09DPP03
342

Distributed and Parallel Processing342

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

ICALEPCS1991, Tsukuba, Japanage time of 50 µs. Jet energy, isolated electrons, mi1111ing
energy, shower shape and position are the essential event
feature extracted from the calorimetry. Various selection
algorithms are under detailed study. They are based on
the analysis of the energy deposited in neighbouring cells,
making correlations between the information coming fromthe electromagnetic and hadronic parts of the calorimeter.
The possible use of presbower detector is also considered.
As a result, 20 to 30 µs processing time is obtained.

dating good triggers: the transverse momentum conserva.tion implies zero value for the first moment of the energy
distribution (relative to the centre of the calorimeter) and,from the Ko mass constraint, the vertex position can becalculated by using second moment. of the energy distribution and total energy of the clusters. These calculatioWI
should be invalidated if an accidental hit occurred in thecalorimeter in the sensitive time window. Processing time
was evaluated for the ASP and for digital signal processors{DSPs). ASP is better suited for the topological processing
ta11ks (find clusters and count them, find accidentals and.
locate them relative to the normal signal timing), while
DSPs are better on the fa.st, high accuracy, stream arith·
metics required in the energy balance and vertex calcula-tions. This application is an example of the use of ASPs
in prompt trigger systems, where real time respome performance, and fut parallel loading capability is of prime
importance. The result of this study shows that combining
ASP and DSP processors in the fa.st neutral NA48 trigger
system is currently sufficient to fulfil the NA48 requirements: an efficient 2r0 trigger can be performed in leas
than 10 µs.

Possible He of ASP for SSC/SDC detector {Saclay)

At SSC, the measurement of jet energies is essential forthe detection of neutrinos and others unseen particles. The
SOC (Solenoidal Detector Collaboration} detector [llj isbased on a (i,b, 17) tower segmentation where ¢J is the azimuth angle and q the pseudo-rapidity (11 = - In tan 8/2
where is the polar angle). Each tower is logically divided
into five layers providing the symbolic information which
will give the necessary event topology and e/h/µ particle
identification used for triggering:. Starting from the vertex,
the five layel'8 of detectors give the following information:
tracking (hits/track), answer for isolated electron, number of electron dusters, number of hadron jets and muonhits. ln the calorimeter, an isolated electron pixel is characterised by an electromagnetic energy value greater thanan e.m.-tbreshold, a hadronic energy value lower than abadronic-thresbold, and no direct neighbouring eell withe.m.-energy greater than an other e.m.-threshold. The basic principle of using ASP in a second-level trigger is toassociate one APE for each calorimeter cell and to load
into this APE ell the information a.bout the live layers
contained within a corresponding (4', 71) tower. Inside each
APE, the 64 bit data register is enough for storing all thisinformation. For the detection of missing energy, the calculation of the tra.asverse energy E 1 is done by summing
E,;na, calculated simultaneously in the APEs for eachcell. Preliminary results of algorithms simulation using
the VASP-Simulator give 7 µa for the detection of isolated
electrons and ,.... 20 µa average time for missing energy (dependent on clusters number and geometry).

e

E.

F.

ASP tracking with CCD on-line camera in WA99, a
jized target heavy ics phyaica erperiment ai CERN (U.
of GENEVA}

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

D.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP03

A heavy ion experiment (WA93) is scheduled at CERN
with the aim to study Bose-Einstein correlations amongcharged piona. The reconstruction of the pion momenta
with a large acceptance will be done with a tracking syst.em
consisting of a spectrometer magnet and new type of lightemitting multistep avalanche chamber11[13}. The paaeageof a charged particle through the chamber is detected as acluster of light registered by Mega.pixel CCD cameras. The
analysis implies various stages: image preproceasing (background reduction and subtraction, optical distorti0118) thenactual image processing (duster analysis) and finally tracking and momenta correlation . The use of ASP for thesetaBka looks very promising as they are well adapted for
massively parallel image processing. Bose-Einstein correlation requires computation of four-momentum dift'erence
for all pairs of tracka which means that many TFLOPS of
A Ka trigger for NA.f8, a frzed target phym:s ezpericomputing power will be required for only a. few days ofmeaf at CERN (Saclay)
running (- 10 6 events).

The N·MB::experiment is an experiment aiming to perform, in 1994-96,a high precision measurement oft.he (1 /eparameter in order to have a better understanding of CP
violation (12]. Thia parameter is determined from the mea.surement of charged (r+r-) and neutral (2ir 0 ) decays ofor Kfr, concurrently. The target is to obtain on-line avery good signature of 2ir0 candidates in less than 10 µs,
taking as inputs the energy deposits in the 12/JOO cells of
an electromagnetic calorimeter array. Ca.ndidat.es should
give exactly four photon shower clusters in the detector.
Physica coDBtra.inta f.r:om the Ka decay are uaed for vali-

K8

G.

Image sequence coding, data compadio1' for HDTV
(EPFL)At the signal processing laboratory (LTS) in EPFL, theimage sequence coding group has developed number oftechniques for image sequence compression reaching very
high compression ratios. For real time processing at video
rate of large images, a pa.rallel computation approach itnecessary. Thia is why the use of ASPs is studied using
two different methods: the parallel implemeniatiou of the

S09DPP03
Distributed and Parallel Processing

343

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
Gabor compression algorithm (14] and the pa.rallel implementation of artificial neural networks on the ASP (15}.
ln the Gabor compression algorithm, the image is decomposed in elementary Gabor functions ba.sis. The use ofsuch a decomposition is motivated by the fact that Gaborfunctions have optimal localisation in both spatial and frequency domaim. The realisation of this algorithm requires
the study of efficient parallel algorithms for matrix com puta.tion, particularly large matrix multiplication (typically
256x256). Several algorithms for matrix multiplication on
ASP are under study. At this time, two programmes for
integer computation nave been developed, one using 8 bits
and one 16 bits. The best results have been obtained withan algorithm ca.lied outer product [14.]. The initial results
obtained with the ASP simulator in function of the matrix
dimension for 8 and 16 bits integers are very encouraging
in view of video rate compression up to 200:1 ratio.

IV.

CONCLUSION

From the applications under detailed studies for highenergy physics at the future hadron colliders LHC, SSC
and for SPS fixed target experiments at CERN, preliminary results obtained from simulations, based on the useof ASP machines developed in the MPPC project, can besummarised as follows:• a second level muon trigger at LHC is feasible andcould be done within about 20 µs.
• a second level trigger far calorimetry at SSC and at

LHC would require something like 50 µs,• for the NA48 fixed target experiment, a K0 - . 21ril
trigger could be achieved in less than 10 ps.

All these results a.re encouraging and could fulfil the ambitious objectives of these applications. In another domain,for HDTV and videophone applications, preliminary re·suits for compr~ion and restoration of images show thatusing ASPs could open the possibility of working algorithms at video rates. Real time test.a for the seven ap·
plications studied at present should be possible in about ayear, when the four MPPC.array machines become avail·able.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S09DPP03

3. Proposal· The MPPC Project, MPPC / 89- 2, CERN,
28 July 1989.
4. Memorandum of Understanding for the Execution of
the MPPC Project,
CERN /EF /FR/fr, 16 Marth Hl90.

.5. MPPC -1990 Status Report, CERN/DRDC/90-76,
DRDC/M4-Rev., 18 January 1991.

G. TRAX-1 proposal, Proposal to develop a physics image processing workstation for Megabytes per event
data based an fine and medium grained parallel processors, A. Sandoval et aL, CERN, 27 April 1988.

7. CERN-LAA/89-l, 15 September 1989, section II.6,
p.267.
8. Study of muon triggers and momentum reconstruction
in a strong magnetic field for a muon detector at LHC,CERN/DRDC/90..36, DRDC/P7, 30 August, 1990.
9. Second-Level Muon trigger for the Large Hadron
Collider, G. Odor, F. Rohrbach, G. Vesztergombi,
CERN /ECP 90-20, 21 December 1990. Aachen LHC
Workshop Proceedings CERN 90-10, vol.III. p.136.

10. Integrated High-Rate Radiation Detector and Track·ing Chamber for the LHC, Proposal, B.Dolgoshein,spokesman, CERN - DRDC/90..38.

lL SDC, Letter of intent SSC/LOl-0001, 30 November
1990
12. Proposal for a precision measurement of €1 I< in
CP violation go - 21f 0 decays CERN/SPSC/90..22
SPSC/P253, 20 July 1990.

13. Proposal for a Light Universal Detector for the Studyof Correlation between Photons and Charged. Particles
CERN/SPSC 90-14 May, 1990 and CERN/SPSC 90..
32 October, 1990.
14. T. Ebrahimi. T.R. Reed, M. Kunt, Video coding using
pyramidal Gabor expansion, SPIE, Vol 1360, Visual
Communications and Image Processing 90, p. 489-501.
15. G.W. Cottrei, P. Munro, D. Zipser, Image compression by back propagation: an example of extensional programming, ICS report 8702, February 1987,
UCSD.

REFERENCES
I. ASP: A cost effective Parallel Microcomputer, R.M.

Lea, IEEE Micro, October 1988.

For more details on ASP we are available by e-mail:
ROHRBACH @ CERNVM.CERN .CH and VESZTER @CERNVM.CERN.CH.

·i. The Massively Parallel Processing CoUaboration, The
MPPC project MPPC/89-1, CERN, 30 June 1989,
Proc. of a Meeting held at EPFL La.ueanne 9 June
1989.

S09DPP03
344

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

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

clock signals for subsystem synchronisation to sophisticated timing control of the equipment control computers. However: A control system is only
complete with a timing system (Fig.1 ).

III.1.2@---@

Online Management

The operator may have a need to change either
the supercycle or the timing of an individual cycle.
The presently running cycle continues unchanged,
but the next one will have the modifications.

llORKSTATIONS

III.1.3

INTERRuPTS
TRIGGERS

Process Driven Management

Process conditions may change and need fast response (suspend immediately one type of cycle ofthe supersycle) or even very fast response (emergency, dump the presently running cycle). Evidently this is beyond the operators' abilities andmust be handled on the process level.
For fast response, a request mechanism is very
useful: Cycles are only executed upon request.
This is the appropriate level to feed in additional
conditions, as shown in Fig.2. Effective exploitation of beamtime is not the only aspect of PPM.
Security, radiation protection etc. are other ones:
A high energy beam must not be generated if itcannot reach it's destination point properly.

EQUIPMENTCONTROLCOMPUTERSTIMINGSYSTEM

Figure 1: A complete control system

III PPM-MANAGEMENT IN REALTIME
III.I

•n

Realtime Demands of PPM

TIMIP«:l

SYSTEM

The control system of Fig.1 already contains all
realtime and synchronisation mechanisms to manage the process, e.g. to execute a synchrotron
cycle. A system that can execute one cycle canas well execute another one. Nothing principially
new needs to be introduced to perform PPM.
What then could be the realtime aspect of
PPM? Let me call it the 'online supercycle management'.
There are three levels of access to supercycle
management, with increasing realtime demands:

III.1.1

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS01

OfHine Management

The supercycle is built up ofHine to fit the experimental program. The internal timing of the individual cycles is programmed at the same time.
There is no realtime demand.

Experl--.t
w_.,t.8 ~?
Security tn eera •n?
HaQnets In eer'll •n Cl<?

Vai:;u..o111 In eer-e •n Cl<,.,....t •lee Nlv• yClU In •n ..

Figure 2: Request Level
Emergency handling is too special in every accelerator environmeut to be discussed here.

III.2

An Example: PPM Managementat SIS-ESR

Fig.3 shows the control and timing system of SIS~
ESR. The timing system drives a timing networkin parallel to the communication network~ Timing interfaces receive the serial timing informationand pass it as a 16-bit parallel code, the eventcode, to the equipment control computers.
A selectable set of events is transformed to
hardware triggers for equipment by the timing interfaces. The time jitter for triggers is smaller

S10TS01
346

Timing and Synchronization346

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

ICALEPCS1991, Tsukuba, Japan

than ±.5 microseconds in the system. Nanosecond timing has been left to special solutions tokeep the timing system hardware simple.
In contrast to Fig.I the timing system in Fig.3
is not a special part in the control system. To theoperator it looks as, and in fact is, just anotherequipment control computer.

In comparison to other PPM-solutions, e.g. (3], no
special PPM-management components like PPM
message decoders are needed at the process conrol
level.
Fig.5 gives the operator's view of a simple supercycle.
NO l l NC

DCount-2
ActiveCount•t
ActiveCount-5Inactive
NR

7

R
BACKBONETIMING NETIJORKEQUIPMENTCONTROLCOMPUTERSEQUIPMENT 1/0
ANO TRIGGERS
TIF: TIMINGINTERFACES

R

15

NC

Figure 5: A SIS Supercycle
The properties assigned to each cycle are
active/inactive
execution countdecement/nondecrement
contiguous/ noncontiguous

all of which can be changed online by the operator. Active/inactive provides a simple means tosuspend a cycle. An inactive cycle does not leave
The SIS-ESR timing system has direct timing a gap in the supercycle. It continues with the next
control over all equipment control computers [2]. active cycle.
The execution count works together with
Each equipment control computer has available
complete settings to execute sixteen different cy- (non)decrement and (non)contiguous.
In non-decrement' condition, (non)contiguouscles, the 'virtual machines'.
ismeaningless. The subsequent supercycles are
The timing system activates machines by providing the event-code (Fig.4). The equipment identical containing as many individual cycles incontrollers do nothing unless they receive events, sequence as set by the count number.
With decrement and non-contiguous, the cycle
command events, if nothing else, when no cycleis active and the timing system is idle. In fact, will show up once in as many supercycles as set
the timing system of the SIS-ESR is a hardware by the count, and suspended in the following sudispatcher to compensate for the loss of realtime percycles.
With decrement and contiguous, the cycle is exabilities on higher control levels: It is the tilnecuted
as many times as set by the count in only
ing system that makes a 'real machine' out of a'virtual machine'. This given, it is the natural one supercycle.
One type of cycle may show up at different
candidate to be the 'supercycle manager'.
places in the supercycle, giving a high flexibility.
for supercycle programming .
TIMllfJ
EVENT BUS
TIMING
Fig.6 gives an overview of the supercycles reINTERFACE
16 bit • IRO/ EOUll'HENT
NETVORI<EQUIPMENT
sultingfrom different settings provided the status
CONTRCL,COMPUTER'
J/O
from the request level is 'true'. If 'false', the cycle
MASTER
V SYSTEM g, "'CCH4UN.
CPU'\.. DATA BUS /inquestion either will not be executed as in 'nonNETllOl=IK,'
active' state, or an appropriate gap is inserted into
Figure 4: Event-Driven Equipment Control Com- the supercycle, if it is essential to maintain theputeroverall timing structure. The choice is ma.de by a
Figure 3: The SIS-ESR Control Architecture"'

S10TS01
Timing and Synchronization

347

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 DOICD

IJORKSTATIONS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS01

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 Publishingsoftware switch in the timing system.
R/NR is no input channel for the operator. It
indicates the request status.

After four years of operation, we found no demand for timing that could not easily be granted.

doi:10.18429/JACoW-ICALEPCS1991-S10TS01

V DEFINITIONND I NC

ND

Count•2
ActiveCount•!
Active

R

R

2

NC

ND

3

NC

A 'virtual machine' in this context means a complete and consistent set of data stored in the
Equipment Control Computers to perform an accelerator cycle if activated by the timing system.

Count•!
lnect Ive
R

VI
D

I

NC

ND

2

NC

Count•2
ActiveCount· I
ActiveR

R

Count·2
ActiveND
NC
2Count· I
Active

R

R

D I

C

ND

3

NC

ACKNOWLEDGEMENTS[1] The PS Staff, reported by J .P.Potier,Count•!
ActivePulse-to-pulse modulation of the CERN PS
complex, Particle Accelerator Conference,
Chicago, 1977

R

[2] W.Rosch, R.Steiner, SIS-Timing, GSI Scientific Report 88
ND

3

NC

[3]

Count•!
ActiveR

Bolliot J. et al., IEEE Trans.Nucl.Sci. NS-28(1981) 2195

Figure 6: Supercycle settings
The properties given to the cycles, together withthe request mechanism, easily allow a preprogrammed dynamic behavior of the supercycle.
This is extremely useful when conditions change
inpredictibly, e.g. when the storage ring ESR requests a bunch of cycles every few hours.

IV

SUMMARY

The benefits of online PPM-management havebeen described. As an example the PPM-controlof the SIS-ESR has been shown. the PPMmanagement in the SIS-ESR control is very simple
and straightforward due to two facts: The central role that has been given to the timing system
within the controls, and the proper design of thissystem. With direct control of the equipment controllers' timing it is the beating heart in SIS-ESR
controls, rather than anything else.

S10TS01
348

Timing and Synchronization348

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
is equal to the time seperation between two adjacent rf buckets. When.a arbitrary standard revolution clock is defined, eachbucket can be uniquely identified by the time displacement ofinteger multiple of a tic from the standard revolution clock andcan be named as bucket #0,#1, ... #467. Actually the standard
revolution clock is made dividing the rf frequency by the SR
harmonics and then the physical bucket #0 is identified as thebucket which synchronized with standard revolution clock in theinjection point. The physical bucket #0 is also defined as thebucket filling firstly for the ring operating cycle. To fill the next
bucket, for example, as bucket #n the phase of standard revolution clock is shifted a degree of n times of a tic and then the
gun trigger is fired at time when synchronizes with this delayed
standard revolution clock. On the other hand, A pretrigger isprovides 102.8 usec prior to gun grid trigger to properly charge
the modulators. Basically, a trigger signal generated on the firstedge of revolution frequency falling with a gate drived from the
120 Hz zero-crossing in the repetition rate generator produces
a fiducial which is superimposed on the 1.07 MHz singal in thesynchronizer is then transmitted on the timing local station andSR kicker station.
In the Lina.c, a pretrigger is delayed according to the timing
requirement of each pulsed devices. Their events are as follow :1. Gun Trigger ; This signal is used as the reference for allof the other events. The occurence of this signal is determinedby the entire timing system and is synchronized to the SR rf.
2. Early Modulator Tirgger ; The high-power modulators
must begin charging before any other events.
3. Thyratron Trigger ; This event enable the klystrons. Afterthe modulator rise time, rf begin filling the accelerating waveguides and the pulse compressor cavities.
4. Booster Modulator Trigger ; This event enable the booster
modulation amplifier.
5. PSK trigger ; The klystrons used the pulsed compressor
need a phase reversal gate. This starts at 0.86 usec prior to thegun trigger signal.

ICALEPCS1991, Tsukuba, Japan

Timing System Description
The PLS timing system consists of a master oscillator, abucket selector, two rf drive stations, a kicker drive station andother miscellaneuous modules. A block diagram of the systemdescription of PLS timing is shown in Fig. 3. The 500.082 MHz
rf reference signal is provided to each component via a temperature stabilized line from the main oscillator located in the rf
room.
In the bucket selector, the synchronizer generates the pretrigger and a gun trigger, which are synchronized with the SR
rf. A gun trigger singal is transmitted to the gun grid pulser
without extra delay, in order to reduce the jitter of beam withrespect to the ring rf. The pretrigger is split and delayed individually by three kinds of delay circuits to adjust the timing ofeach modulator.
The repetition rate generator decides an operating cycle tothe pulsed devices. Although the pulse repetition rate is limitedby the hardware constraint of the power supply of kicker magnet,
the repetition rate is variable up to 120 Hz.
Bucket Selector
The function of bucket selector is to make the Linac triggers synchronize with ring rf and to facilitate the selection ofan arbitrary bucket. The bucket selector is composed of a ring
revolution frequency generator, a synchronizer and a fine delay
module.
Fig.4 shows the schematic layout of the bucket selector. Firstly,
the standard revolution clock is obtained as divding the ring rf
frequency by the ring harmonics. The next, the standard revolution clock is delayed and then the fine delay module is used asa revolution frequency phase shifter. Threrfore we can select anarbitrary bucket by the setting of a preset value corresponding
to time displacment of a target bucket. The synchronizer generates two kinds of synchronized triggers : the injection trigger

To : QunTdgs;cr, ThisSign.alis\Ueldu:tMtcf'amufOf•llLintctimins.
Tho ooct.m:tJCO ol. TO LI S)'rU:hn:nized to the Ring rf
Tt : Phuo ltevtiMTiigcr. Thoco Kl)'IUQnl lhat utilized ED cavilioa requirod•J'll-l<VOl>l&•!C. (TI> ·0.83••)
T> : lnj«tian Kidcr Triucr

I;":::;

a.....

~·1

G

T> : - . . . Modula10rTnuor.
T• ; High.PbwcrModWatorTDgcr.
TJ : Ptcuiaucrr--------1-------I

11,----.11-----11-~-....1...~~-----.--__,,&.-;,1---+----.--il---;W.idD.llED

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS02:r,:- - j_ - - - ---1- 1·'------ - - - - - - -t - - - - - - L -i - - - - - -1- ,-----

Bol:m Bmrf.y~:'l"'I----*--------<:

1

I

I

I

-----1-J_
RPt>or... ED-- f l - _1 __

- - -

I

----------------ff-,-/!--~

Fig.2 Timing Sequence (II)S10TS02350

Timing and Synchronization350

Maslet Osdlator

RI

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS02

Bucl<el Selecting
ModuleRF 500.0112MHz

Rev. Freq. Generator
Fine Delay Module

Synchronizer

1n· cllon

Gun Grid
Pulser Trigger

i<-Mod 10
K-Mod9&PSI<

Fig. 3 Schematic Diagram of the PLS Timing System
and gun grid trigger. The jitter of the gun grid trigger output of
the synchronizer is less than 100 psec with respect to the SR rf.
RF Drive Station
The rf drive station is designed to adjust individually thetrigger timing of each Klystron modulator and a booster modulaor, and to select the trigger mode of each Klystron modulator.
At each station it provides 6 mode-selected Klystron modulator
trigger signals delayed individually. Each unit of the local station consists of a trigger mode selector, six 10 us/step variabledelay modules and a clock generator. The input trigger generates two type of signal : an acceleration mode trigger and astandby mode trigger. Both are fed to the variable delay module
for the one of them selected by the mode selector is fed to each
Klystron variable delay module.

a.x
500.0!llMlh

StorageRing
Clock(/468)

a.x

Control of Timing System
For the high flexibility a.nd reliability of the timing control,
VMEbus based computer a.re introduced and all the timing modules are installed in VME crates. Overall control sytem for the
PLS timing is composed of a master and 3 distributed slave
system. The master VME system consist of a motorola 32-bit
microprocessor, loca.l memories, a Ethernet controller, some I/O
controller. The real-time opeating system such as OS-9 is installed and all of the timing data is set and recorded.

Stonge Ring Cock (l .068MHz)

References
Delayed SR'------=--"'"'"I Clock--------r---+-tmagnet field must be stable when the bunch arrives, the magnet
should nominally be triggered at 2 usec prior to the arrival ofbunch at injection point. The kicker drive station is composed ofa fixed and some variable delay modules and supplies the pulsed
magnets with the delayed trigger pulses according to delay timeof each pulsed manget. The lengths and heights of a delayed
pulse should be adjusted to drive the pulse magnet.

("tic.'x n delay)Dela)"d SR Ooc:k(1.068Mlh)

sync1uano... Trigget.._---~--T'., Sampling - - - - -=-==-"""'-=------------,1'"""1Ga~

1. T. Urano, K. Nakahara, Nucl. Instr. a.nd Meth.
A247(1986)226.
2. G.R.Aiello, A. Carnie], Sincrotron Trieste ST/M-89/11

Fig. 4 Schematic Diagram of the Bucket Selector

Kicker Drive Station
To inject the bunch into the SR, the inj:ction kick~r magnet must be energized to provide the appropnate ma~net1c ~eld.
The power supply of PLS injection kicker magnet 1s spec~fiedto provide a ha.If sine wave with a base width of 4 usec. Smee

S10TS02
Timing and Synchronization

351

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-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 Synchronization352

3. KF common synchronization system

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS03

injected from LA bunches in BR separatrix alongphases and momentums. Before

The system isdesigned

for

pulse

ration and pulse distribution for

LA,

gene-

ning controlling generator

injection

begin-

outputsignals

13

BR,

SR

are directed by modulator-manipulator 15 toand SS work synchronization with locking toLA

HF

amplifiers

17

inputs.

AS

injection

Aftercycle, to BR and SR injection magnetic

fields,synchro-pulse is switched off and further up toas well as toinitialbeam injection time in SR work ofBRaccelerating

frequency and phase. ACS

field

couDlings

sible to fulfill corrections

at

under

is

ful-

programmed

BR

fre-

make

pos-

filled in standard way

complexwork

quency control, which is concerned withmagne-

timely. General number of timer pulses is eaual

tic field and with frequency correction on base1162 - for BR, 3140

of data about beam radius and phasefor SR, 1058

for SS.

liisz.4l

I

I

I

is

SR and SS frequency control principles areII(thereuse beam feedback).
near to that has been described for BR.

I

Common each cascade CBR, SR, SS)

feedback

I
I
I

I
I

oosition (blocks 1 and 2) and partial

I
I
I

I
I
I

loops with using data of

beam

phase

(blocks 10 and

used

for

I

looD with using information about

11)

are

beam

radialfeedback
position

slow

syn-

chrotrons oscillations suppressing.

I

J

.LL

J
5. Accelerating Stations CAS)
Automatic Adjusting Systems CAA'S)fu.
BR :l'eeiruenc!I contwt system
I. Beom io.d.Lo.e positi.on pLck-up. 2. t1i conecfom slgno..e
geneio.toi. J. Cascade-to· cascade Geam dtive &gstem.
+. 8-timei. S. Piimo..~11 sto.ndaed eeectloma9net.
6. IndJ.at :fmp1ency o.nd phase :fotmei. 7. !nLtio.f :lte9.uency
phase sh<Jtet. 8• ..Acc11feto.tLn9 iesono.toi. 9. Acceeeiating
votto.ge detectoi. (0. Beom V.tensLty p<cf.-up. If. Phasesy•!:em p•ocessing device. /2. ti 9>- conection siraf gt!l'letatoz.

FLg 2.

Salient features of AS AAS and ACS concern
with highofacceleratingprocess,

4-5 times above resonator loss power), very highf3.1JehnLn9 gem:io.toi. 14. Ft~uency p2092o.mmel. 15.1/mpfdud.e
mori.ulat£on p209<ammei. f6. llmpl!iwde modufatoz-maoi.pufatci.
17.Resonatoi JI/: suppf!I system.
fu. -Signal wi.lh l.R o.ccdera.ti.n3 vofta_se :fw;uenc!f,
B,A • st9nals, that a:e p2opozttono.C to magnette :l<efri. valueand. i£s de•ivatM~, lls·accefe~a.t1.n9 station, TJ -staet pu&e,
KM. l:.<ci<. ma911ets,-Sta.?.t f"esc UL

RF power levels, which are required for KF cascades work[2].

So, for KF work

supporting

it

needs

supplv SR accelerating resonators with

T.••

4.

velocitylarge beam loading (the beam taken off power isto16.5 MWof summary average power (64 AS with 400 kW

ofKF Accelerating Stations CAS)

maximum power per unit). At the same

AAS

frequency control system

must have increased speed of response and largetimeadjusting r·ange.
The system structure for BR

is

shown

at

Common (for SR, BR and SS) AS structure isconsist~Fig.2. Frequency control complex supplies gene-presented at Fig.3. It

ration of signals

combination with programmed devices. Theysup-port beamsyn-ampl itude

withadjustinginfrequency,

phase

and

accordance

to

given

and

RF

of some AAS

accelerating

voltagelows. The signals are used as input AS signals.

chronism and maintainLAbility. For this reason AS resonator RF voltage
is adjusted by AAS of amplitude (AAA) and phasewithfrequency, because of ''zero"-frequencv

at

in-

jection time must

LA

beam

be

determinedbunch following frequency. Blockby
6transforms

198.2 MHz signal to 30.03 MHz signal. The

lastis US•d both for synchronization

gene-

of

13

rators in each ~f 24 BR AS, and for control
chopper, which cuts out of LA beam

each

of

sixth

bunch. It makes possible to optimize putting of

longitudinalCAAP), as well as natural

beam

in

BR frequency control system

concerns

resonatorsta-frequency

is adjusted by AFA with
fast acting varactor
1
tuner. To maintain stableinteractionof all1)

It is discussed now opportunities

varactor tuner for highintensitytouseaccelerated

beam instability suppressing.

S10TS03
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

353

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, Japanthe systems in condition of large beamloading

are connected in local

a large amount of RF

tocascade.

generator andfeedback

resonator.

apDliedForloading compensation during

tranaientbunched

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS03

of

each

way,

LA ACS is built in another way then

other

op-

KF cascade ACS, because of it has been designed

RF

ring

network

beam

beam

in-

jection and because of empty separatrisses (forkick magnets switching) it is suggested tobroadband adjusting

loop

with

beam

use

envelope

feedback and one turn delay.

Fl~ 4. Ko.on :fc:u:Lttt~

6.

KF RTS Automatic Contl'ol

System ( AC:S.")

It is suggested to build ACS in suchthat each

KF

of

will

cascadehave

an

ACS shuctuu

7. Linear Accelerator ACS

portunity to work both in autonomy, and in com-at well

plex. ACS divided on sectors (clusters) by ter-already during setting up work on

ritorial (for distributed RTS>
(for localized

contain

RTS)

separatecomputers or-andattributes.

highClusterprod•Jctivi ty

compute\'processor

bus-module system crates. Number

with ACS information andis evaluated as -functional
micro-

stations
of

ACS

of

connected

final-contr-ol

30000. KF

canpointsstructureisshown at Fig.4.
The upper

access toearliertimelity LA. The

systemishierarchicallevelsradialsystemlevel
andfurnishes:complexuser

equipment,

centralfailuresituations

thewhole,

pi'ediction;

management for complex on tt1e

faci-

to

have

network

controlconsole~ontrol

CCC servicing,libraryBybecomandtheirdividecomDuterkeeping2(Fig.5.)
hardware,(CCC).

function keys the computers mayoncomplex),andstoring,

program debugging and network front-ending (formutual communication between

on

using

coupling and synchronization box equipment

comDuters). The

complexismeson[3). The first (upper) level represents 5

fulfilling of difficult calculations, that con-ting ofitdesigned

nect with process modeling, wor-k regime

reset-

now

puters of CM-1420 type with standard

central (the mainprocessors

andsecondseparate(cluster's)

LA

ACS

level

is

refusalanddivided by territorial attribute on 5

sectors,

data

base

which cover LA injector Csectorl),initialwhole;

overlap-

LApart (sector:<:> and LA main part (sectors

3-5),

based

ping of current tasks solving

with

soft-

and

Each sector control computer complex

ishard-ware

level

will

be

on CM-1420 computer type also. These

complexes

created on base of 2 super-mini computers,

for
to

are

eqt1ipment

development.

The

example VAX. These computers areconnected

ring network as well, as computers for KF

cas-cade control maintaining. Cluster computers
BR, SR, SS ar·e based on

microcomputers,connected

withtechnologicalthrough Object Coupling
rule, each Df

OCD

Devices

operatesbyof· part of LA technological system

wtiichone resonator· withRF

amplifier(OCD).

Asacorrespondin9(forexample,channeland

S10TS03354

Timing and Synchronization

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS03

AAA, APA, AFA).

LR !etto"t.
teveC SICS

FL13 5. Ltnccn .Accefe?.a.ta-i. AC 5 st?.uctu-i.e
oc11- oGJect coupei.n9 devtce

It should be noticed, that
LA work control tasks -somesuch, asequipment turn-on/-off andautomated

technologicalbringing

to

given

work conditions,synchronizing processes
setting procedures,are fulfilled by

and
ACS

equipment on real time scale.
8. Conclusion

In conclusion it should benoticed.
the

that
main

RTS devices and defined ACS structure andcom-

ponents. In

full

up to now there have been worked out
MRTI

there

are

developing

scale brass board models of AS for BR

and

SR,

including ACS and AAS equipment.
Introduction in AS components of new fastacting varactor tuner, which is able to control
high reactive power flows,

gives

to use the tuner not onlyfor

presumptions

resonator

tuning, but and for high intensity beam

auto
insta-

bility depressing.

9.

1. roRy6eB
KOMrrReKc
noH.~ .•

KaoHHO~yc~opwreRRM

Ref'erences

EcMH C.K. M np.
ta6pM~M.

Yc~opwreRbHb111

Bceco~BHoe

CoBe~aHHe

GapR~eHHbl>:

1988 r., MOCKBa.
2. ~BaHoB ~.c., KoHoBaRoB B.A., MypMH B.Il. M np
Dco6eHHOCTM
paGpa60T1~M
KaoHH011

ta6pM~M~51111

AH CCCP, TaM :ce.
TOM

2,

OcHOBHble

B.Il.MypMHa),M.'

ATOMMGnaT, 1978, c.272-286.

S10TS03
Timing and Synchronization

355

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-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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingreference line must be reduced to less than "' lpsec (rms). We
maybe also introduce two kinds of structures with a little different
accelerating frequency as the tool for the compensation of energy
gain variation due to beam loading[7].
4. Since beam instrumentation and control on a bunch-tobunch basis or on a pulse-to-pulse (train-to-train) basis are essentially required, we must make precise beam timing signals at any
local place over 12.5km from the main control room.
II. RESULTS OF THE RESEARCH AND DEVELOPMENT
FOR THE RF REFERENCE LINES~v bunches

10

2 x 1O electrons

I

A. The Optical Fiber Cable
The thermal coefficient for transmission delay is negligible
around 20°C. This optical fiber has the following characteristics:(1) Stable transmission delay time (less than 0.04ppm/°C),(2) Low loss (0.35dB/km),

l-

"
"

(3) Immunity to electro-magnetic interference,(4) High resistance against radiation.

1.4 nsFig.2 Beam Structure of the JLC

fiber cables. The new optical fiber cable will be installed on acable rack in the tunnel, in which many klystrons and modulators
will be set, In the slow timing system, a dedicated microprocessor for the generation of slow timing signals will be introduced in
the computer network system for the JLC control[5]. The slow
timing si~nals will be also transmitted through other fiber in thecable which contains many fibers in it. This communication line
is necessary for changing the operation mode and for monitoringsynchronized with the bea.m pulse on a pulse-to-pulse basis.
The fa.st timing system supplies timing signals(fast timing)for devices whose operation is synchronized with bunched beams .
These signals are also used in various beam monitors and beam
feedback systems. The slow timing system generates trigger signals(slow timing) in order to achieve synchronization between the
beam and the computer processing. These triggers are also used
for the automatic operation of machines. The slow timing systemmanages the operation mode of machines with both flexibility andextensibility. The synchronization signals are transmitted throughoptical fiber cables over 12.5km from the main control room.
In this paper we describe results and status of the researcha.nd development for the RF reference lines. Also, the conceptual
design of the fast timing system is described since the outline of
the slow timing system was shown in other paper[5,6].

Even in the whole expected operation range -20 to +30°C, thetransmission delay change is only within lOps/km. These values
are far better than any other existing cables. Fig.3 shows the measured transmission delay time change against temperature for thefiber cable. For the comparison, typical data for the conventional
fiber is also shown in Fig.3[8).

100'.i.....
.,u
~
.,
Ul

.~

...

...,»

.....

"'" 50
....0
Ul
...."
a

"a
.....

- - o - - No.l·No.2-No.3
fiber loop....... ,.. ••••••• No.4-No'.5-No.'6
fiber loop

.,

ii
....0
~

a
"'
0

·20

B. Requirements

-10

10
20
Temperature [°C]

30

40

50

The beam control and instrumentation of the JLC requiresvery high precise RF reference lines and timing system. Following
requirements are mainly thought to be necessary.

. Fig.3 Temperature dependence of the transmission delaytime

1. The jitter requirements for the gun trigger is determinedby the stability of number of particles per bunch (± 0.5%) andthe energy acceptance of the electron damping ring(± 0.7%). We
must reduce the beam timing jitter to less than "'5psec (rms) withthe enough accuracy of electron gun trigger.

This fiber cable was installed from the gun room of LINAC tothe main control room of the TRISTAN AR in April 1989. The
cable has 800m length and contains 6 fibers in it. 300 meter of
the total cable was laid even in the underground Positron BeamTransfer Line where the cable was subjected to the irradiation.
Since the core material of this fiber is pure silica, this fiber cable
is much resistant to irradiation than conventional fiber cables. The
characteristics has not been degraded during the last two yea.rs.

2. The phase stability of the RF system for the rings must
be reduced to less than ± 0.1 degree (rms) because this value
determines collision point in the interaction region.
3. The energy spread of the beam in the main linac must be
decreased to less than± 0.1 % (rms) because the energy acceptancein final focus system is small. Then, the signal accuracy of X-band

The confirmed high stability suggests that the use of this cablesystem will effectively simplify and improve the "main drive lines"
in the acceleration systems, where large diameter coaxial cables areused in the special conduit with sophisticated temperature control.

S10TS04
Timing and Synchronization

357

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-S10TS04

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

B. Test Results

Fig.7 shows the drift of the 11.424GHz signal with fiberoptic
devices from Orte! Corporation and without them. The temperature in the experimental room changed in the range of 23.1 to

For the further characterization of the system, the two experiments were conducted. Two other fibers in the cable wereconnected together at the gun room so that they made a l 600m
link with both input and output ends locating at the c~ntr?I room.
Using this 1600m link with measuring .setup shown Ill Fig.4_ andFig.5, jitter of the 508MHz signal and drift of the ll.424GHz signal
were evaluated.
·

I5

Ltnoc Gun
Room

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS04

psec

C: 0Pt!colconnector

Slgnol Generoto
508.6 MHZ

PC 9801RX

ltn Floppy
Disk

Fig.4 The Circuit for the Measurement of the Timing
Accuracy
HP NelWOrk Analer 8510

in.co

OO.P\ltln! t5Etl

n11.oouo.oo•I 0 '

Fig.6 Jitter Fluctuation over 24 Hours

11.424GHz
5-12GHz 34dB Amp.

0
leRecorderOsc.

With O/E and E/O Converter
Without O/E and E/O Converter -·.T.;. --•-

Fig.7 Phase Drift of the 11.424GHz Signal. Horizontal
scale; !hour/div., Vertical scale; 2 degrees/div., 2 degrees
correspond to about 0.5psec.

HP Network Analyzer 8510
11.424GHz

25.5°C due to air conditioner. 4 degrees correspond to the phasedrift of l.Opsec for ll.424GHz RF signal. Since the double balanced mixer of RHG can respond until lGHz, we observed thatthe phase jitter within the bandwidth of !GHz was almost small.
The complete measurement of the phase jitter is in progress.

5·12GHz 34dB Amp.

026.6mW

RecorderIII. CONCEPTUAL DESIGN OF THE FAST TIMING SYSTEM

Attenualor

Many devices for linear collider research and development require precise timing signals. The fast timing system provides timing signals for the pulsed operation of the gun, bunchers, klystron
11.70.tk
modulators and other equipment. Depending upon the operationmode, several parameters in the timing system must be controlled.
A line synchronization generator in the fast timing system is designed to provide triggers(l50Hz) at a fixed phase of the threephase AC line frequency to reduce power line AC effects in accelFlg.5 The Circuit for the Measurement of the Phase Accuracy
erator operation. The timing accuracy of this generator is better
than ,.,,lOnsec(rms). The 150Hz zero crossing signals a.re synchro·
Phase jitter was measured by a Tektronix 11802 Oscilloscope, nized with the 714MHz by a beam timing delay module.
and recorded every 40 seconds for 24 hours to evaluate the longAt first, the synchronizer generates a pre-trigger pulse for theterm drift. The long-term drift over the 1600m link transmission
was almost negligiblly small(Fig.6). Detail report of this jitter S-band linac, the damping ring and the X-band linac. Then themain delay trigger module generates the source of the gun trigmeasurement was given in other paper[S].
ger pulse by delaying the pre-trigger. Fig.8 shows the conceptual
Osc.

43dB

L

•

•

<>

•

S10TS04
358

Timing and Synchronization

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS04

V.ACKNOWLEDGEMENTS
The authors would like to thank Professors Y.Kimura, Shigeru
Takeda and Seishi Takeda for their support during the work. They
also wish to thank Dr. S.Tanaka and Mr. Y.Murakami of SUMITOMO Electric Industries for the collaboration in the construction
and the test of the optical fiber transmission system.
VI. REFERENCES[l] Y.Kimura, Proc. of the 2nd European Particle Accelerator
Conference, Nice, France, June 12-16, 1990, pp.23.
[2] K.Takata, Proc. of 1990 Linear Accelerator Conference, Albuquerque, New Mexico, Sep. 10-14, 1990, pp.13.

ower mp.
owerSplltter[3] S.Takeda, Particle Accelerators, Vol.30 (1990) pp.143.
[4] J.Urakawa, Particle Accelerators, Vol.29 (1990) pp.251.
[5] J.Urakawa et al., Nucl. Instr. and Meth. A293 (1990) pp.206.
(6] J.Urakawa et al., Nucl. Instr. and Meth. A293 (1990) pp.23.

hue Detector(7] T.Higo, Private Communication
Synchronizer

E/O Convener

Beam Timing

ero ron ng
Signal Gene111tor
Una s nch. Gen.

[8] S.Tanaka et al., KEK Report 90-5 (1990)[9] Proceedings of the Second Workshop on Japan Linear Collider( JLC), KEK, 1990, KEK Proceedings 91-10(1991)

Flg.8 Conceptual Design of the Timing System for JLC

design for timing system which is intended to develop as RF refference lines and beam timing transmission lines for the JLC.
IV. STATUS OF THE RESEARCH AND DEVELOPMENT
The KEK Accelerator Test Facility(KEK-ATF) for the JLC isin construction. The ATF consists of the following major accelerator components; l.54GeV S-band injector, damping ring, bunch
compressor, final focus test facility, 0.5GeV X-band linac and atest station for positron production[9]. Since the S-band injector
linac will be completed until March of 1993, following low level
modules are being developed for the timing signal transmission
system by using GaAs integrated circuits from Nippon Electric
Corporation(NEC).
1. µPG506B;ll.424GHz 1/8 dynamic prescaler
2. µPG501B;2.856GHz 1/4 dynamic prescaler
3. µPG502B;2.856GHz 1/2 dynamic prescaler
4. µPB587G;0.05GHz-1GHz 1/2, 1/4, 1/8 prescaler
5. Low level power amplifiers
6. Phase shifter
7. Fast phase switch, etc.
In order to investigate the characteristic of materials for RF
circuit board, we are designing above frequency divider circuits on
three kinds of board. We will decide the material until April of1992 and complete the timing system for the S-band injector until
end of 1992.
We have transmitted ll.424GHz reference signal over 1.6km
and obtained enough phase stability. The measurement of the jitter was only shown in the case of 508.6MHz transmission. We areplanning to measure the jitter in the case of ll.424GHz transmission. The developments for low level control circuits, especially
RF frequency dividers, are in progress.

S10TS04
Timing and Synchronization

359

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-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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingspecially treated by the TG8 hardware, and in addition to its
synchronization usage, it may also be used to clock any ofthe eight TG8 counters. Like any other event, the lkHz
events can be used to trigger TG8 actions.

events can occur per millisecond, as the eighth division isused by the millisecond clock.

V. SIGNAL STANDARDS

C. Date and Time ofDay Events
The MTGs receive the Central European Time information each second via a 77.5kHz radio signal originating froma 50 kW transmitter located at Mainflingen, Germany. They
receive this information in the form of an ASCII string andsubsequently convert the data into eight bytes containing the
BCD values for second, minute, hour, day, month and year.
The MTG broadcasts these events precisely over the network
each second. They have lower priority than the other eventsso that if a clash occurs then for example, the year or month
events will be transmitted during the next millisecond timeslot.

In addition, a time event is generated containing thesecond, minute and hour information and also a date event
comprising of the day, month and year. These two events canbe used to trigger actions at specific calendar or date times.
D. Telegrams
The telegram message is composed of a set of numberedparameters which describe the particle beam, currently being
produced by a group of machines. For historic reasons, theseparameters are referred to as groups, a term arising from theway the telegram used to be distributed as a serial bit stream.
Each parameter is described by two quantities, namely; thegroup number, and the corresponding group value. The
group number determines which parameter is selected, andthe group value specifies a signed sixteen bit value belonging
to the selected parameter [4]. Telegrams are associated with amachine, or group of machines, in the same way that standard events are. The telegram message however, do not trigger an action, rather they are used to condition whether or
not an action starts executing in the first place.

IV. TIMING FRAMESThe network distributes information as a sequence offour byte frames; up to eight of these timing frames can occur each millisecond. The present SPSILEP timing systemgenerates four frames per millisecond which has so far
proved to be adequate. A timing frame bas an identifying
header byte, which classifies what kind of information it is(telegram, event, time of day etc.} followed by three bytes
which further specify the frame within the header class. The
timing frames are transmitted during the one millisecond timeslots and are validated at the end of this time. Thus the resolution of a frame, and hence any timing event on the network
is one millisecond.
The timing slot boundaries are in fact marked by thelkHz clock frames, leaving seven time divisions in which
other frames can be sent. Thus no more than seven timing

The original machine timing signal standard used at
CERN was developed over 30 years ago. This •blocking
oscillator• circuit generates a transformer isolated pulse with
an amplitude of 24 volts and a duration of 1.5us. It was designed specifically to transmit timing pulses over 50 Ohm
co-axial cables in hostile and noisy environments. It is still in
use throughout the PS and also in the original SPS control
system.
However, for the SPS upgrade and also for LEP, it was
decided to adopt commercial standards rather than continue
with an in-house system. The standard chosen conforms to
the electrical characteristics defined by CCITf Recommendations V.11 and X.27 and EIA specification RS-485. Eachframe is Manchester encoded and the local line drivers aretransformer isolated at the driving end. The data format
adopted is supported by integrated circuits from National
Semiconductor (the NS8342/8343 transmitter/receiver set).

VI. TG8 HARDWARE
A. Overview
The TG8 is a timing module conforming to the VME
standard. It operates in the slave mode and also as an interrupt generator. The TG8 VME timing module consists of two
sections: a receiver part and a process part. The basic purpose of the receiver part is to accept all the frames from thetiming network and to pass on the treated events to the process part. The process part compares each received eventwith a set of pre-loaded parameters contained in a portion of
the on-board memory referred to as the •action table•. These
parameters are a subset of the total events contained in the
MTG's memory.

If a valid comparison is found between the received eventand the parameters loaded in the •action table•, then thatspecified action is performed. This will normally result ininterrupting the VME crate's CPU, and/or generating a TTL
level pulse on one of the module's eight front panel outputs.
The options are user programmable.
B. The Receiver Pan

In the MTG, the NS8342 integrated circuit frames the 32
bit events into four bytes. Each frame is enveloped within apredefined start/end sequence and in addition each byte starts
with a synchronizing bit and ends with a parity bit. The
TG8's NS8343 receiver chip performs the reverse operation
and reconverts the frame to a 32 bit NRZ word. In addition,
the NS8343 contains a seven bit error register which indicates, amongst other things, the detection of a mid-bit transition fault, an invalid ending sequence and also a parity error.

S10TS05
Timing and Synchronization

361

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-S10TS05

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, JapanThe contents of this register are used by the TG8 for error
detection.

fields. In this case they will always match with the corresponding field of the event being processed, no matter what
it contains. Thus up to three "don't care• wild cards can beused in order to specify a trigger condition.

The receiver continuously monitors the reception of thelms clock events. If a clock is missing then the hardware
generates a substitute clock, produces a lms •watch-dog"
error and informs the process part of the error situation. Allof these error bits can be read via the VME bus.
The interface between the NS8343 integrated circuit andthe process part incorporates a XILINX 3030 gate array. It
contains all the logic necessary to perform the above functions.
C. Process Part

The core of the process part is the Motorola MC68332
integrated circuit. This chip is a powerful microcontroller
based on the MC68020 microprocessor. It contains the various functions required for embedded control applications
such as 16 bit timers, RAM, UART, along with digital input
and output facilities. A second XILINX is used, this time a4008 containing 8000 gates, which contains all the logic tocontrol the counters and interrupt circuits for each of theeight outputs.

The module uses 16 bit VME data transfers and 24 bit
address decoding. In order to optimize communications between the VME bus and the timing card, two kbytes of the
TG8 's total memory are dual ported. These two kbytes canbe accessed both from the VME bus and the MC68332 microcontroller. For system configuration reasons, this dual
port memory can be placed on any location in the 16Mbyte
VME memory map. The module also contains lMbit of
EPROM, used to contain the microcontroller's firmware,plus 512k:bits of static RAM along with a 256*48 bit Content
Addressable Memory (CAM) which contain various user
tables.
The firmware's main task is to treat interrupts generated
by the receiver part. For every valid frame received theMC68332 uses the speed of the CAM to compare each eventwith up to 256 pre-loaded trigger conditions. If a valid comparison is detected then the microcontroller, using the XILINX gate array, loads the specified counter with theappropriate delay, selects the clock unit and prepares the
hardware to generate an output pulse and/or a VME interrupt
when the selected counter has been decremented to zero.

D. 1he Action Table
The action table is partitioned into two sections referred to as the trigger part and the action part. The trigger
part is located in the CAM, whilst the action part is locatedwithin the RAM.
The trigger part contains the full 32 bits required forthe event definition, plus the 16 bit PLS identifier. The action part describes what the TG8 must do when triggered,such as setting up a counter to make an output pulse etc.
With the exception of the first byte header, "don't care•values (Hex.FF) can be placed in any of the other three byte

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS05

VII.TGSSOFIWARE
From a software point of view, the major task is the
management of the action table. As previously mentioned,
the table contains 256 rows each of which describes a unit ofwork to be carried out by a TG8. Each row is composed of a
trigger and an action to be performed when the trigger conditions occur. A TG8 unit of work is specified by:
1) The trigger condition, which is composed of an event
specification and an optional telegram condition. Both ofthese must occur before the rest of the action table row is
processed.
2) The delay, which consists of a clocking train selection, and the number of ticks to be counted in the specified
train.
3) The mode, which describes how the TG8, counters
may be combined to produce counter chains, in which theoutput of one counter triggers the start of another; or burst
mode, in which pairs of counters are combined to produce aburst of pulses.
4) The result part, which will be either a VME bus interrupt, or an output pulse, or both. If a bus interrupt is specified, then a user specified callback routine will be invoked. A
library for the VME chassis processor will be provided.
Each TG8 module in a given VME crate is controlled bya device stub controller (DSC) processor [5], which runs a
diskless real time POSIX-4 compliant version of Unix supporting all the usual features such as NFS, TCPIP, XWindow client etc. Applications running at this level use the ·TG8 library to control the TG8 modules resident in the same
VME crate, and are able to communicate with Unix based
work stations running X-windows and OSF Motif.
The application program interface (API) will consist of a
C language binding to a TG8 library in which functions manipulate structures containing action table rows. Care must be
taken when combining these rows into an action table for aparticular TG8 Checks must be carried out to ensure that theindividual rows do not compete for TG8 resources, such ascounters, in real time. Some simple checks can be performed
which ensure a basic level of consistency, but full checking
would depend on knowing how the trigger conditions will
actually occur in real time, which is clearly impossible.

Vlll. CONCLUSIONSThe consolidation of CERNs different machine timing
systems has been proposed and discussed many times during
the past two decades, without significant results. This present
proposal was initially outlined at a joint PS/SL Control Users

S10TS05
362

Timing and Synchronization

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS05

Forum held in Chamonix, France, during April 1990. In
June 1991 the PS and SL control groups agreed on a specification for a common machine timing system [6]. This entailed using the IBM/PC based Master Timing Generator, aspresently used in the SL division and to produce a new VME
timing module compatible with both timing systems.
Presently, the prototype TG8 module is being tested in
the laboratory using the SL timing system. It is planned totest the unit with the PS system in the first quarter of 1992. It
is therefore too early to arrive at any definite conclusions,particularly regarding costs. The price of the "state of the art
hi-tech" components used in the TG8 is falling rapidly andclearly the production units will be far less expensive thanthe present prototype. On the cost basis however, one must
consider at what stage in a systems lifetime is it cost effective
to develop a completely new system rather than to develop
complex new modules compatible with two different existing
systems.

IX. ACKNOWLEDGEMENTS
Many people have contributed to the upgrading of the
PS/SL control and timing systems, but particular mention
must be made to the two group leaders, K.-H. Kissler and
F. Perriollat, who have stoically pursued the project. Also to
P. Nouchi and R. Parker for their invaluable contributions.

X. REFERENCES[1]

C.G. Beetham, R.J Lauckner, C.G. Saltmarsh, Overview of the SPS/LEP Fast Broadcast Message Timing
System, Proc. of the 1987 Particle Accelerator Conference, Washington, D.C., Vol. 1, p. 766.

[2]

F. Perriollat, C. Serre, Problems in Rejuvenating aControl System and Plans for the CERN Proton Synchrotron (CPS) ICALEPCS Vancouver 1989

[3]

C. G. Beetham, K. Kohler, C.R.C.B Parker, J.-B.
Ribes, The Transmission of Accelerator Timing Information around CERN, these Proceedings.

[4]

J. Boillot, G. Daems, P. Heymans, M. Overington
Pulse-To-Pulse Modulation of the Beam Characteristics
and Utilization in the CERN Accelerator Complex.
Proc. of the 1981 Particle Accelerator Conference,
Washington, D.C.

[5]

A. Gagnaire, N. de Metz Noblat, Ch. Serre, Cl. H.
Sicard, Replacing PS Controls Front End Minicomputers by VME Based 32-bit Processors, these Proceedings.

[6]

PS/SL Controls Consolidation Project, Technical Report, CERN PS/91-09(CO), CERN SL/91-12(CO).
Unpublished

S10TS05
Timing and Synchronization

363

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-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 Synchronization
364

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS06

Modular .. Electronics
Control System.

III.

and

The electronic system for the
MUTtokamaksvstemarespecially
designed in modular form.
The fourmodules are as described below.·
A. Module lr-"---._,

1_.... Insulating

Flange!op a:nd !ottcm nanse s

Fig. 2Module l generates the 50 ns master.
trigger pulse which is produced bya .SCR circuit activated manually by
a 22.5 v pulse circuit shown in
Fig. 4. The O.l µF capacitor of
the SCR unit generates a pulse when
fired across a 50 0 load resistor.
This pulse is sufficient to provide
accurate triggering of the units
shown in Fig. 3.

The tokamak vessel.

...

..1.r

-----::::... J\J..·Fig. 4,

Module l

SCR circuit.

B. Module 2

Fig. 3.

Block diagramfor
operational sequence
the tokamak system.

theofModule 2 consists of a SCR trigger
unit.
In this module the SCR
switches a 400 V, O.l µF capacitor
upon the introduction of a 20 v, 50
ns pulse from module l to the gateviaadecoupling
triggertransformer • The circuit is shownin Fig. 5(a).

S10TS06
Timing and Synchronization

365

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, Japanc. Module :S

circuits from
the
high
power
capacitors that the ignitron isswitching. The krytron circuit inmodule 4 provides a 2 kV pulse at
the ignitor with a current ·flow of
200 A to create the required hot
spot in the ignitron mercury poolnecessary for switching on
theignitrcn.
The ionizationtime(turn-on time) of the GL
7703
ignit_ron is 0.4 µs.

Module 3 is a krytron triggeringunit.
It uses a KN-68 krytron toswitch a 0.47 µF capacitor charged
to 2.5 kV. The pulse circuit is asshown in Fig. 5(b). The krytron is"kept-alive" by a 50 µA current to
the KA electrode via a 50
MOtapping resistor. The krytron istriggered by the introduction of apulse from module 2 to the gate of
the krytron via
adecoupling
trigger transformer as before.

D. Module 4
Module 4 generates theigniterpulse used to switch the ignitronand hence discharge the capacitor
energy into the tokamak system.
The circuit is shown in Fig.5(c).
It consists of a
1:1 decoupling
trigger transformer.
The secondaryof the transformer is connected via

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS06

IV.

CONCLUSION

A modular architecture consistingof the pulse generating devices
used in thetimingandtime
sequencing of the tokamak system is
described.
Its compactness
andversatility
haveallowedits
applications in ether pulse plasma
devices such as the focus C3J,
pinch C4J and electromagnetic shocktube E5J withminimalmodifications.

V. REFERENCES

t.n.•

{a)

(bl

(c::)

Module 2

Ma:luJ.e 3

Mcdule 4

ClJ"Design
and
A.C.
Chew,
a
DevelopmentofSmal 1
UniversityofTokamak",
Malaya,Kuala Lumpur, Ph.D.
dissertation,
March 1991.

C2J

S.Lee,"PulsedElectronic
ModularDevices",
UNESCO/
ASPEN
Physics
Equipment
Programme, IBSN 967-99993-0 0,
1986.

C3J

S.Lee,"LaserandPlasmaTechnology
World
Scientific, 1985, pp.38-46.
11

Fig. 5,Modules 2, 3 ~nd 4.

a 7 Q orotective series resistor
to the igniter of the GL 7703
ignitron.
Theignitronisprotected from pulse reversal(notto exceed 25 V) by a bank of 1N4007
diodes.
The l:l pulse transformer
serves to isolatethetrigger

C4J

S.H.
Saw,
"Experimental
Studies of a Current-stepping
Z-pinch",Universityof
Malaya,Kuala Lumpur, Ph.D.
Thesis, Dec.
1990.

C5J

S.Lee et. al. Laser and Plasma
Technology", World
Scientific, 1985, pp.3-20.

S10TS06
366

Timing and Synchronization

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

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-S10TS07

!

t

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

Figure 1: Hardware Structure of the RFX Central Timing System
Section delivers timing signals to all the equipment which is
not essential for machine operation, typically the diagnostics.
The two sections use one Timing Highway. The highway
serves first the Machine Section and afterwards the Diagnostics
Section. A timing Event Recorder is placed at the end of eachsection.

3.2. FEATURES

3.2.1. PRE-PROGRAMMED TIMING EVENTS
A number of pre-programmed timing events are released
sequentially after an initial software start command or hardware
start pulse. The start signal is fed into an Encoder event input
channel. The corresponding event then travels in encoded form
along the Timing Highway; it can be used by any downstream
Decoder module. It returns to a Decoder module placed at the"end" of the highway (physically near to the Encoder module).
This Decoder produces another timing pulse after a pre-programmed delay after receiving the encoded Start event Thispulse is again fed into an event input of the Encoder, from
where it travels along the highway as second encoded event.
All further timing events are generated in the same way as
delayed events after the start signal. This structure has theeffect of interrupting the timing sequence in case of interruption of the Timing Highway. In this case the clock signal ismissing which is used to count down the delays for the delayed
events.
At the local CAMAC crate, one decoder channel isrequired per event in order to "reproduce" the event as local
timing pulse. This reproduction includes a programmabledelay, the possibility to invert the output signal, and to program the duration of the local timing pulse.

3.2.2. ASYNCHRONOUS TIMING EVENfS
Encoders which are placed anywhere on the Timing
Highway may be used to encode asynchronous external sig-

nals. Such events are encoded in exactly the same way as preprogrammed events. They can be decoded and used by any
decoder downstream from the position of the encoder moduleon the highway. At RFX this mechanism is used to record
interventions of the independent Fast Machine Protection System and to trigger automatically data acquisition channels incase of such intervention.
3.2.3. GATING OF TIMING EVENTSTiming events produced by the central part of the timing
system are subject to gating by the fast machine protection
system. This intervention is part of the machine protection
strategy of RFX. The gates are placed at the inputs of theEncoder Modules of the event generation circuits.
3.2.4. TIMEBASE FOR ND AND D/A MODULES
A large number of ND Converter CAMAC Modules need
to be synchronized during the plasma shot both in terms ofsampling repetition rate and acquisition time window. An
equivalent requirement exists for the generation of fast, preprogrammed reference waveforms, which are produced by D/A
CAMAC modules with local memory. Among the many possible configurations two 'standard' configurations have been
selected: The Gated Single Speed Clock Generator configuration produces clock pulses of programmable frequency andon/off ratio for a time window which starts at a programmabledelay after a selected timing event and ends after a programmable time. This configuration occupies two Decoder
channels. The Dual Speed Clock Generator configuration produces clock pulses of programmable frequency fl, switches toprogrammable frequency f2 after a selected timing event, andswitches back to frequency fl after a programmable delay. Thisconfiguration occupies two Decoder channels.
3.2.5. PRECISION AND TIME RESOLUTION
The system guarantees an overall precision of less than

S10TS07
368

Timing and Synchronization

3 µs between any two events in any two locations of
the system. Time resolution, i.e. the minimum time
between two different, programmed or recorded events,
is 10 µs which are due to the frame length of theencode timing event on the Timing Highway.

3.2.6. SELF-TESTICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS07

MPB Timing encoder\RFX::SCTMl_0003

IU1lb

IsCTMz_ooo:(
Comment II
Name:

Muter MPB_TIMINC:

1.-.TIMINq
I Dispatch

a.annel 1: • Active
Event IT_STAIT_n.(

Trl111er:

I

ISTAIT_PM:TllCCER

Channel 2: • Active
Event IT_OPEN_PTSq

Automatic Stop of the Timing Sequence: In case
Trl19er: IOPEN_PTSO:TllCCE
of interruption of the Timing Highway the generation
Channel 3: • Activeof further timing events downstream from the interrupEvent IT _INSRT_PT~
Trl19er: I1NSIT_~CB:TRJCCE
tion is inhibited because the internal counters of the
Channel 4: • Active
downstream decoders are stopped due to the missing
EventlT_STAIT_PCj
Trl19er: ISTAIT_PC:TIUCCER
highway clock which is used to increment these counChannel
S:•
Activeters. As the Decoder modules which produce the highEvent:-, T _INSRT_PCj
Trl111er: I•NSIT_PC:TIUCCER..
way events are placed at the"end" of the highway any!Channel G: 0 Active
such interruption has the effect that no further events
Eve111: I
Trlooer. I oI
are produced.
Software
Channel:0
ActiveEvent Recording Function: In order to record the
Evenc: I
Trlooer. IoItime of occurrence of events, the timing system comprises Timing Event Recorder modules which register
I Apply I
I 1eset I
timing events. The same function is used for recording
I Cancel I[]Flasynchronous events and for the verification of the
Figure 2: User Software Window for Encoder Module
generation of the synchronous events.
Missing Clock Detection: The Timing Event
Recorder Module which is placed at the end of the Timing 4.2.1 MODULE-RELATED DEVICES
One such software device exists for each type of CAMAC
Highway can be programmed to produce an interrupt request to
module, which make all functions and settings of the actual
the computer in case of missing highway clock.
Watchdog Function: A software controlled watch-dog CAMAC modules available: MPB_DECODER, MPB_function can easily be implemented. At regular intervals a spe- ENCODER, and MPB_RECORDER respectively. These arecific software generated event is produced and sent down the the only software devices which have a direct hardware
highway. A Decoder channel placed at the end of the Timing counterpart Their fields reflect the hardware registers of themodules. Fig. 2 shows, as an example, the set-up window for
Highway is programmed to detect this event.
the Encoder module.
4. SW SYSTEM DESCRIPTION
4.2.2. RJNCTIONAL PSEUDO-DEVICES
4.1. MDSPLUS
The functional pseudo-devices have been provided in orderto provide an easier interface for the Decoder module. They do
The Timing System Software is embedded in not correspond directly to any hardware. Rather, the contents
MDSplus [5], the model driven data acquisition system of their fields are translated by their initialization operation
jointly developed by IGI Padova, MlT Plasma Fusion Labora- into the appropriate values and stored in the "target"
tory and the Fusion Group of Los Alamos National Labora- MPB_DECODER device. The pseudo-devices do not support
tory. It works in a VAX/VMS cluster environment It is based all features of the module, only the more commonly used conon the concept of an "experiment model" which contains a figurations are supported.
hierarchical, tree-structured representation of the experiment
MPB PULSE provides the software support for the genThe experiment model contains the description of the parame- eration of pre-programmed timing events at local CAMAC
ters to be loaded, of the data to be acquired, of the devices used crates (see 3.2.1 above). It provides the generation of a pulse
for acquisition, of the set-up of those devices, of the data after a programmable delay from a timing highway event.
acquisition and analysis "actions" to be executed during the Optionally a second pulse may be generated on the same outexperiment shot cycle.
put channel after a second delay. Pulses can be substituted
with level toggles.
4.2 TIMING SYSTEM SOFTWAREMPB_CLOCK is a continuous single speed clock generator, with programmable frequency and duty cycle.
The software support for the timing system 'has been
MPB GCLOCK provides the software support for theorganized in a three-layer approach: module-related devices, Gated Single Speed Clock Generator (see 3.2.4. above)
functional pseudo-devices which regroup frequently-used funcMPB DCLOCK provides the software support for thetionalities of modules into easy-to-handle software devices, and Dual Speed Clock Generator (see 3.2.4 above). Fig. 3 shows,
one system-wide device.
as an example, the corresponding set-up window.

I
I

S10TS07
Timing and Synchronization

369

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

4.2.3. SYSTEM DEVICEICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS07

MPll Dual speed clock generator \RfX::TOP.ltFX.IDA.POl.OIDAl..DEVICES.Pll:PllMC_IM_TBAS

""""'

II
The system pseudo-device MPB_a11111nel:l!__Gate MPll decoder:.._l\S_Cl'M_x___oo_z..;.I(_ _ _ _ _ _ _ __TIMING has three distinct functions: system initialization, system configurationaock MPll decoder:
I...\S_Cl'M_X..;;__oo_z..:.I(_ _ _ _ _ _.,...._ _ a11111nel: li._assistance, highway monitoring.
Event:
Tri99er mode:l,_E_ve_nt~-A typical initialization sequence is theDunatlon:!_.1_<(_ __Delay: j10E-:(
Exe. Trigger. IJ
following: First, the table of association"----between timing event codes and the corre40_ 0....:I('--·_ __Fniquencyl:
sponding times (in seconds relative to the
ouq,ut mode:! Double switch: to99lestart of the experiment pulse) is calculated
from the user input to the MPB_ ENCODER and MPB_TIMING devices.
Figure 3: User Software Window for Dual Speed Clock Generator Device
Next, initialization operations are performed
MPC_TIMING Timin9 highway supervisor\RFX:·MP&_TlM!NC·
f!'..il :ii'on all declared pseudo-devices by loading thecurrent shot number: 419
necessary parameters into the MPB_Recorded 11111•
Name
CO de
11111•DECODER devices (no CAMAC command
IEYerrt edltj-1. 399e-02-1.400e-02
is issued in this phase !). If event times arellot RecordedlS
2. OOOe-03
T_STAl\T_'lT
required (e.g. to record the correct pulse timen1111n1 statvs
llot Recorded
6. 000e·03
T_IllSl\T_'lT
16
in a MPB_PULSE device), they are retrieved-1.soo..oo-1.SOOe•OD
T_STAllT_Pll
19from the MPB_TIMING system-device.
·3. 02De·02-3. 019•-02
IHardware ten I
T_OPDl_PTSO
21
Last, initialization operations are performed<:;>on the MPB_DECODER and MPB_Start avant :ENCODER devices and set-up data are
Start encoder:loaded into the Decoder and Encoder module
Event recorder: cr_M_w___o_1- - - - - - - - - registers,
The second function of the systemI Apply I
I Update I
canceldevice MPB_TIMING is the assistance withsystem hardware configuration. In large sysFigure 4: User Software Window for Timing Event Recording
tems, as RFX, events are generated by an
Encoder whose trigger input is the output signal from a
The actual installation comprises of 5 Encoders,
Decoder channel which is used as a delayed pulse generator 24 Decoders, and 2 Event Recorders. About 20 different timwhich in tum is using an event produced by another Encoder ing events are being produced during a normal RFX pulse
channel. In addition, gated and dual speed clock generators cycle which are used as trigger signals in different parts of therequire two Decoder channels to work: the first channel is used plant 5 asynchronous events (from the protection system) are
as a gate for the second one. Keeping track of all necessary actually recorded and distributed. Time base signals are generconnections and of the times associated to events and pulses, ated for 52 CAMAC transient recorders providing 391 data
as well as frequency switches, may become very difficult when acquisition channels, 58 of which use the dual frequency clocka large set of signals is involved. MPB_TIMING supports this feature, and for 10 DIA converter modules which provide 42
by calculating the times associated with each event fol- fast reference waveforms.
lowing the cascade of hardware triggers and timing events;
REFERENCES
by providing a graphic display of the set of the programmed signals;[1] G. Malesani, G. Rostagni, ''The RFX Experiment", in Proby listing the required hardware connections.
ceedings of the 14th Symposium on Fusion Technology,
The third function of MPB_TIMING is the display of theSept. 1986, Avignon, France, pp.173-184
timing highway events as recorded by the timing event [2] V. Schmidt et al., "Structure definition and component selection for the RFX control and data acquisition system", in Prorecorder modules(s). As shown in Fig. 4 the time of arrival of
ceedings of the 12th Symposium on Fusion Engineering,each event is displayed alongside the time at which the event
Oct. 1987 Monterey, California, pp. 695-698
had been programmed.
Comment:

,_1

I

I

._I

· 5. OPERATION EXPERIENCE
The system is now fully operational. It was successfully
used during the integrated commissioning of the RFX Power
Supplies from April to October 1991. It is now being used forthe start-up phase of RFX which should lead to first plasma
before the end of 1991.

[3] J.M. Larsen et al., "The Data Acquisition System of theTokamak de Varennes", in Proceedings of the 15th Symposium on Fusion Technology, Utrecht, The Netherlands, Sept.
1988, pp. 1687-1691[4] manufacturer: MPB Technologies Inc., 1725 North Service
Road I Trans Canada Highway, DoIVal, Quebec H9P 111[5] G. Flor et al., "MDS-Plus - A Comprehensive Data Acquisition and Analysis System", in Proceedings of the 16th Symposium on Fusion Technology, Sept. 1990, London, U.K.,
pp. 1272-1276

S10TS07
370

Timing and Synchronization

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

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

2

Each PLO of the Radioheliograph consists of a 8.4GHz
variable frequency oscillator (VCO), a 1/16 frequency divider, a phase-detector (PD), a low-pass ftlter and 0 /E
converter. Figure 2 is a block diagram of the PLO. Since
the frequency down-conversion to the received signals at
17GHz is performed by a harmonic mixer, the second harmonic frequency of the PLO output is used as the local
signal.

OUTLINE

OF

THE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS08PHASE-LOCKNETWORKThe Nobeya.ma. Radioheliogra.ph operates at l 7GHz.
Signals received by the antennas a.re amplified andfrequency-converted to IF signals of 200MHz, and transmitted to a observation building. Then, cross-correlationsof the received signals a.re measured for all antenna pairs
to obtain Fourier components of radio images. Figure 1 isa function block diagram of the receiver. Low-noise amplifiers, frequency down-converters and local oscillators a.re
installed in front-end boxes of antenna sites. Each antenna
and the observation building a.re linked through opticalfiber cables. The IF signals are transmitted to the observation building via these optical fiber cables. Local signals of
frequency down-converters are phase-locked to a reference
frequency of 525MHz transmitted from a master oscillator
in the observation building through the optical fiber cables. An output of the master oscillator is converted to an
optical signal, which is splitted to 84 blanches by optical
dividers and transmitted to 84 antennas. The modulated
optical signals a.re demodulated by 0 /E converters in thefront-end boxes. Phase-locked oscillators (PLO's) are used
to generate local signals, which are phase-locked to the reference signals.

... e
CI. e

E-O

c::J..O__ Q
c_:?___________ _.

c: :~~0'..... t!O 0/E+> q:..._-,-.....

ro .....
> -0!...-!v ·"';:,.0 o:i(/)

O'

Figure 1: Functional Block Diagram of the Radioheliograph Receiver.

Figure 2: Block Dia.gram of the PLO.

3

PHASE

STABILITY

OF

THE

NET-

WORK
As mentioned above, the phase-lock network is an open
loop system and phase drifts of the network a.rise fromfollowing origins;(1) temperature responses of the optical fibers,(2) responses to mechanical stress of the optical fibers,(3) temperature responses of PLO's,(4) responses to input power drifts of PLO's, and(5) responses to supply voltage drifts of PLO's.
Phase drifts ca.used by (4) and (5) are relatively small.
The temperature coefficient of the phase stable opticalfiber cable is less than L5ppm/C (5ps/km/C). The cables
are buried Ulm depth in the ground, where the temperature variations are less than O.lC/day. As a result, phasedrifts of 17GHz RF signals are less than 1 deg/ day for thecables of 300m length.
Optical fibers are also used to transmit the local reference signal across azimuth and elevation axes from antennabases to the PLO's in the front-end boxes behind ma.in reftectors. Fibers are bent and twisted according to tracking
motions of antennas, with the minimum bending radius of
3 cm. These mechanical stresses ca.use phase variations oftransmitted RF signals. When the cable is bent from thestraight line, the phase of RF signals increases according
to decrease of the bending radius. Figure 3 shows the relation of the phase changes of RF signals and the bending
radius of the cable. Phase change of RF signals at 17GHz
is about lOdeg when the cable is bent from the straightline to the radius of 3cm. As the cable is loosely bound at
the axes to a.void such a strong stress in case of the Radioheliogra.ph, the actual phase variations are much smaller.

S10TS08
372

Timing and Synchronization
372

15

a

Coaxial Cable•••••••••••••• [$_!.}~~-~~~El

,•
,

I

,''

'

I

,,,

+100

q,o

..c:

/ 4. 8 deg/'C

+150

~10
'tl
......
«l

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S10TS08•..
•• •• ,'GJ,..,

ICALEPCS1991, Tsukuba, Japan

Optical Piber
5

I

,'

'

I

0..

I

,•

+50

0
0

50

100

Radius of Loop(mm)''I

1. 19 deg/'C

I

bO
ll)

'"Cl

Figure 3: Relation of the Phase of RF Signals a.nd theBending Radius.

ll)
(/j

0

+60

cd

Temp ("C)..c
Phase characteristics of the devices in the PLO a.re sensitive to temperature variations. In the Radioheliograph,these devices are placed on a thermally stable base controlled by a. Peltier device. The phase deviations of thetemperature stabilized PLO due to ambient temperature
variations a.re 0.5deg/C a.t 8.4GHz as shown in Figure 4.
The PLO is mounted in the front-end box which is maintained at temperature of 40±0.50.
Phase a.nd gain error in the measured Fourier components cause a. reduction in gain of the synthesized beam
and a.n increase in its sidelobe level. Total Phase stability
required to the Radioheliograph is less than 3deg duringobservation time of 6hours. This requirement is sufficiently
satisfied in the phase-lock network of the Radioheliograph.

4

PHASE NOISE OF THE NETWORK-0. 5 de g/C

0..

<l

-50

\
\
\
\
\

\

-100

\
\

\::-3. 85 deg/'C•···•PLO in Open Air.
Temp. Stabi 1ized PLO.
*" - ><Temp. Stabilized PLO with O/E.
~Temp. Stabilized PLO with O/E
installed in same sta&e.

G--eFigure 4: Realtion of the Phase of PLO Outputs and theAmbient Temperature.

The phase noise of the PLO degrades the sensitivity of
the radio interferometer. The degradation of sensitivity
is limited by the thermal noise of the output load register
is evaluated as the coherent loss of correlation output [6J.
in case of the PIN photo diode. The C/N ratio derived
Usually, the phase noises of the master oscillator and thefrom the above values is -116dB/Hz. On the other hand,
VCO a.re ma.in origins of the PLO phase noises. In the new
the measured value of the C/N ratio was a.bout lOldB/Hz
phase-lock network, the additional phase noise is generated
at lOkHz offset point from carrier when the optical input
in the O/E converter of the PLO. The phase noise level ispower was -25dBm. The measured ratio is deteriorated byexplained by using the carrier-to-noise ratio (C/N ratio).
15dB compared with the calculated one, which is probably
The output RF signal power of 0 /E converter is shown by
ca.used both by the noise included in the master oscilla2
P.=17eP RL/2h11, where Pis the optical input power, 17 is tor output itself and by ina.dequa.te matching between thethe quantum efficiency of photo diode, e is the charge ofphoto diode a.nd the transducer amplifier. Assuming thean electron, RL is the output load register, his the Plank's cut-off frequency of the PLO loop filter is 50KHz, this exconstant, v is the light frequency. In the phase-lock netperimental result corresponds to the additional coherent
work of the new radioheliograph, the optical input power
loss of less than 0.1 %.
is a.bout -25dBm including the transmission loss of boththe optical divider and the optical fiber cables. The wavelength oflight is 1.3µm. The output load register is 2.8k.11. 5
SUMMARY
Therefore, the detected RF signal power is calculated to
An optical fiber phase-lock network is installed to thebe 7.9x10- 9 W, where we assume the quantum eflicienc ofphoto diode 17 is 60%. The output noise power of the 0 /E Nobeyama Radioheliogra.ph. This network is a. open loop
converter is estimated to be a.bout 1.7x10-20 w/Hz, which system a.nd its phase stability strongly depends on re-

S10TS08
Timing and Synchronization

373

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-S10TS08

sponses to temperature and mechanical stress of the optical fiber cables and response to temperature of the PLO's.
The network satisfies the phase stability of 3deg/6hours in
rms, which is required in the Nobeyama Radioheliograph.
The phase noise generated at the O/E converters causes
the coherent loss of 0.1% at the correlator output.

6

REFERENCE[1] S. Tanaka, Y Muraka.m.i, Y. Sato and J. Urakawa,"Precise Tim.ing Signal Transmission by a New Optical Fiber Cable," KEK Report 90-9, pp.1-23, 1990.
[2] G. Lutes and L. Primas, "State-of-Art Fiber optics
for Short Distance Frequency Reference Distribution,"
TDA Progress Report 42-97, pp.81-87, 1989.
(3] K. Sato and T. Hara, "Performance of Optical Fibers
for Reference Frequency and IF Signal Transmissions in
VLBI Observations," Proc. of the Twenty-first Annual
Precise Time and Time Interval (PTII) Applications
and Planning Meeting, pp.421-430, 1989.
(4] L. E. Primas, G. F. Lutes, R. L. Sydnor, "Stabilized
Fiber Optic Frequency Distribution System," Internal
Report.
(5] H. Nakajima, K. Kai, S. Enome, K. Shibasaki, M.
Nishio, T. Taka.no, C. Torii, Y. Shiom.i, H. Sekiguchi,
M. Sawa, T. Bushimata, S. Kawashima, N. Shinohara and T. Kosugi, "A New Radio Heliograph at
Nobeyama," The 3rd Asia-Pacific Microwave Conference Proceedings, pp.1021-1023, 1990.
(6] A. E. E. Rogers and J. M. Moran, Jr., "Coherence
Lim.its for Very-Long Baseline Interferometory," IEEE
Trans. on Instrumentation and Measurement, Vol. IM30, No.4, pp.283-286, 1981.

S10TS08374

Timing and Synchronization374

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-S11LLC01

Local aftd MCR
X-Windows & Mo~f
H(II I L o(tt/ll>inl fOPotnf LINK

to SPSCONSOUSI• Sl Al~l1<10,k

(I())

SPl!T
/J/UOGED

ue,1e.rall71/l(,.--e Network
Etll~rn~t

lJS JIO()ULT/UK

Fflierntf f!<P/JP J

MC68030
DSC

LynxOS/t1sfrummftrtion ofllf
new <PnlroHtd tfUipmtt1fs

II+

f'rtttU£quipmtnl ._""'T-...~

Ollt/
tofl6nI

I\.._}
A« • THS II()#
SH.4« •Ht &100()

Figure 1. PS Control System during Transition Phasesystem, which offers the most recent POSIX standard
definitions, especially for the real - time (draft 1003.4 and1003.4a). The biggest advantage of this choice is that thewhole system documentation is intended for a C programmer
and even a device driver can be written in C.

C. Common CERN Facilities
One of the main goals of the CERN accelerator control
systems convergence is the non-duplication of effort inside theaccelerator community. For the front-end processors software
the work was shared between both PS and SL Divisions forthe following facilities:- RPC (Remote Procedure Call) and network compiler,- Common ORACLE on-line Data Base management,- Error reporting and system survey,- Nodal interpreter (written in C) running on the different
platforms of the network, with network extensions basedon the TCP/IP protocol suite, and integrated with
X-Windows and Motif environment [5]ill.PORTING THE PS CONTROLAPPLICATIONS TO THE DSC

A. Equipment Access Software
The present application structure layout providing theequipment access from the workstations remains unchanged.
This software, actually located in the front end minicomputers

and in the CAMAC embedded microprocessors, is ported in
the DSC processor. The former code (mainly in C) of the
CAMAC embedded processors running RMS68K operating
system is, for a major part of it, directly re-used under
LynxOS operating system.
In the VME context, simple VME interface boards areaccessed using the memory mapped l/O. Connections to fieldbuses, such as serial CAMAC, GPIB or 1553, are handled bystandard device drivers. Interface compatibility libraries hide
the structure changes from the former implementation. The
control data of these equipment access routines use the UNIX"shared memory segment" and the code of all the application
programs call a shared library where all the equipment accessroutines are stored. This point will increase the reliability as
the programs use a single copy of the library.

B. Real-Time Tasks
Whenever possible, the same interface library used forequipment access is re-used by real time tasks. The application
programs are not integrated at the level of interrupt routines,
but are working at the level of the user task. In case of
response time problems, the system thread facility will be
used. Our main real time constraints are today repetitive
acquisition at the rate of 3 msec. The actual measured responsetime for such a processing (including the wake up of a task
waiting for an external event, the time for this task to accessthe CAMAC interfaced equipment through a standard device
driver) is compatible with these constraints.

S11LLC01
376

Low-Level Controls376

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

C. General control applications
Detection of equipment alarms has been incorporated into
the equipment access software layer, through a uniquefunction, which can return an alarm indication, for all classesof equipmenL
Application libraries and tasks may log informative or
fault messages to a central service, which will record them in
the ORACLE data base and, if they occur in a remote call,display them on a window of the originating workstation.
A general data collection mechanism, synchronized withthe accelerator cycle, allows the workstations to subscribe to
specific sets of control parameters, and thus receive regularlycomplete updated data messages.

IV. FIRsT ACIUALIMPLEMENTATION
IN THE PS COMPLEXFirst actual implementation of the rejuvenated common
control system in the PS Accelerator Complex concerns the
LPI machines (Linac e·, Linac e+ and electron/positronaccumulator). A present console will be replaced by a work
place of three DEC workstations running UL1RIX, associatedwith selection and observation of analog and video signals.
The present control of the LPI equipment is done throughfront end minicomputas (NORD 120) and CAMAC embedded
microprocessors: they will be replaced by a file server and a setof DSC, each of them driving a serial CAMAC loop, linked
on a regional Ethernet segment of the control network. (Fig. I)
For the man machine interaction, at the level of theworkstations, in order to re-use as much as possible theinteractive application software, the Nodal functions of thepresent consoles are emulated on the workstations in order tominimize changes to existing Nodal programs. The generic
programs developed in C for the workstation interaction
prototype will be integrated (knob control, synoptic
presentation, console manager). (6] [7) No accelerator real-time
constraints must be treated at the level of the workstations, theDSC will take care of them. The number of DSC is functionof:• the geographical distribution of the CAMAC crates and the
topology of the equipment interfaces,• the real-time load of each DSC processor, depending on thereal-time constraints of the application programs
controlling the equipment (instrumentation, pulse-to-pulse
modulation).
As often as possible, one single DSC is used to control
one given beam insttumentation device; this point facilitates
the device diagnostic, and allows more development capability
to the equipment specialist.

As one of central service given by the network server, one
powerfull server is used to house the ORACLE on-line database management service; this data base is also used for the
off-line data preparation to allow an adequate continuous
running of the application whatever happens to the data baseserver.

V. CONCLUSION
The main points introduced by the common rejuvenatedcontrol system for the CERN accelerators could be listed asfollows:• UNIX is the single operating system for all the control
levels of the architecture,
the network is based on commercial well establishedstandards as TCP/IP protocol suite and NFS facilities,
to increase the reliability and to ease the maintenance, theworkstations and the DSC are used as diskless devices,
the access to equipment is done through a single
homogeneous level, the DSC,
the present important hardware investment (serial CAMAC
crates for the PS Complex) is kept; the equipment interface
does not need to be modified immediately,
we hope that the proposed architecture. based on open andwell accepted standards (hardware as well as software) will
pennit continuous upgrading as the technology evolves.

VI. REFERENCES[1]The PS and SL Control Groups, PS/SL Controls
Consolidation Project, Technical Report, CERN PS/91-09(CO), CERN Sl/91-12 (CO), April 1991.
2 R. Rausch, Ch. Serre (Editors), Common Control System for[ ] the CERN PS and SPS accelerators, Nov. 1991, these
Proceedings (ICALEPCS, Tsukuba, Japan, 1991).
[3] G. Benincasa, G. Daems, B. Frammery, P. Heymans,
F. Perriollat, Ch. Serre, Cl.H. Sicard, Rejuvenation of the
CPS Control System: the first slice, May 1991, Proceedingsof 1991 Particle Accelerator Conference, San Francisco.
[4] W. Heinze, Driving serial CAMAC systems from VME
crates, Nov. 1991, these Proceedings, (ICALPECS, Tsukuba,
Japan, 1991).
[5] F. Perriollat, G. Cuisinier, A. Gagnaire, Nodal in C,
PS/CO/note 91-20, Oct. 91 (CERN internal note; notpublished).
[6] M. Boutheon, F. Di Maio, A. Pace, General Man-MachineInterface used in accelerator Controls: some applications in
CERN/PS Control system rejuvenation, Nov. 1991, these
Proceedings, (ICALEPCS, Tsukuba, Japan, 1991).
[7] P. Antonsanti, M. Arruat, J.M. Bouche, L. Cons,
Y. Deloose, F. Di Maio, Workstations used as Consoles for
the CERN PS Complex: Setting up of the environment, Nov.
1991, these Proceedings, (ICALEPCS, Tsukuba, Japan,
1991).

S11LLC01
Low-Level Controls

377

377

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 Controls378

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

II. Control System of the PF Linac2>

pumps and interlock items. It also includes a few analog
parameters, such as reading the vacuum gage. Usually, theThe control system of the PF Linac shown in Fig. 1 digital parameters are indirectly controlled through a relay
has three kinds of computer communication loops: Loop-I, circuit from the sequencer.
Loop-2 and Loop-3. Loop-1 is an optical communication link
The optical communication link (9.6 kbps) is based
used for the main minicomputers (Mitsubishi, MELCOM on the RS422 specification and connects the FC-9801V with
70/30); Loop-2 and Loop-3 are optical communication links
the sequencers. The individual controllers must be coupledbetween satellite MELCOM 70/30 and the microprocessortightly, because one controller's infonnation is important forbased device controllers.
The device controllers reported here are connected to the others. For example, if the vacuum of the electron gun is
the minicomputer system through Loop-3: asynchronous destroyed, the sequencer for the high-voltage dome must
quickly turn-off the heater power supply of the cathode;communication at a signalling rate of 50 kbitls is possible.
otherwise, the cathode surface could be easily damaged by thepoor vacuum. The optical link is used to isolate the circuits in
the high-voltage dome (about 100 kV) from the ground level.
The FC-9801 V, including the loop-3 communication
board, has the following roles: One is a gateway forconnecting the electron gun control system to the PF linac
control system. It interchanges information between thesequencer system and the minicomputer system whileconverting each protocol. Another is to control the circuits in
the high-voltage dome from the ground level. The control
software for these functions were written in BASIC.

l!llMlm!...

r-;i==::t:=====.---,&llllU

QlNI8QllfB~------------,
1.QCAL rnN!'RIJll!R
I
RS422
I
RJLSB
I TRANSMISSION

CaJ : Qmmnnk:ttion O:.itrd Unit

LONCJ.DISTANCB"4

rlm'l'lllPitt:l!"llNIM.

I ANALOO:::::::::::j"IRANSMISSION
BUl'fl!R AMP I~

Mlll.O.')M-7Q'JO .. .... ... ..... .. MELCOM·7<VJO

LOOP·! (SMbpo)

I

k1PIJLSB..ili'!!"l!l!'.'Gl"l!'!"llr-!

..,......,_D1UVBRS__-!

1rxmaxr1
CIRC!Jlf

I
IK'---------------'

ANlt.L()q'DIOD'AL
TRANSMISSION

RlLSB
TRANSMISSION

Fig. 2 Block Diagram of the Electron Gun Control System
CCU:
PMC-2:COMMUNICATION UNIT
PULS!l-MOTOR CONTROL MOOIJLB

1'10-l(fl6: PARAl.LELIJOMOOUU!

ADll:!A:NO CONVBRTER MOOIJLB

ID. Electron Gun Control System

3 >.4 >The device controller for the electron gun is basicallyconstructed using an industrial personal computer (FC-9801 V)
and two sequencers (C200H), as shown in Fig. 2. The
sequencers are used to control a high-voltage dome and avacuum system for the electron gun. The controlled parametersof the sequencer for the high-voltage dome are the grid voltage
of a long-pulse mode (1 µs electron beam) and a short-pulse
mode (4 ns electron beam); a grid bias voltage; a heater
voltage and the heater current of the cathode as an analog
voltage control device; and ON/OFF for the devices and theinterlock items as a digital control device. The vacuum system
controller mainly controls digital parameters, such as the
open/close action of the gate valves, the ON/OFF for vacuum

Fig. 3 Block Diagram of the Slit Control System

IV. Beam Slit Control System!l
The beam-slit control system of the beam-energy
analyzing station comprises a remote controller at the klystrongallery and local controllers at the linac tunnel. A block
diagram is shown in Fig. 3. The slit controller controls twopulse motors, two potentiometers for position detection andfive limit switches which detect the limitation and theS11LLC02
Low-Level Controls

379

379

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-S11LLC02

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 Publishingcollision of moving slit blocks. The FC-9801V is used as aremote controller. One remote controller directly controls acouple of local controllers for slits utilizing an extended pulse
motor control board of the FC-9801V. The pulse motor
control signal generated in the remote controller is directlytransfered to the local controller through the RS422 levelsignal interface.
The local controller includes the pulse motor drivers,
which are directly connected to the slits. It also has a panel formaking the silts locally controllable: control buttons for theright and left movement of slits and a position display using a
digital volt meter, which shows the potentiometer voltage.
The control sequence in the local mode is achieved by a logic
circuit (T1L circuit) without any control software.
The control software on the remote controller was
written in BASIC. The remote controller also has a control
panel with a CRT display and hardware buttons controlled by
the software.

as a wide temperature allowance; an improved physical shockallowance; and improved immunity against noise from thepower line. It also improves the self diagnostic functions: awatchdog timer, an over voltage check for the power supply, atemperature emergency alarm, a memory parity check, etc.
The RAS-board has the above-described functions. Details
concerning the improved functions are shown in Table 1.
The operating system of the FC-9801V is MS-DOS,and the software for it was written in MS-DOS-based N88BASIC. The MS-DOS-based software system encouraged therapid development of the control program. Furthermore, theauto-starting-up function for the FC-9801V was established by
the RAM disk and by defining the AUTO-EXECUTIONBATCH file of the MS-DOS system. Starting-up without afloppy disk or a hard disk has great advantages regarding
reliability.

doi:10.18429/JACoW-ICALEPCS1991-S11LLC02

Main CPU Box* RAS Board Function
I l, Detection of the Power Supply OFF. -> NMI
I 2, Memory Parity Check.

-> NMII

I 3, Watchdog Timer.

-> NMI

II
I 4, Detection of the Temperature alarm. -> NMI
I
orINl'R I-> NMI

I 5, Extemal Alarm.
I 6, Remote ReseL(NMI, Non-Maskable Interrupt I INTR, Maskable Interrupt)

Table 1RAS Board Functions

l!x1lmdod BUS of l'C-9801 V(Addn>ar,'Dall)

Fig. 4

Configuration of FC-9801 V

V. Components of the Device Controllers
A. Configuration of the FC-9801 V6>
The FC-9801 V comprises a CPU box and an
expansion unit with extended circuit-boards, such as a RAM
disk (1 MBytes) with a battery back-up, a process input/output-board (PJ/0), an analog/digital converter-board (ADC),a Loop-3 communication-board and a RAS-board. Fig. 4
shows the system block diagram of the FC-9801 V. The CPU
box within the dotted line in Fig. 4 contains a CPU, a
ROM/RAM-unit, a DMA control-unit, a Calender/Timer-unit,
a CRT/Keyboard control-unit, a printer control-unit, anInterrupt control-unit and an RS232C-unit.
The FC-9801 V is an improved version of aconventional model of the PC-9801; it has better reliability
for industrial use. It has good environmental capabilities, such

IJ!D S-. Dilj>lay(Xnil, RBC, llaor)

Loap-3 Port

Fig. 5 Configuration of the CCU

S11LLC02
380

Low-Level Controls

380

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

B. Communication Control-Unit(Loop-3 CCU)

VI. Conclusion

The communication control-unit(CCU) interfaces
between the device controller and the PF linac control system.
Fig. 5 shows the configuration of the CCU board, which has a
one-chip CPU(HD63701) with ROM and I/0 ports, anasynchronous communication interface(ACIA) and dual-pon
RAMs. The dual-port RAMs are used to exchange control data
between Loop-3 and the FC-9801V.
The BASIC program on the FC-9801 V can easily
handle the CCU through the mail-box on the dual-port
memories. Separating of the communication task from the
CPU on the FC9801 V to the CCU board is extremely
effective for improving the reliability and productivity of the

The system now works well and is reliable. Byutilizing a commercially available system of an industrial
personal computer and a programmable s~uence controller,
the electron gun and slit controllers were made. The installedbattery back-up RAM disk, especially, made the maintenanceeasy and removed a mechanical unreliability which occurs
during a program boot from a floppy disk or a hard disk;
furthermore, it improves the starting-up time of the FC9801 V. Since we have adopted commercial devices and BASIC
language, the device controllers could be developed.
In the future we will use a real-time multi task
operating system for the device controller, and will replace
local controllers of slits with sequencers.

software.

Acknowledgement
The authors would like to thank Prof. Gen'ichi
Horikoshi and Prof. Akira Asami for their support, as well as
the members of the PF Llnac.
Reference

Fig. 6 Sequencer System

C. Sequence controllers?)
For designing the device controllers, great care shouldbe paid to the large noise caused by the high-voltage pulse(about 100 kV and 2 µs) of the gun pulser. Therefore, thesequencer was used for the device controller; it has a CPU, ananalog l/O, a digital 1/0 and a communication link and power
supply units. A block diagram of the high-voltage dome
controller is shown in Fig. 6. The capability of the individual
units for the environmental acceptance has been improved asin the case of the FC-9801 V. For example, the digital 1/0-unit
uses an optical coupled I/0, and the analog 1/0-unit uses a
differential 1/0.
The program for the sequencer can be written as aladder circuit diagram, which has been widely used to design arelay circuit. Funhennore, it can be handled and programmedon the FC-9801V. We can examine the sequencer's programby on-line checking from the FC-980IV. This is very
convenient for reading, writing and checking programs.

[l), T. Shidara et al., "Improvement on Monitor System·in the KEK 2.5..0eY Linac", KEK-Report-88-11, January
1989.
[2), K. Furukawa et al., "Recent Progress in the Control
System of the KEK 2.5-0e Y e"/e+ Llnac", Nucl. Inst. andMeth. A293(1990}16-22.
[3], M. Yokota et al., ''New Power Supplies for PF Linac
Electron Guns and their Control", Pioc. of the 16th Linac
Meeting, Nihon Univ., P. 212-214, September 1991.
[4], "KEK Photon Factory Activity Report", 1990.
[5), K. Kakihara et al., "Energy Slit System for the PF
2.5-0eY Linac", Proc. of the 7th Symposium on
Accelerator Science and Technology, P. 231-233, Osaka,
December 1989.
[6], "Hardware Manual of FC-9801Y in Japanese", (NEC,1989}.
(7], "Hardware Manual of C200H in Japanese",(OMRON, 1989}.

S11LLC02
Low-Level Controls

381

381

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-S11LLC02

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 Controls382

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

ICALEPCS1991, Tsukuba, Japanexplicitly non-equipotential.

settling time witherror 0.001%
0.1 s
analog part capacitywith respect to the body 150 pF
module widthl M

For the problems with higher requirements to thecontrol accuracy (power supply systems of the main
magnets and lenses of storage rings) the precision DAC
was developed that is based on the use of themultiphase pulse-width modulation. This method is the
improved version of the PWM. Its use enables one to
reduce the settling time by a factor of the number ofphases with respect to the conventional case andsimilarly to reduce the switching frequency. In thiscase, the requirements to the fast switching time of
the analog switches determining the PWM signal
became .weaker. This fact enables one to simplify
substantially the technical-design solutions of theswitches and drivers using the standard logic elementsof CMOS kind. The schematic diagram of the analog
part of the apparatus is given in Fig.2. DAC isperformed according to the two-cascade circuit. The
output voltage is the sum (with weights 1/2048) of
voltages of two independent DACs. The first one
converts 11 senior bits and has an 8-phase generationof the output signal (switches Kl - Kl6). The second
DAC for junior bits is a single-phase, 8-bit (K17 - Kl8).
Th~ voltages of both the DACs are summed by theresistors and smoothed by one filter of low
frequency (Al, A2). The bipolar voltage is producedby the output circuit (K19 -K22, A3, A4). in thesource of output voltage the precision reference
diod is employed in the oven wil.1:i the stability oftemperature lK.
The apparatus has the following parameters:

20 bits
8 I 192 v
15,625 µV
0.001%
0.0001%0.00002%/K+2µV/K

Apparatus for measurements of direct voltages
As alre~dy me.n_tio~ed, ·the real operation of any
large physical fac1hty is usually accompanied by thegeneration of a large wide range of very different
electromagnetic noises and quite often the amplitude ofthese noises is substantially higher than the signal
to be measured. Therefore, in the analog-to-digitalconverters the most noise-resistantmethodofpreliminary integration of the output signal is used.
Using various modifications of the method: thedual-slop integration, multi-tact integration, themethod of dynamic integration, the series of ADCs isdesigned at INP aimed at the use in the multichannel
noise-resistance measuring systems. Let us consider
briefly the features of construction and parameters ofthe most characteristic versions of this series.

S11LLC03
Low-Level Controls

383

383

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

In the process of energy retuning of the storage ring?f char~e particles the matched variation of parameters
is required for many power supply sources of magnetic
elements with its
high accuracy and highly
synchronous. In the power supply systems of first
generation this problem was solved by theappropriate selection (taking into account theindividual ·Characteristics of magnets) of special RCfilters on the DAC output. At present, the most relevant
solution of the problem given is the use of DAC withthe built-in digital interpolators. Two types of
converters have been developed.
The multichannel DAC provides the conversion of a
16 bits code with the error 0.01 % over 16 channels.
The built-in processor makes the simultaneous
variation of the output voltages. The variation law
for each channel is given with the intermediate values
by which the portion-linear interpolation is performed.
Up to 80 intermediate values can be given for eachchannel. In addition, in each linear part theinterpolation time is given within the range from 1 to
63 s with the quantization step of 1 s or in the range
from 0.1 to 6.3 s with the quantization step of 0.1 s.
For the control of the precision channel a 20 bit
DAC was developed with the built-in signal error
amplifier. The conversion error is 0.001 %. The
functions of the digital interpolator are similar tothat described above. ·The converter control is performed through thecontroller with the protocol MIL-STD 1553B. The
controller is designed in the CAMAC standard.

Fig.2. The analog section of multiphase PWM-DAC.

scale length
voltagerange••
quantization step
error (for 3 months)
nonlinearity
temperature factorof output voltage

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC03

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

integrated by a certain algorithm. When the integrator
output voltage reaches its threshold value (either A2 or
A4 comparator is operated) to the integrator input
the reference voltage is applied whose polarity is
opposite to the input voltage for the fixed period oftime, i.e. the multi-step integration of the reference andinput signals is performed. After input signal
integration the operation algorithm is the same as thatin the previous method. The end of the 3rd step,during which the reduced reference voltage is
integrated, is defined by the comparator A3. In thisscheme the integrator transfer factor is approximately
the same as the number of integration steps when ·measuring the input maximum signal.
Fig.3. Three-step integrating ADC.

The three-step integration with respect to the dualslop one enables the reduction of the error that is dueto the noises of theintegrator amplifier and comparator. An additional
advantage of the method is its high resolution atcomparatively low frequency of the tact generator. The
simplified block diagram of the device is given in Fig3.
The input signal with the help of amplifiers Al and A2
is converted into a current. A3, T2 is the current
mirror. To a<;hieve the fast action the switches Kl - K3
are made with diodes. The main reference signal isgenerated by the current generator on A5, T4. The
reference signal of the third step 64 times lowered ·isformed with A6,
TS. During the first step th~
integration of the input signal is performed. During
the subsequent two steps the integration of the mainand divided reference signals is performed. Thismethod is realized on the ADC 15 - 256. Its main
parameters are given in Tab.1. The device has a builtin memory for 256 words and the control circuit for
the analog multiplexer that transfers the address ofthe measured channel in the subsequent code throughthe socket on the front panel. While performing themultichannel measurements the operation is performedin the following way: preliminary to the service
register of ADC the initial and final addresses ofchannels are written along which the measurements
should be performed. By the start command ADC
performes the given series of ~easurements andwrites the results into the corresponding cell of thebuilt-in storage. The presence of this given mode
enables one to reduce substantially the load of the
CAMAC data bus in the measurement system.
The method of multistep integration enables one
to reach the high resolution and linearity of theconverter at quite high fast action. The block diagramof the method performance is given in Fig.4. Itsessence is the following. Simultaneously with the
input signal integration the reference signal isc+Uref~-Uref~+Uref~K-Uref~

I<

Fig.4. ADC with multicycle integration.

Note that conversion errors related to thepolarization of integrator capacitor dielectric are
reduced similarly. On the base of thi~ method theprecision converter ADC-22 was designed (Table 1).
Let us give some additional characteristics of thedevice that are important for the construction of
measuring systems of high accuracy: integration timeof the input signal - 20 ms; settling time for the input
amplifier (with an error 0.001 % - 8 ms; signal
measurement range 0.1; 1; 10; 100; 1000 V; resolution
capability, respectively, 0.1; l; 10; 100; 1000 µ.V;
relative error of conversion in the range of 10 V for 8 hours - 0.0005% of the scale,anadditionaltemperature error - 0.00005%/K; temperature drift ofvoltage - 0.03 µ.V /K; input current - lower than 10 pA;
the input resistance or! lower ranges - higher than 100
GOhm.
The method of dynamic integrator. This method isthe version of the pulse width modulation PWM
conversion with the pulse feed back. The block
diagram of the dynamic integrator operation is given
in Fig.5. The input signal is applied to the input of
integrator Al through resistor RZ. Depending on the
integrator input voltage polarity, defined by thecomparator A2, an appropriate reference voltage is

S11LLC03
384

Low-Level Controls384

applied to the integrator input through the switches Kl
and K2. (The operation oftheseswitches is
synchronized with the switching frequency by the Dtrigger.) The specific feature of the method is thatsimultaneously with the input and reference signals
through the capacitor C2 to the integrator input theperiodic voltage is applied of the rectangular shapewhose amplitude exceeds the sum of modules of the
input and reference voltages. The main advantage ofthe method is that it enables one to vary the time andbits of conversion. This property is especially useful for
ADC designed for the multichannel measurements:
measurements with not very high accuracy are
performed quickly but those of high accuracy - slower
but with larger number of bits. With larger time of
measurement an additional filtering is envisaged forhigh frequency noises in the measured signals.

Fig.5. ADC with dynamic-integrator.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC03

Table 1
'fype of device

AJX:22 AI:C20

lllC20-256!llClS-256

Conversion time, ms

40

7.5-48a 1.25-160

Scale (binary)

22

lH?O

13-20

15

a.001% o.au

a.au

0.011

256

256

120

80

Error (tor 3 months)
llemcrr (words)
Connon mode rejection, db

140

120

a.1

The metrological characteristics of devices remain
the same within the range 20 K - 50 K.
For the arrangements of the multichannel measuringsystems some analog multiplexers been developed at theInstitute:- AM-16R and AM-128R: with 16 and 64 channels
respectively, the commutation elements - s.ealed contact
reed relay with switching time of 1 ms, maximum
voltage - 200 V, commutation error - 50 µ,V.
- AM-16RM and AM-32R: with 16 and 32 channels
respectively,
thecommutation
elements
thermocompensated reed-relays, commutation error - 1µV. They are designed for the measuring systems inthe microvolt range.
AM-128: 64 channels, produced based on
microcircuits with the complementary MOS-transistors,
switching time - 10 µ,s, input voltage range - 10 V,
commutation error -100 µ,V.
The multiplexing of input signals is usually
performed according to the two wire circuit.
In all the versions the protection is envisaged against
the overvoltages by the input. The address register ofmultiplexers have 8 bits, that enables the union of up
to 256 measuring channels per one converter.

On the base of the method of dynamic integrator
ADC-20 and ADC-20-256 (Table 1) are designed. Eachof these modules has 8 time ranges of measurements(when switching the ranges the scale length changes
respectively) and 2 ranges for the input signals (8 V
and 500 mV) which enables the measurement of voltage
in the microvolt range. ADC-20-256 has a built-in
memory and the control for the multiplexer.

S11LLC03
Low-Level Controls

385

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-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

Communication between the SDVME as VME slave andthe processor as VME master is governed by the Data Transfer
protocol described in the VME specification. It is based onprogrammed IJO operation, short addressing and 16 bit datawidth (Al6/Dl6). Driving the Serial Highway is done inconservative mode which simplifies error treatment andrecovery.
The transmission speed is switchable to 0.5, l, 2.5 and 5
MHz for byte and bit serial operation. Confonn to the EUR
6100e specification, the appropriate number of space bytes isinserted into the Command messages to guarantee thecompletion of the Dataway cycle. The Serial Driver generates
the necessary parity check patterns for the outgoing Commandmessages and checks them for the incoming Reply messages.
The Serial Driver resides on a single-width 6U VME board.
A CAMAC access consists of writing to and reading fromcertain registers in the Serial Driver as shown in Figure 2. For
a CAMAC write, one first loads the Command registers with
SC, SN, SA and SF, and then loads the data into the Data
Write registers W24-W17 and W16-Wl which generates theCommand message. After a certain time which depends on the
speed of the Serial Highway (e.g. about 55us in 2.5MHz bit
serial systems), the VME processor can read the status(relative address $0C) which, after the Serial Driver having
received the Reply message of the addressed Serial Crate
Controller, contains the Reply. The Reply can be checked; if
no error occurred, the next CAMAC function can be executed.
DlS

00

DO

D8 D"I
SA

I I

I

SF :

''

02

l

I

04

'
W16!-Wl

06

oc
OE

R/W

SC

R/W

1'124-Wl"I

R/W

R24-Rl..,l

R

Rl6!-Rl

OA

R

I

-

IBUSl CSU

1111

rnl~!=l~IWls:clllEU! so I I

R

SGL

R

$X

I

SC

ACCESS

R/W

I

08

SN

EU

:coNTROL REG. REPLY INTO

R/W

12

: CONTROL REG. DEMAND INTl

R/W

14

: CONTROL REG. INT2 (NOT USED)

R/W

16

: CONTROL REG. INT3 (NOT USED)

R/W

18

: VECTOR REG. REPLY INTO

R/W

lA

I
I
I

VECTOR REG. DEMAND INTl

R/W

lC

: VECTOR REG. INT2 (NOT USED)

R/W

lE

: VECTOR REG. INT3 (NOT USED)

R/W

10

I

l

20

I

R

Figure 2. Address allocation of Serial Driver

S11LLC04
Low-Level Controls

387
387

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

Reading of the Reply message can be done by polling astatus bit NBUSY (which is reset at the start of the Commandmessage and set with the arrival of the Reply message) or byconnecting the read to an interrupt generated by the Reply
message. If after a certain time (corresponding to 320 bytes in
the message stream) the Reply message has not arrived, the
NBUSY bit and the interrupt are set together with thecorresponding error bits in the status register.
CAMAC read and control operations are generated byloading the command register. After having read the Reply
message, a control operation is terminated. For a read
operation, the data word has to be read from the data readregisters.
The software driver must assure that the sequence ofcommands necessary for a CAMAC access cannot beinterrupted by another CAMAC access to the same Serial
Driver.
Arriving Demand messages are stored in a FIFO (first-infirst-out) memory. This assures that all possible LAMs can beserved properly. The arrival of a Demand message is signalized
by an interrupt.
So, one has 2 internal interrupt sources. They are treatedby the VME compatible interrupter chip MC68153. Interrupt
levels, interrupt vectors and masking bits are freely
programmable. The Reply message generates an INTO, theDemand message an INTL

111.CHARACI'ERISTICSOFTHESDVMERELATIVE
ADDRESS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC04

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 Publishing

The address space needed by the Serial Driver is only 17 word
addresses (from $XXOO to $XX20, $ meaning hexadecimal),so short addressing mode has been chosen. The base address is
set by a switch in steps of $800 (pennitting 32 different
address settings). The address modifier codes accepted are $2D(SDVME is only accessible in supervisor mode) or $29 and$2D (accessible in user and supervisor mode), theconfiguration is selectable by a switch. Figure 2 shows theaddress allocation of the SDVME and the location of thecommand and error bits. SA, SF, SN, SC are the serial
subaddress, function, station and crate numbers. Wl-24 are thewrite, Rl-24 the read registers. Address $XXOC contains thestatus register.
The meaning of the status bits is as follows. The 4 LS
bits {ERR, SX, SQ, DERR) are inserted by the Serial Crate
Controller into the Reply message. The other bits are
generated by the SDVME:ERRCommand message was found by the Serial Crate
Controller to be non correct,
SX
X-response of CAMAC access,
SQ
Q-response of CAMAC access,
DERR
delayed error, see Chapter 12.2 in EUR 6100e,
NBUSY
Reply message has arrived which means a
Command - Reply transaction has been
completed,
CERR
error was detected, it is the OR signal of the error
bits ERR PB, ERR CP, ERR HED, ERR CPL
andNOSYNC,
FNE
FIFO for Demand messages not empty,
ERR CPL Reply message not complete, i.e. number ofbytes wrong,
ERRHED header in Reply message wrong,
ERR CP column parity error,
ERR PB byte parity error,
NOSYNC synchronization lost, i.e. clock is no longer
detected at the input port.
The register at relative address $OE contains the Demand
message and an error bit: SGL is the Serial graded LAM
pattern, ERR DM indicates an error in the Demand message,i.e. byte parity or column parity error. This register can only
be read.
The following 8 registers at $10...$1E serve to program
the MC68153 interrupter chip. For the exact meaning of thebits refer to the MC68153 data sheet. Only the first twocontrol and vector registers are used.

The last address (at read access) does a complete reset of the
Serial Driver, like SYSRESET on the VME bus.
An exhaustive description of the hardware can be found in

doi:10.18429/JACoW-ICALEPCS1991-S11LLC04[2].

IV. SPECIFICATION SUMMARY-

6U single VME slave board with Pl connector
register generated single CAMAC accessconservative mode and PIO only
bit and byte serial mode, 5, 2.5, 1 and 0.5 MHz selectableappropriate insertion of space bytes
stacking of Serial Demand messages in a FIFO
Reply message generates maskable interrupt, polling
possible
Demand message generates maskable interrupt, polling
possible
VME characteristic Al6/ 016, l(x), x programmable
low power consumption (6.5W) due to utilization of
CMOS

V. DRIVER SOFTWARE
The driver for single CAMAC instructions and blocktransfer runs under LYNX OS and is written in C. Originally,
it was written under OS-9, but then transported to the new PS
standard operating system which is the POSIX compliant
operating system LYNX OS. The execution speed per
CAMAC instruction for a list of CAMAC functions islOOKwords/s (for 24 or 16 bit words). The speed for blocktransfer (executing the same CAMAC read or write function)is 200Kwords/s. Both values hold for 5Mbyte/s transmission
speed on the Serial Highway and a 68030 CPU running at
25MHz. For 2.5Mbit/s transmission speed, 45us have to be
added per word transfer.

VI. ACKNOWLEDGMENTS
The original design of the SDVME was done by
L. Antonov and V. Dimitrov, CLANP, Sofia. The software
driver under LYNX OS was written by A. Gagnaire, CERN.

VII. REFERENCES
[1]

[2]

A. Gagnaire, N. de Metz-Noblat, Ch. Serre, C.H. Sicard,"Replacing PS Controls front end minicomputers by VME
based 32-bit processors", November 1991, these
Proceedings, (ICALEPCS, Tsukuba, Japan, 1991).
L. Antonov, V. Dimitrov, W. Heinze, "A CAMAC Serial
Highway Driver in VME", PS/CO/Note 91- 22, 1991.

S11LLC04
388

Low-Level Controls388

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

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-S11LLC05

and their characteristic frequencies, which may be studied, not converting treating system into too expensive one.
In this case the most interesting tasks are ones bound up
as mentioned above with intluence of space charge neutralization, and also with inertness of resonator feedbacks.
During beam injection it takes place ionization of residual
gas in transfer channel, that can create at the beginning of
beam pulse distinctive change of the form of the envelope
because of change of the phase shift of radial oscillations.
It can lead to unforeseen losses and to current limitation
because of mismatching. Because neutralization time takes
up 5 ... lOµs at designed vacuun1 ( and greatly depends on
vacuum ), then this process can be observed only by fastenough system. As the system "resonator-feedback" hascrossover frequency of 160 kHz, .then for observing intluence of this loop on the beam, diagnostic system must bea few times faster. In exploitation when tuning problems
are solved the speed of measurements can be equal or lessthan 100 Hz repetition rate of the Linac.

Figure 2: Block diagram of simple MUX.

inducings arising from high-power pulse equipment of accelerator. Generator of scanning envelope (EG) is started
by decay of DG pulse and permits working of generatorof scanning train (TG) . Pulses of TG are fed to counter
Cntl. Highest output of Cntl is connected to input of
Proposed system consists of three parts :counter Cnt2. Cntl output code controls working of de• Simple Profile Measurement system (SPM), which coders Del - Dc4, and Cnt2 code controls working of Dc5
permits to get profile of each pulse of the Linac by which permits working of Del - Dc4 in turn. Signals frommeans of integration of the currents from the wires of Del - Dc4 outputs converted by forming circuits (FC) open
Multiwire Chamber (MWC).
switches Sl - S62 in turn. Switch S63 is opened between
scanning pulses and prevents charge accumulation on input• Beam Current Transformer system (BCT), which per- capacitance of final amplifier. For determination of profile
mits to measure pulse current for each pulse of the for each beam pulse there is unit in scheme for repeated
Linac.
start of system and discharge of capacitors. It consistsof generator of envelope repetition (ERG) and switch S64• Fast Beam Parameter Measurement system {FBPM),
connected
to final amplifier input. After closing the switch
which permits to get series of beam profiles measured
S65
every
decay
of EG pulse starts ERG, which opens S64
within one beam pulse at tuning Linac regime or perandpermits
tobeginrepeated cycle of scanning. Thus it
mits to make SPM system measurement at normal 100
iscarriedout
inturndischarge of all capacitors throughHz Linac exploitation.
switches Sl - 862 and switch S64.
One of the advantages of computer treating is subtrac3.1 Simple Profile Measurement Systemtion of voltages existing on the capacitors when no beam
SPM hardware consists of analog signal multiplexer passes through MWC. Storing and subtracting of low(MUX) which is installed near MWC at the Linac, and frequency inducings permit us almost completely to elimADC in CAMAC crate, which is placed in accelerator con- inate their intluence on measurement results.
trol room. Methods of multiplexer construction are wellknown [3 14] so we limit ourselves only to brief describing 3.2 Beam Current Transformer Systemof its working. Simplified block diagram of device is given
in Fig. 2 . Besides of input RC-circuits multiplexer con- BCT system consists of low noise preamplifier (PAMPL)
sists of following parts: analog switches, control logical installed near feuite cuuent transformer (CT) at accelerscheme, circuits of signal forming for switch control, out- ator, main amplifier with scheme for suppression of lowput amplifier. Voltages accumulated on input capacitors frequency inducings and ADC installed in CAMAC crate
are switched in tum to final amplifier and through cable in accelerator control room. Working out amplifying tract
line are fed to ADC. MUX logical scheme is started by of CT we paid attention to decreasing of level of circuit
external sync pulse SP coming to input of time delay gen- noises and external inducings [5}. In system "CT - amplierator (DG) which is needed for shifting of scanning begin- fying tract" it was carried out optinllzation based on thening for a time sufficient for elimination of high-frequency criterion of signal/noise (S/N) maximum ratio. As result

3

Organization of measurement
system

S11LLC05
390

Low-Level Controls390

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

ICALEPCS1991, Tsukuba, Japanof this investigation it was found ma.xi.mum S/N at numberof turns of CT equal 170. The level of noise corresponds
80 nA of beam current. Existing software for BCT system is directed to subtraction of background, amplitude
analysis of current pulses and getting some quantitative
information for amplitude spectra (histograms).

in CAMAC crate. Module ADC has digital memory. This
module makes digitizing of signals and then memorizes received information about the magnitudes of signals for su~
sequent reading them into computer memory. Module TSl
is intended for time attaching of the beginning of program
running to synchronization pulse (SP) of accelerator. Let'sconsider structure and work of the part of complex which
permits to carry out calibration and lineariza.tion of signaltransmission tracts. This part of complex includes DAC,
two interfaces (IF-TMR and IF-RCV) and TS2. The baseof calibration algorithm consists in feeding of rectangular pulse from DAC to all inputs of matching amplifier.
As DAC should be placed near matching amplifier, thentransmission of digital code from computer to DAC is organized by modules IF-TMR and IF-RCV. Module IF-TMR
provides recoding of parallel code of calibration pulse amplitude to serial code for transmission through the cable.
Interface IF-RCV makes inverse transformation. Besides
that module IF-TMR transmits special code words needful for time attaching of calibration pulses to multiplexer
synchronization. Ma.in stage of calibration is carried out
when there are no beam current signals on MWC {for example, when MWC is taken out of beam ) and consists inmaking up the work table of correspondence between DAC
codes and codes being read from ADC memory. For thispurpose it is set consecutively a few tens of DAC amplitudes with equal intervals between them. When measuring
profile, inverse transformation is carried out. This permits
to decrease considerably influence of following factors on
final results of measurements:

Fast Beam Parameter Measurement
SystemFBPM system can measure a series of proton beam profiles
with time interval between adjacent profiles equal 1, 4µs
and more. The measurell'!ents of beam current can be done
within the same time interval by BCT system with separate fast ADC. Simplified scheme of system is given in
Fig. 3 and consists of two main parts:• Head part, i.e. complex of equipment placed near accelerator;• Equipment placed in control room of accelerator.
Control Rooll'\.4ccelcrator

CA.MAC Crate0:u....it--~~--'l-+4~ ~

~

~

~

SPZ

1} spread of transmi~ion coefficients of the channels;2) non-linearity of tracts;
3) constant low-frequency and impulse inducings.

11-Cla.Amplilier

Figure 3: Simplified scheme of fast beam para.meter measurement system.
Let's consider the structure and work of the ma.in elementsof the head part. Signals from MWC pass through 8channel matching amplifier with switched gain factor andmode of work. In tuning mode anlplifier works as linear
amplifier, in exploitation mode it works as charge sensitive
amplifier with gated input. In tuning mode signals enter the fast multiplexer (FMUX) which selects and holds
time samples of beam profiles and takes out them in consecutive order to the cable leading to fast ADC. ADC
FMUX synchronization is provided by series of pulses(SP2) from ADC. Besides these modules head part contains also DAC and interface-receiver (IF-RCV), which areintended for synchronization, calibration and switching of
the work mode.
Part of the system placed in control room of accelerator,
consists of microcomputer and five modules ( fast ADC,
two timer-synchronizators (TSl and TS2), interfacetransmitter {IF-TMR) and crate-controller {CC)), placed

Besides that system permits to control any change of thesefactors directly in process of measurement. With this purpose in module IF-TMR it is organized starting of second
sync pulse delayed from SP by module TS2 for the time
sufficient for reading of all information from ADC memory to computer; and to DAC it is transmitted code of
amplitude of verifying pulse and command for its forming.
Thus, it is fed additional verifying pulse of known amplitude to calibration input of matching amplifier in every
period between beam pulses, and it is started multiplexer,
ADC and program for reading of response information to
the computer memory. Result is compared with table { created at the beginning of measurement session with usingof second sync pulse ) and then is led out to videoterminal
screen. It permits operator to decide whether it is needed
repetition of the measurement because of some accidental momentary noise influence on the system ( or maybe
carrying out of new cycle of system calibration because ofchanged conditions of system work ). If we are satisfied
by test results then we convert, in accordance with work
table, putput values of ADC to corresponding input values of DAC. Because table is got only in finite number ofpoints, then we need linear interpolation. After converting

S11LLC05
Low-Level Controls

391

391

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

3.3

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC05

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-S11LLC05

the array of output ADC values to equivalent DAC values we normalize result array on maximum value and leadout information in form of profiles. Then we either repeat
cycle of measurements or go out of program.

Vwiu ,V

Results of bench test measurements

System was tested on the stand. To all 8 inputs of system
it was fed the same rectangular pulse. Following tests werecarried out:
1) Comparison of profiles which were got without calibration table and with table. In both cases it was fed signal
equal the half of maximum input signal. Without table
we had spread of profile top of 20 ... 30%, then with table
2 ... 3%.
2) Measurement at different speed of counting. That is
to say it was carried out measurements when varying thescanning time between multiplexer channels from some t 0
to tmin• It was got amplitude spectra (histograms) of output signal at different speed of counting. Results showed,that decreasing of scanning time less than 175 ns, whichcorresponds to the time of writing of one profile 1.4µs ,gives rise of equipment errors because of limited speed ofwriting to ADC memory.
3) Temperature drift. It was received amplitude spectraof output signal in some time interval of system running.
These measurements indicate that at room temperature
one can work with the system without re-calibration during
several hours not distorting measurement results.
4) System linearity. Research of linearity indicates that
distortions are less than ± 1%.
5) Measurements with slow and fast inducings. It was
carried out measurements in conditions when slow inducing makes up approximately 8 % of signal amplitude, andfast local inducing makes up about 50 % of signal amplitude. Note, that given inducings were stable in time.
Under these conditions due to calibration with the samestrays we could avoid their influence and achieve rectangular profile with spread of top about 2 ... 3%.
FBPM system is preparing now for installation on theaccelerator with new measurement assembly.

40-ts -to -s o s 1oy,..,,,,-ts -to -s

5tDX,,.,mFigure 4: Beam profile change after introducing of collimator: l)without, 2)with collimator.
~ 120 mA, pulse duration ~ 70µs the amplitude of signal
on central wire was a few Volts and inducing signals were
not more than 2 ADC channels (20 m V). Stability of beam
current was measured by BCT. Pulse current shapes thatwere got by BCT system had more details than ones fromusual current transformer monitor at the transfer channel. The inducings, that were measured in BCT tract, had
maximum value 0.2% of usual pulse current magnitude intransfer channel.

References[l] E.J. Soderstrom et al., Proceedings of 1989 IEEE
Particle Accelerator Conference, March 20-23, 1989,
Chicago, 89CH2669-0, v.3 of 3, p.1864.
[2] S. Bragin, N. Ilinsky, P. Reinhardt-Nickulin,
Yu. Senichev, Prib. Tekh. Eksp., No.3, 1990, p.59-62(in Russian).
[3] S. Bragin et al., Prib. Tekh. Eksp., No.6, 1990, p.76-79(in Russian).
(4] Lee D.M., Brown D., HardekopfR. et ci.I., IEEE Trans.
on Nucl. Sci. 1985, v. NS-32, No.5, p.1967.

Beam results

Simple profile measurement system and beam current
transformer system were tested on proton beam transfer
channel of the MMF Linac between injector and first accelerating resonator. MWC was installed perpendicularly
to beam axis. Multiplexer was placed at the distance of~
1 m from transfer channel. Information about shape andamplitude of pulse beam current was got with the helpof our current transformer and BCT system. Serviceability of system was tested by introducing of collimator intochannel at the distance of ~ 0.8 m from CT and MWC.
Changes of profiles after introducing of collimator (15 mm)
is shown in Fig. 4 . Introducing of collimator decreases as
signal amplitude as profile width. At pulse proton current(5] Gallegos F.R., Morrison L.J., Browman A.A., IEEE
Trans. on Nucl. Sci., 1985, v. NS-32, No.5, p.1959.

S11LLC05
392

Low-Level Controls392

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

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 Publishingattenuation of the BPM front-end analog processor. Finally,
its internal counters are initialized to begin counting channels
and samples per channel. After the set up is complete thecontroller accepts analog signals and begins analog to digitalconversion.
When the controller has acquired all the requested
beam position information, it formats the data, flags any
known bad data, and loads it into a CAMAC input FIFO.
Then the controller pulses a CAMAC input register that sets
an interrupt for reading the BPM data that has been loaded into
the input FIFO.

The CPU is a commercial STD board available fromMicrolink, a division of Sea-Ilan, Inc.[3] .
We have made several changes to the CPU card toaccommodate non-standard STD Bus signals that are routed on
the STD backplane.
The 8085 is designed to boot to address OOOOhhowever the ROM on the CPU circuit board resides at 2000h.
We have included a special boot sequence to take care of this.

doi:10.18429/JACoW-ICALEPCS1991-S11LLC06

H. Chassis/Backplane Circuit Board
The multiplexer controller resides in a Matrix
Corporation "Blackplane" STD bus card cage. The chassis waspurchased assembled with back plane and fused and switchedpower supply. The power supply is rated at 5 volts, 25 amps
and+/- 12 volts, 3 amps.

ill. CIRCUIT DESCRIPTION

A. CAMAC lnteiface Circuit Board
The CAMAC interface card is the interface between
the controller and the CAMAC crate connected to the PSR
microV AX via a CAMAC serial highway.

B.110 Functions Circuit Board
The controller talks to the Area Select chassis, theseveral Channel Select chassis, and the Timing and .Gate
Generator chassis via the three I/O cards. All three cards are
similar in that each card decodes I/O write instructions andlatches the data bus into buffers. The differences are that theport addresses differ from card to card.
The instruction decoding, on all the 1/0 cards, occurs
in programmable logic device (PLD) decode chip.

C. Timing and Control Circuit Board
The Timing and Control card generates the timing
pulses that other cards use to initiate analog to digitalconversions, strobe data in to RAM and increment counters.

D. Analog to Digital Conversion Circuit Board
The three AID cards, one each for horizontal position,
vertical position and beam intensity are identical except for thead~ decoding jumpers.

F. Beam Status Module & Counter Module

IV. SOFfWARE
Of the 3000 lines of 8085 assembly code that is the heart ofthe controller, only about 20 lines needed to be changed. Mostof the changes were in response to the hardware-specific bootsequence required by the new CPU card. The mapping of
memory needed to be modified in order to accommodate theaddress space available on the commercial STD cards.
A PC-based (MS-DOS) diagnostic was written toassist in the development of the new controller. The program
was written in C with a modifications to the software library
supplied with the CAMAC crate controller used for our
CAMAC-multiplexer testbed so that software interface to thelibrary routines was the same as those on the PSR microVAX.
The source code for the diagnostic program was easily ported
to the VAX with very few changes.
The VAX-based diagnostic can be run from any VTtype tenninal. One can modify the command list which is sent
to the multiplexer controller. By modifying the command list
one can control channel selection, time into pulse, time into
cycle, trigger selection, sensitivity, and samples per channel.
The diagnostics will send the list to the controller, handling all
the handshaking just as the production software used by theoperators does. When the controller has acquired the data it
saved to disk,where it is available for viewing and analysis.
The diagnostic program uncovered a CAMAC
interface timing problem, that existed with the old controller,
which had the potential to cause data to be lost.

V. RUN-TIME EXPERIENCE
The Beam Status card uses one bit of a 2K RAM tostore whether or not beam was present at the time of an analog
to digital conversions.
The microprocessor subroutine that packs the data forshipping to the VAX looks at the beam status data and flags
the horizontal and vertical position data if beam was notpresent. The bad data flag is an 80h[2] in the position byte.
When the VAX software sees the 80h in a stream of data it
ignores that byte and does not attempt to display it.
The main function of the counter card is to countSamples Per Channel (SPC).

G. CPU Circuit Board

The controller has been used for about four months of
PSR production. We have had no major problems with thesystem. The addition of needed diagnostic software has
allowed us to accurately pinpoint the sources of problems thathave come up.
[l] E.F. Higgins and F.D. Wells," A Beam Position Monitor
System for the Proton Storage Ring and LAMPF", Particle
Accelerator Conference, Washingtan, DC USA (1981)[2]The lower-case "h" indicates a hexidecimal number.
[3] "STD-245, 8085A Single Board Computer, Operations
Manual" Microlink, a division of Sea-Ilan, Inc.,14602 N. US
Hwy 31, Carmel, IN USA..46032

S11LLC06
394

Low-Level Controls394

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

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 Publishing

the case is a 20dB gain amplifier to avoid signal to noise
ratio degradation from the detector to the electronics
building located outside the tunnel (Fig. 2).

The detector case is attached to the tunnel wall
pointing to the beam pipe of interest. The front wall of thecase is carefully adjusted so as to degrade the lower energy
component of the background residual radiation. The gain
calibration of each tube is still in progress. There is notenough data available yet to check performance degradation
due to radiation damage of the tube.

doi:10.18429/JACoW-ICALEPCS1991-S11LLC07

B. CAMAC system
The detector signals are digitized by CAMAC ADCs locatedin a building outside of the accelerator tunnel. All timing
signals and gating are controlled by CAMAC modules. For
the beam transport lines a 100 MHz ADC is used. The
booster accelerates one bunch in 25 msec. To acquire theturn by turn beam loss with sufficient resolution, a 100 MHz
ADC with 2.5 MBytes of memory is used (Fig. 3).
Since the main ring accelerates nine bunches, a bunch• selection system is used to select the bunch of interest. Also
since the acceleration ramp is rather long, data along thewhole ramp cannot be acquired. Instead only the loss

Figure 2 An overview of the detector.

:---------------------,
I

I

L---------------------1,---------------------,

I

·ADC

I

00011111)

L---------------------1(2. 5118).. (C.UU.C)..••:----------------'------,
I

I

L---------------------1,---------------------,

I

I

L---------------------1:-------------~-------,

I

I

L---------------------1,---------------------,

I

I

L---------------------1:---------------------,II

RIO Volt111

L--------------------~

Power Su,, Ir

Figure 3 Booster loss system configuration.

S11LLC07
396

Low-Level Controls396

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

signal peak is digitized using a specially developed ADC andstored in memory. Figure 4 shows the nine bunch beam loss
in the main ring. All ADCs have hardware memory so thatthe computer is not used during the actual acquiring of data
(Fig. 5).
The ADC system described above enables us to observe
time dependent beam loss for an individual bunch through­out the entire acceleration cycle. Beam loss due to betatronoscillation for instance, can be observed which will help intuning the ring correctly.
The CAMAC crates are connected to a VME comput­
er via the Branch Highway interface. The Branch Highway
to VME interface card has hardware interrupt inputs which
are used to signal the end of the acceleration cycle.

Figure 4 Nine bunch loss in the 12GeV main ring.

r--------------------1
IJIP
I

I
I
I

I
I
I
I

TO CCR(AHAl.OG llOlflTOI)----iAHALOGQA.

L--------------------~,----------------------._.,_......__,,.._...
I
I
I

L-------------------­....·­.
........­

.....
_..,
::

.

CAMAC D 1/0;::

Biol Yolutt

VME Coapuur

Power 111,.lr

Figure s Main ring loss system configuration.

S11LLC07
Low-Level Controls

397
397

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

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-S11LLC07

III. SOFrWARE

assumptions about the type and number of detectors so that
this system could be used for other purposes.

The data acquisition system software consists of a number of
separate application programs written in C using X-windows
and the OSF/Motif toolkit. The operating system is UNIX.
The CAMAC hardware information is stored in a
database. Using a menu-driven program the user is able toeasily update the location and module types, the command
list, etc. of the CAMAC hardware in the system. The dataacquisition program reads this database at start up as its
only source of hardware information thus requiring no soft­
ware changes when there is a hardware change.
The actual data acquisition is made up of several
processes running simultaneously. There is a control process,a CAMAC process, and a separate graph process for eachdetector signal being acquired. Except for the signal data to
be displayed all interprocess communication is handled bycustom X events. The signal data to be graphed is passed via
the UNIX message facility.
The control process oversees all aspects of the dataacquisition system. This process maintains an additional
database which lists which CAMAC commands start or stop
the data acquisition for each detector, commands to read in
the data, control of the detector voltage, and timing control.
The user can create several software "detectors"
for eachhardware detector corresponding to different types of data
desired.
The CAMAC process is the only means of communi­
cation with the hardware using a UNIX device driverdeveloped especially for this purpose. This device driver has
a command list mode in which the CAMAC instructions for
all detectors are concatenated into a single list by thecontrol process, passed to the CAMAC process and loaded
into the device driver. At a hardware interrupt indicating theacceleration cycle has completed, this instruction list is
executed and the data is passed back to the CAMAC
process. The CAMAC process scales the data appropriately
and sends the scaled data to the proper graph process by aUNIX message.
A separate graph process is running for each detector
signal being acquired. The graph process sends to the
CAMAC process graph scale and window size information
so that the data can be scaled properly. The data is scaledin the CAMAC process to minimize the amount of data
which has to be passed between processes; all redundantdata are thrown away.
Although an object oriented language was not used forsoftware development, the data structures and functions
were constructed in an object oriented fashion. As a result
there is good isolation between different types of data
structures and functions which makes extension and debug­
ging of the system easier. Also there are· no hard-coded

IV. SYSTEM PERFORMANCE
Figure 6 shows a typical display. Multiple detector windows
as well as the control window are shown. The bunch tagging
system is very effective in acquiring data from the same
bunch throughout the accelerator complex. A comparison
between the data displayed in several windows clearly showswhere and when the contents of the bunch is lost. The beamloss shown in a single window varies from cycle to cycle
showing the lack of beam stability. In the beam loss data forthe booster loss has been observed outside of the rf bucket
during acceleration. This type of loss cannot be observed
very well with the usual type of beam monitors because thissignal is buried in the signal from the particles in the rf
bucket.
Although the system is working a number of improve­ments need to be made. Due to the large amount of dataacquired (3 Mbytes), it takes two acceleration cycles (onecycle = 5 sec) for the graph windows to update. Consider­able speed increases can be obtained by optimizing the datascaling routines. Also there are still problems in communi­
cation between the CAMAC device driver and the CAMAC
process.

Figure 6 An example of the display picture.

V. CONCLUSION
A development of a fast beam loss system is now
successfully going on at KEK. In spite of waiting for some
improvements, the turn by turn beam loss observation in theaccelerator has been certainly realized. Some examination
on radiation damage of the detector and on the gain
variation are waiting for soon.

S11LLC07
398

Low-Level Controls
398

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

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-S11LLC08

chl
ch>

ch 3.2

LOCAL COMPUTER
ch I

ch2

Figure 1. Fundamental plan of a horizontal NDPM
with multi-anodes.

MPX

ch 8

ch 8
I

l~~'l

!CONTROL ROOMI

1I

tfa 11 I

tl I j I

Ia 11 i

MPV 952 (B.B )

1ch
anode
on
MC?

MPV 952 (B.B l

MPV 962 (B.B )oscilloscope

Figure 3. Multiplexer and A/D converter system totake signals from 32 anodes.

Figure 2. Block diagram of the electric circuit connecting every anode on an MCP or EM.

B. Data taking

Every anode's output signal from beam injection to
extraction is memorized by a VME local computer via
an A/D converter. The A/D converter has a datasampling period which can be changed from 3µsec to
255µsec, and eight input terminals. As shown in Figure
3, (in the case of the minimum data-sampling period)
the signal from one anode is chosen by a multiplexer for3µsec with every 24µsec(=3µsecx8ch). Therefore, our
NDPM system (which has 32 anodes) requires four A/D
converters and the minimum data taking period for one
anode is 24µ sec. As the data-transfer time from thelocal computer to the center one is not fast, we set the
maximum data-taking number from one anode to 256.
When the measuring time range is long, such as theMa.in ring acceleration period (about 3 sec), we increase
the sampling time from the minimum value (=3µsec)
and take 256 data by averaging over several data for an
increasing S/N ratio.

C. Calibration
In this system the most important point concerns
the calibration of the entire gain, which includes the
MCP, pri-amp, voltage-to-frequency converter (VFC),
frequency-to-voltage converter (FVC), main-amp andanalog-to-digital converter (ADC). For observations of
the beam profile, the direction of the anode stripes on
the MCP is set so as to be parallel to the beam direction, as is shown in the left-hand figure of Figure 4(Measuring position). For the calibration, however, thedirection of the stripes is changed by a pulse motor andset perpendicularly to the beam direction, as shown in
the right-hand figure of Figure 4 (Calibrating position).
In this position, each anode can be considered to receive
the same quantity of ions produced by the circulating
beam, and the anode signal should be similar to eachother. Therefore, the calibration constants are set bythese figure heights.

S11LLC08
400

Low-Level Controls

400anodeICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC08

Horizontal Beam Profile of M. R
from 0 (msecl to 1904 (m sec ), step
24.0 (msec)

anode

/__

~~~

beam

Figure 4. Orientation of the anode strip lines of
a MCP.
Left figure: Measuring position(the anode strip are parallel to the beam).
Right figure : Calibrating position(the anode strip are perpendicular to the beam) .
Hor (cm)

D. Rearrangement
The VME computer system t akes the time dep endence of the current from every anode via an A/D converter in the "measuring position", divides the databy the above-mentioned calibration constants and rearranges them to a "mountain view" of the transversal
beam profile within one acceleration period, as shownin Figure 5.
MC P

position

t1

t2

13

time

t
(A)

(8)

(C)

!D)

1

4
'

rearrangementincomputer

1' c=:::;>

r
time

!3

Figure 6. "mountain vi ew" of hori zontal beam profilein the Main ring.

(mm)( normal beam l

+10

*~ *~
I
:
~

*_../ :

12
-1 0 '--~--'-~~-'-~--'~~~~--'

0.0
t1
(Al

(8)

(Cl

(0 )

MCP positi on

Figure 5. Typical current signal from multi- anodes
and a "mou ntain view" of the beamprofile rearranged by a computer.

0.5

LO
1.5
Ti me (sec )

2.0

2.5

Fi gure 7. Time dependence of the center of th ehori zontal beam profile calculated
by a computer.

3. MEASUREMENT RESULT

A. "Mounta in view" and time dep endence of the beamprofile center
The computer outputs by rearranging the data at
the place, where the dispersion function is small, of theMain ring. The time dependence of the center of thehorizontal beam profile (shown in Figure 7) is in goodag reement with the output signal of the 6R monitor(shown in Figure 8).

Figure 8. Output Signal of the 6R monitor at thesame position of NDPM (X:200ms/d, Y:2mm/d) .

S11LLC08
Low-Level Controls

401

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-S11LLC08

B. Momentum spread of circulating beam

35

Beam Size(This measurement idea was suggested by
Prof.S.Hiramatsu and Dr.N.Kumagai.)

E

30

II

E

Lr" 25

Assuming that the intrinsic beam profile and momen-\LOtum distribution have Gausian shapes, the total halfbeam width (x) is

,._:.

'°

20

(i5

15

~

N

E
ro
(J)
co

(1)
where fJ is the Twiss parameter, e the beam emit-

"ffi

I

tance, T/ the dispersion function, and ~p the momentum spread. If two NDPMs are installed at a location

\

10

'~

~\

5
0

1000

0

with the same Twiss parameters (/3), but having a differ-

2000

3000

Time( ms)ent dispersion function (ri 1 , 172), the momentum spread

Figure 10. Time dependence of a half beam width atis deduced from the above-mentioned equation to

203 height in the Main ring at large 77.

(2)

Momentum Spred in KEK-PS-Matn ringiwhere x 1 and x 2 are the half beam width at the pooition with r]l and ri 2 , respectively.
The time dependence of a half beam width at 203
height of a beam profile measured by MCP (at smallri) is shown in the Figure 9, and the output of EM (atlarge ry) is shown in the Figure 10. The time dependenceof the momentum spread in the Main ring is calculated
from those two figures and is shown in Figure 11, whichshows a sharp peak at the transition time (rv0.8s).

1
1

0.8

/

I "'

1.

()')

v.

jll Vr~.,.,\

§ o.4

'J

r/

1·

\)

\

\

"'-,,~~

~~,

·-~

0.2

0

1000

2000

3000

Time(ms)
35

Figure 11. Time dependence of the momentum spread .
in the Main ring.

Beam Size at Small Dispersion Function
30

E

s 25
LL

'7 20

4. REFERENCES

C'O"
(J)

15

N

(i5

'"iii

[1] T.Kawakubo, T.Ishida, E.Kadokura, Y.Ajima andT.Adachi, "Fast Data Acquisition System of a Non-

10

I

5

Destructive Profile Monitor for a Synchrotron Beam by0

using Micro Channel Plate with Multi-Anodes", NIM
A302,pp.397-405,I991.

0

1000

2000
Time(ms)

3000

Figure 9. Time dependence of a half beam width at(2] T.Kawakubo, T.Ishida, E.Kadokura, Y.Ajima and203 height in the Main ring at small 77.

T.Adachi, "Non-Destructive Ream Profile Monitors in
the KEK-Proton Synchrotron", KEK Preprint 91-23 May
1991.

S11LLC08
402

Low-Level Controls402

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-S11LLC09

RAM space is not necessary. However, the decision toincorporate this memory space was made to provide for
unforeseen modifications to the requirements for themodule. By designing in this extra memory the module will
be able to do more complex data and register operations in
the future. Again, because of the RAM chips memory
structure, two chips were used to allow for sixteen bit datawords.
One Integrated Device Technology 7133 Dual Port
RAM is used as register space for data that will be written
onto the CAMAC data bus. The use of this is necessary tomeet the CAMAC specifications for dataway operations.
The microcontroller (even with a clock frequency of 16MHz) cannot respond to a CAMAC write command fastenough to have the appropriate data present on the
CAMAC dataway when the S2 line is asserted 700 ns into
the CAMAC data cycle.{3] The IDT chip was chosenbecause of its 55 ns address access time.[4] This speed willallow for valid data to be present at the dataway for the readcommand.The IDT chip has a sixteen bit wide memory
structure.
The usage of a dual port RAM chip is acceptablebecause of the functionality requirements of the module. No
data manipulations must be done on the data present in theregisters in the 700 ns from the beginning of a CAMAC data
cycle to when valid data must be present on the dataway.
To load the appropriate register data onto thedataway within 700 ns an EPLD is used to decode the
CAMAC Function and Address lines. This EPLD logicallyrecognizes the CAMAC read commands and then sets theaddress to point to the correct memory location in the DualPort Ram. When the S2 line is asserted the Dual Port thenwrites the requested register data onto the CAMAC
dataway.
The EPLD also sets the specified values for the Q,
X, and Look-At-Me (LAM) lines. Use of the EPLD insuresthat these signals are present on the dataway at theappropriate times in the CAMAC cycle. The Q line can beasserted or deasserted, or can be set to reflect the state of
the ready bit or the LAM. The EPLD also sets X = 1 for all
valid functions.

iii. Data Latches
Because of the timing constraints of the CAMAC
dataway, cycle valid data from a CAMAC write operation
will not be present on the dataway by the time themicrocontroller can respond.[5] To solve this problem,
74AS573 Transparent Latches are used to latch in the write
data and hold it until the microcontroller is ready to process
the information. The data is latched off the bus by the
logical AND of the N and Sl lines. This insures that valid
write data is held for the microcontroller.
The microcontroller memory maps the write data
latches into its external memory structure. When the
microcontroller is ready to process the write data, it asserts
the correct address lines and processes the information.

lnt•rfoce fQ Cxp•rfmental[l•clronfc1 Vic:i f'ront Pon.!

."

Hltoclil&26'

Hila chi
6264•••

16 OilDolo Su•lnt•I
6DC196KC~icro-Conlrcllor

lnl1I

2764
[PRO~

IDT
71.33
Ouol Port R,U.I
C>.M.AC A1od
C..l.MAC D1ccd1
Commands[PLO
1--~-----

Figure l Module Block Diagram
These latches also store the CAMAC Function andAddress lines.
This information is held until the
microcontroller can process and decode the commands.
All external memory decoding will be handled by asecond EPLD. This EPLD decodes the address bus fromthe microcontroller and asserts chip enable lines to eachexternal memory device. Addresses were specified to allow
for use of the entire memory space of each external device
in the future.

IV. Camac Functions
The module has been designed to respond to thefollowing commands, while setting Q and LAM lines
accordingly.
F(O)A(O)F(2)A(O)F(O)A(4)F(O)A(6)F(9)A(l)F(16)A(l)F(16)A(4)F(16)A(6)F(24)A(O)F(26)A(O)F(S)A(O)
F(lO)A(O)

Read entire Polarity Register, set Q to thevalue of the ready output pin.
Read entire Polarity Register, latch thecurrent state into the latched register, set
the ready output pin to the value of the 5th
bit of the latched register, clear the LAM
and interrupt pin, and set Q to previous
ready output pin.
Read Timer register, assert Q line.
Read Sequence register, assert Q line.
Clear the current Polarity register, clear thetimer register, clear ready bit, set LAM andinterrupt output pin, set Q to LAM value.
Write current state, clear the ready bit,assert LAM, set interrupt bit, assert Q.
Write timer register, assert Q.
Write sequence register, assert Q.
Disable LAM, deassert Q.
Enable LAM, deassert Q.
Test LAM, set Q=LAM.
Clear all registers, clear LAM, set
Q =LAM, clear interrupt bit.

S11LLC09404

Low-Level Controls404

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

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingF(16)A(O)
Write entire polarity register, assert Q.
F(27)A(1)Test interrupt bit, Q =interrupt output.
The module will enter appropriate reset states by
the assertion of the Z, I, or C lines. The Z signal resets themodule by clearing all registers, disabling the LAM, andstopping the countdown timer. The C line clears theregisters and stops the timer. The I line inhibits the moduleand precludes any processing while the line is asserted.

[5) Peter Clout, A Camac Primer, I.A-UR-82-2718, Los Alamos National
Laboratory, 1982, pg. 33

V. Software
Programming, written in Assembly, for the
microcontroller is stored in the EPROM chip. Softwaredevelopment for the module will be done using the IntelEVSOC196KC Evaluation Board and 2500AD 8096
Assembler software on a PC. The EPROM chips will thenbe burned with the code for the module.
The microcontroller is in an idle state until themodule is addressed. An interrupt to the microcontroller isgenerated
the N line of the CAMAC dataway. This
interrupt causes the microcontroller to access the EPROM
memory vector and begin executing the program. The
microcontroller will then access the FOAO latches. The
decodes these and proceeds with the proper
operations.
During all program executions the
speed
pin to assert the
microcontroller uses aline as a module busy line. This alerts the computer is still
prc1cei>Srr.1g and avoids the possibility of the module receivinga second interrupt before the processing of the firstcommand is complete.

•4.s of this vniting the module is ready to enter thephase. The design of the circuitry and printed circuit
has been completed and the module has been
Softv;arefor the microcontroller
and extensive testing is requiredneeds to beready to be incorporated into
before the

Acknowledgements
The authors wish to acknowledge the contributions
T. Capshew, J. Collins, D. W. Frame, J.
to this work
Graham, and the Computer /Electronics group at Indiana
1n1,~,.,.,o;tv Cyclotron Facility.
This work was done under the support of National
Science Foundation Grant #NSF PHY 90-15957.

References[1] Intel, 16-Bil Embedded Cor.rrollers Handbook, Mt. Prospect, IL,
1990, pg. 5-1. pg. 5-126[2] Peter Oout,A Camac Primer, I.A-UR-82-2718, Los Alamos National
LaboratOiy, 1982, pg. 72 - pg. 74[3] IEEE Std 583-1975 pg. 50(4) Integrated Device Technology, High-Speed CMOS Databook, Santa
Cara, CA, 1988, pg. 5-61

S11LLC09
Low-Level Controls

405

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-S11LLC09

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 Controls406

q(tx)ws=- B(tx)
R

Bis the magnetic inductance
S is the sensor cross-section
The product W <io S characterizes the sensor
sensitivity .
.Po~ converting the charge into the code the capacity
C 1s discharged by the calibrated current on the circuit
Uref, Rref and Sw2 and the discharge time indicatedby the comparator is then measured. As a result, thevalue

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S11LLC10

the switch (in this case, on Sla) does not make any
influence on the charge stored in the integrator
capacity. During the storage and conversion the switch'
Swl is disconnected (Sla and Slc are off, Slb is in the
conducting state providing the connection of the feedback circuit).

W s RrefIref

R UrefB (tx)

is uniquely related to the magnetic field value at theFig2. The integrator with •triangle" of switches.
moment when the integration is stopped. From it isseen that the accuracy of measurements is determined
The typical current of a signal is of 0.1-10
by the stability of the sensor parameters (W '" S) andthree elements of the measurer: R, Rref, and Uref. In mA. Therefore, the operational amplifier with theorder to provide the high accuracy the wire and the field transistors with the input current lower than 0.1
metal-film resistors of highest stability are used as R nA with an extra circuit of dynamical corre"ction of theand Rref. The voltage reference diodes have passed the input bias voltage fits quite well as the integrator
amplifier.
pr~liminary test, certified of the thermostable point.
For carrying out the practical measurements
This mode enables one to avoid the use of the oven forrequiring,as a rule, the simultaneous measurements 0£
the diode at the accuracy of the reference voltage of up
a
few
tens
of signals the four-channel CAMAC-module
to 0.002%. As to the capacity C, its nominal -is notisdesignedthat is operated according the principal
important. The only thing required is its short-term
described.
stability. The leakage currents of modern capacitors
The field sensors are located just in the magnets and~re negligible small and the only error, which could bethey
are connected to the measuring devices with amtroduced by the capacitor is the variation of the.
coaxialcable. The connecting cable can be up to 100
effective charge caused by the adsorption (themlongwith substantial capacitance. To avoid thepolarization of the dielectric of capacitor). In order todistortionofthe signal by the capacity of the cable andachieve the accuracy about 0.01 % it is sufficient to use
the capacitors with the low polarization dielectrics th~reby to avoid errors, the integrating resistor is(polystirol, teflon). In order to reach the higher removed to the sensor. In this case, the measurer has theaccuracies one has to use the special analog circuit zero input resistance, which cancels the influence ofofthecompensa~ionfor polarization. The the track capacity.
The moments of the integration start and stop areparameters of the circuit are selected for each certain
given
from outside and usually by the pulses ofcapacitor.
synchronization
system of the facility under service. In
As a rule, the problem of precise measuring the
this
case,
the
input
"integration start" is common fortime interval does not make any difficulties.
fourchannelsandthe control for the integration
Some difficulties occur with the switch Swl. To
isindividualfor
eachchannel.
stop
prov~de the time for commutation (about 10 ns)
Technical
parametersof the module:
reqmres the use of semiconductor switches which
Numberofchannels4
havethe
noticeable switch-on-resistance. The
LSB
weight5
pQ
swi.tch resistance is added td the integrating
16 bitresistance R and its instability introduces the error. Dynamic range
0.01 %
This problem is solved by the "triangle" of switches Accuracy
Conversion
time
50
ms
Swl (Fig.2) assembled with the field transistors.
In this scheme, the on-state of the switch Sla Slc
The given accuracy is realized at the integration timeand off-state of Slb correspond to the on-state of' Swl.
While the integration of a signal the current passes of a signal of longer than 500 µ.s, at lowest times
through the switch Sla but the. amplifier watches the the accuracy decreases.
At present, the apparatus is modified in order topoint G via the switch Slc and namely at this point
improvethe measurement accuracy (an accuracy nearlyprovides the zero potential. Thus, the voltage drop on
0.002%, scale 18 bit).

S11LLC10
Low-Level Controls

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

407

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC01

and control the velocity profile of the system when a positionchange is required.

Galil Controllerr--------G(s)r------------,
R(s)
E(s\
1

--D.111

)

1
1
1I

1
1

1

D(s) 14-1--i:I
I

III__________ JI

I

L.........

C(s)

lI

""'""""'""""1

L~~~-----lFigure 2. Analog Hardware Elements of PID Filter.

The transform: sl(z. l) and z =T(z+l)

Figure 3. Flying Wire Control Loop

l+sT
T
1.L

known as t.i':ie

B. Velocity Profile2bilinear transformation, applied to the Laplace yields the z
domain.
The function expressed in the z domain assumes asampling in time wher<:: the sample interval is constant. The
filter function is then transfonncd into a series of outputs

The position change of the wire is accomplished byaccelerating at a constant rate, holding a constml velocity, andthen decelerating at the smne constant rate used foracceleration. The Gali! Contrnllcr contains a digital filter4

correlated to the nth, n - 1, n - 2, etc. samples in time. This
yields a difference equation for the filter output :u(t) u(n-2) + K1e(n) + K1e(n-l) + K3e(n-2)

25 6
5 1
with D(z) = GN z which transforms to G(s) = K +'b
1
.J2l_
s+

=

where

KI = Kp + 2Kdff + KjT/2,

K2 =KiT -4K 1/r,
:md
K3 = 2Kctff - Kp +KjT/2.
These constants can then be programmed into a digital
signal processing system. 2

D. Stability
The typical stability criterion applied to analog systems
are Bode plots in frequency, ands-plane (s = o + jw) plots for
Laplace transfer functions. Bede plots graph the gain andphase of the system vs frequency 10 determine both gain andphase margin. A stable system has a gain less than l when
the phase reaches 1300.
The s-planc plot~ the imaginary and real parL5 of the
Laplace transfer function. 'I11e requirement for st.1bility is that
all roots of the characteristic equation have negative real parts.
Using the z-transfonn for discrete time sampling systems thez-plane stable area maps into the unit circle.

ill. MOTION CONTROL
A. Introduction
Typically motion control systems fall into two categories.
A velocity control system tries to maintain a continuous speed
profile for a system while a position control system will try to
first establish aml t11en maintain a position co1Tesponding totJ1e desired input. The Fennilab flying wire system described
previously3 uses a combination of these to maintain positionLrz - 256
which, for a<b, is a lead filter. K = GN and the zero and poletmn relate to a am! b as GN~S~ ~

ii= ~
K

.

The wire speed in the Fermilab Tevatron is 5!!!. . The wire issmounted on a fork tbat is .0965 m radius yielding an operating
frequency of 325 radians/sec. The oplica1 encoder provides
16384 counts/rev. Hardware prescales the counts of theencoder and the processor periodically samples the output todetennine the actual position error on a time scale that matches
the required system performance. TypiC<llly a sampled systemshould run at 10 to 20 times the minimum sample rate for themeasurement process. It is clear that the processor can notdirectly sample the encoder inputs in real time. However the
motion of t11c wire can be corrected on the millisecond
timescale ro:iuired of the system.

C. Tuning the Loop
We want to select the parameters to produce a fast but
stable response. For the flying wire system t11e most stable
set of operating parameters have historically been determined
empirically. We have since taken measurements with an
HP3563A Control System Analyzer to detennine the true bestparameters over a wide range of operating conditions.
From these measurements the natural oscillation frequency
can be obtained. The zero is then selected to be half to two
t11irds of the natural frequency such lhat: ZR 256e·0.4roc T
where T is the sample interval. For an We 200 rad/sec and=

T = SG-0 µsec yields ZR==246. Our zeros are in the range of

S12FC01
Feedback Control

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

409

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 Publishing

245 to 248. The digital number input is 0 to 255. The gain
varies from system to system but in the range of a few counts( min 4 to max 7) out of 256.
The mechanical components of the system are subject tochange due to temperature, humidity, and wear. If the closed
loop parameters are set appropriately then the system will
operate reliably over time. For our system the pole is set at
its default value.

A fast feedforward loop that is able to learn from the pasthistory of accelerating cycles is needed. We chose a digitalsystem to generate the feedforward waveform because of its
versatility and accuracy. Digital signal processing techniques
enable the use of a learning algorithm. Because true system
testing will not be done until all installation is done and there
is beam in the machine, the hardware needs to be made as
general as possible. Any last minute modifications can thenbe done in software. A block diagram of the RF system isshown in figure 4. Note that all the electronics for the lowlevel system resides in the VXI crate.

doi:10.18429/JACoW-ICALEPCS1991-S12FC01

D. Control System Analyzers
There is a new class of instrumentation available to aid in
the process of designing and implementing closed loop
systems referred to as Dynamic System Analyzers. These
analyzers work in both time and frequency domain. A special
case is the Control System Analyzer (CSA) which also allows
inputs or outputs to be either digital or analog. Once themeasurement has been made, a wide range of math functions isavailable for analysis.
The CSA has been used to make step response
measurements in the time domain. It will be used to makemeasurements of the closed loop perfonnance of the system.
This work has not yet been accomplished.

VXICrate

IV. LINAC LLRF
A. Introduction
FANBACKThe last three 201 MHz accelerator sections of the
Fermilab linear accelerator are being replaced by seven new
sections operating at 805 MHz, each driven by a 12 MW
Klystron. Due to the higher frequency and higher gradient thisupgrade will increase the beam energy of the linac from 200 to
400 MeV. In order to minimize momentum spread of thebeam, tight regulation of the RF gradient in the cavities isneeded. Feedback: alone does not have the needed bandwidth tomeet the regulation specification, therefore a processor basedlearning feedforward system was added.

CAVIlYDRIVE

TRANSFORMER

B. The System
The accelerating field gradient in the cavity is regulated bya feedback system controlling the magnitude and phase of the
RF field inside the cavity. The design specification is toregulate the gradient field to 1% magnitude and 1 degree phaseduring the time that beam is present. This requirement for
regulation is made difficult by three aspects of the RF system.
First, there are long group delays, (400ns), through the
Klystron and wave-guides connected to the cavity. The Laplacetransform of this delay(Td) is e-sTd. This is a frequency
dependent phase shift that limits the closed loop bandwidth of
the feedback loop to less than 400KHz. Second, the beamloading is a rectangular pulse that has a very fast rise time.
This demands a fast response from the control loops. The
third problem is that while the cavity responds like a simple
LC resonator at its central res.onant frequency, it can also be
excited in other modes at freque::icies that are within t500KHz.
Any positive loop gain at these resonant frequencies will makethe system unstable.

Figure 4. UNAC RF System

C. The Model
The system was modeled to a great degree of accuracy
using a time domain analysis program, EX'IENDS. Using
EXTEND, the nonlinear components such as the Klystron,
mixers and phase shifter are modeled so that the system can beunderstood over its full dynamic range of operation However amuch simpler linear model works well over a narrow dynamic
range. This linear model is shown in Figure 5.
All signals shown in the diagram are modulation signalsof the 805 MHz signals magnitude or phase. The 805 MHz
carrier is mixed in and out with the control signals, but has nodirect relation to the feedback loops.

S12FC01410

Feedback Control
410

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

points tllat may be sampled at any time during the 125 us of
the RF pulse .
The error signals for both the magnitude and phase loops
are sampled at 10 Mega-samples/s by an 8 bit ADC and storedin FIFO memory. After the error waveforms bave been
digitized, the module generates an interrupt that starts the DSP
routines in the processor. The computed feedforward waveformis then loaded into another FIFO memory and played backduring the next accelerating cycle through a 12 bit DAC. Thissignal is summed with the feedback signal before driving thephase shifter or the magnitude modulation mixer. The 8-bit
data from the ADC is averaged by the CPU which gives ahigher resolution to the playback DAC.

Kd/(s+ 125000)
ccelerating Cavity

FeedforwardrPlant Model

G(sJ

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC01

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

Feedback....-~~~~~~--!

ICALEPCS1991, Tsukuba, Japan

Dbeam(s)Kc

E. The Operating System_J

The MTOS-UX kernel from Industrial Programming, Inc.
is a true multi-processor multi-tasking real-time operating
system. This kernel is in wide use at Fermilab and has been
ported to many different platforms.
The system is designed so that on startup, the software
detects the number of low level RF modules and processorsthat are installed in the VXI mainframe. It then configures
itself to distribute the processing capability as needed by eacb
LLRF system. This allows the system to be reconfigured byusers without the support of a system software

Ka is feedback loop gain.
Kb is a 'learned" gain by an !IR filter.
G(s) is a heuristically detennined function.
Dbearn(s) is the disturbance due to the beam
Feedforward is active only during beam.

5 Linear Model of RF System.

The feedforward system was dictated by the conflict
between the need for fast system response (200 ns) and large
group delay (400 ns) due to the Klystron and waveguide.
Feedforward is made possible because Uie system, running at
15Hz, is very repetitive from one acceleration cycle to thenext. This enables the algorithm to learn the gain Kb by theuse of an UR Filter that is incremented once each cycle.
Therefore, the filtering function is in the domain of cycle tocycle time and not the linear time of the 125us of one
accelerating cycle.
G(s) is the plant model for the transfer function of thebeam loading effect and Klystron combined. G(s) can be any
function or array that is found to be the best fit and is limited
to only a 2.5 MHz bandwidth by au anti-aliasing filter.

D. The Hardware
In order to implement the feedforward system, a fast wavefonn capture and playback generator is needed. The amount ofsignal processing and 1.0. needed demanded a high-speed
dedicated processor and wide-band computer bus. Good RFshielding at 805Mhz and a quiet environment for signal
conditioning is necessary. The system also needs to be
remotely operated and must have good remote diagnostics.
Due to the large number of components a large card form
factor was needed. VXIbus was chosen as the platform, as it
was conceived for this general type of application. Figure 6 isa block diagram of the Low Level Module.
The control system is designed to be as fle,t.ible aspossible, since full testing of the system will not be done
until there is beam in the machine. This philosophy isembodied by giving the processor full access to the wideband
error signals of the feedback loops and 16 circuit diagnostic

F. The Software
The main job of MTOS (see Figure 6), is to complete
two main tasks when it receives an interrupt from the LLRF
module. The interrupt starts the producer task "I_l5HZ",
which then reads the 16 MADC channels and the two ADC
FIFO memories. Next, it reads the control buffer memory andthen writes to the LLRF Module registers. Finally, it places
pointers to the data arrays in the MTOS message buffer, andthen unblocks the consumer task M_l5HZ.
"M_l5HZ" processes the error waveform, creates thefeedforward waveform. and writes it to the DAC memory intlie LLRF module . It then resumes waiting on the message
buffer for the next task. These tasks must be completed before
the next interrupt is received.
The task "TEST' keeps track of the percent of idle time
for the processor and displays it on an SSM module. This
allows the developers to monitor processor bandwidth aschanges are made. This has proved to be a very usefulfunction.
"DIAGNOSTICS" is off-line code that will le"8t many of
the signal paths in the module. This includes memory,
ADCs, DACs, MADCs and some of the RF paths. The
human interface for this will be LabView running on a
Macintosh 2ci. Communication from the Macintosh to the
LINAC control system is done over TokenRing.

S12FC01
Feedback Control

411
411

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

INTERRUPTFROMLLRF
MODill.E

PRODUCERICALEPCS1991, Tsukuba, Japanamplitude, a simple software routine can create the proper
shape of the feedforward signal. The amplitude can be"learned" by looking at past error waveforms. Thus fastchanges can be made to the drive signal, (100ns), without
affecting the closed loop bandwidth.
The proper amplitude of the feedforward pulse is computedin the following manner. A section of the error waveform,
before the beam, is averaged in order to establish a baseline
value. In the same way the average error is found while beam
is present. The beam present value is subtracted from the prebeam value and multiplied by a gain constant. This value isthen filtered over many accelerating cycles by an IIR filter.
The filter algorithm is simply 5% new value plus 95% oldvalue. This filtered value is then added to a baseline value ofthe feedback waveform between the specified start and stop
times of the beam. When the loop comes into its steady statevalue the error waveform will be flat across the top. This isbecause the feedforward loop is doing all of the beam loading
correction while the feedback loop is taking care of slower
errors.

I_lSHZIA.SK

DIAGNOSTICy Fl.AG?

READMADCREADJx:CONTRolscAN

CONSUMER TASK

M_lSHZKERNEL

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC01

BLOCKED WAITING FOR

I Beam Pulse::IRWARDSIGNAL
PROCESSING[~IDFIFOTESTIDIE TIME MONTIDR

Pre-beam
SampleI-fir

DIAGNOSTIC

Beam
SampleI

I

I

I- J_;--FE-ED_F_OR.....WARDWAVFORM
Figw-e 6 LLRF software overview
,,..

125us

'\t_

L

...-1

G. Feedforward
Figure 7 Feedforward learning over several pulses.

Originally the concept was to have the feedforward loop
learn the entire error wavefonn. Each sample would have an
IIR filter that would learn the best value for that point in time
to minimize the error signal. In the model this worked well as
all the system delay could effectively be removed from theloop. This would allow the effective system closed loop
bandwidth to be increased to about 2.5MHz, the frequency of
the anti-aliasing filters. This algorithm continuously adapts toany changes of the system. The main problem with thisapproach is the other resonant modes of the cavity that arewithin t2.5 MHz of the main resonant mode. These modes
are ideally nulled out of the fan-back signal by summing all 8
cells of the cavity together. However, mismatches in thesignal combiner cause gain slope changes in the response thatcause the closed loop system to oscillate. Another approach isneeded in order to achieve the needed closed loop ~poose.
The beam profile is very close to a rectangular pulse as it
is run through a beam chopper after the ion source. See
figure 7. To model the beam loading effect, the only
information needed is the start time, stop time, and theamplitude. If the error wavefonn does not change except inIn this system, the processor is not in the feedback loop,
therefore processing time does not create phase shifts andpossible loop instabilities. Feedforward, in the time frame ofa single pulse is an open loop process. · Therefore loop
stability is not an issue as long as the processor gets the job
done in the 66ms before the next cycle.

H. Results
The Low Level RF system has been operated on acomplete system test bed in the Fermilab AO lab. It responds
very closely to the model with few surprises. One area that is
not accurate in the model is the complex interaction of the
Klystron, waveguide and cavity. True beam loading effects
have not been seen as of yet, however, system settling time tol % was measured to be less than 300 ns for a 20% step change
introduced by a test system. The versatility of the system wasdemonstrated when system parameters for tuning were changedon the fly from the parameter page. Problems such as thesaturation of ADC's or DAC's were easy to find by using the

S12FC01
412

Feedback Control

412

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC01

quick plot routines. The LLRF system was operational at AO
in the first week after installation.

V. CONCLUSION
The use of feedforward for the LLRF system allows
flexibility in the design and implementation. Once the system
becomes operational some minor changes in the feedforward
parameters or the algorithm can easily be made.
For the Flying Wire system we hope to generate an
optimal set of parameters with a single command to thesystem. The processor should be able to manipulate themotion control system to determine the actual friction, inertia,
and loading of the entire system as installed . When a failure
occurs that requires component replacement, the system will
be programmed to self tune the loop for the best response.

VI. REFERENCES[1] DiStefano, J. et. al. Feedback and Conrrol Systems,

McGraw-Hill, 1990, or other Control Systems Texts.
(2] Ahmed, I., "Designing Control Systems", Digital Signal
Control Applications with the TMS320, Texas
Instruments, 1991, pp 48-52.
[3] Gannon, J.,et al., "Flying Wires at Fermilab,"
Proceedings of the 1989 IEEE Particle Accelerator
Conference, pp. 68-70, March 20-23, 1989.
[4J Tai, J., Motion Control Applications, Gali! Motion
Control Systems, 1989.
[5] EXTEND copyright by Imagine That, Inc. San Jose, CA,
USA. Details of analysis in Pasquinnclli, R., "Modelingof the Linac Upgrade RF System", Fermilab internalmemo, February 6, 1991.

S12FC01
Feedback Control

413

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-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 Control414

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

SYSTEM OVERVIEW
Control Loop Design

The system is generalized and database-driven. New
feedback loops which behave in a linear fashion are im·
plemented by configuring the database and hardware
but without requiring additional software. Furthermore,
special-purpose capability is provided to handle non-linear
functions such as energy control with phase shifters. The
system is based on the state space formalism of digital
control theory [3]. Vectors of measurements, states andactuator values are manipulated using matrix and vector
arithmetic. Matrices are calculated offiine and stored in a
database for online use. Measurements input to the feedback system are typically Beam Position Monitor (BPM)
readings. The state vector includes calculated quantities
such as beam position, angle or energy which the feedback
loop controls to user-selected setpoints. Actuators which
control the beam are typically analog control devices suchas steering dipole magnets, Klystron amplitude controllers
and phase shifters.
The major software components of the system are shownin Figure 2. Most of the associated software is written in
the C programming language. The SLC database. contains
device specifications, display information and control pa··
rameters associated for all existing feedback loops. Only
the software which runs on the VAX has access to theentire database. The VAX software is responsible for initializing and arbitrating feedback processing in the micros
and handling user requests. There is ;,tn extensive selectionof dispL:cys n.vailable to allow users to monitor and anaiyzc
the feedback behavior in addition to facilitating studies of
the SLC itself. The VAX softv.·~cre uses an object-oriented
architecture. Feedback loops, database-driven
and vector elements are among the types of objects which
are manipulated in a gene re.Ii zed manner ['1].
The micro soft.ware executes all of the real-time control
functions, including taking measurements, performing calculations and implementing new actuator settings. Since
these functions may be distributed across several micros, a
specialized high rate network system, KISNet [.5], has been
adapted from the Advanced Light Source (ALS) projectin order to transfer rneasurem.:nt and actuator data between micro5. The feedback software which runs on the
micros is divided into three functions: measurement, control and actuation. For a single feedback loop there may
be multiple measurement and actuator tasks running on
different micros with each responsible for its own hardware. A single controlkr task for each loop receives all of
the measurement. data, performs calculations, and sends
new settings to the actuator task(s).
The matrices used in the controller calculations are determined by an offiine simulation program [6] which isbased on the Matri.xX package from Integrated Sytems
Incorporated. The matrices are designed to minimize theRMS of the controlled states, provide good response to
step functions, and to maintain stability when the machine
response does not exactly match the model. The design

otflineOnir;el<ISNET
INTER-MICRO
Communications
Network&oo M~asurement
Micros

SLC
Database

Controller

Micro

Caltrol

Prc.gram
VAX 8800
SLCNET

Figure 2: Feedback System Architecture.
involves tradeoffs between quick response and stability under changing beam conditions. The response characteristics may be tuned in the matrix design by adjusting thenoise spectrum expected from the accelerator, although
in the SLC the same setup is typically used for all loops.
The matrices are initialized using the theoretical modelof the accelerator. The model is usually good over shortdistances.
The simulation program has been very useful for predicting stability of the feedback processing and determining the workability of new algorithms. 'Most of the problems encountered in opetation were predicted in advanceby the simulator, and some potential problems were circumvented by the software. This is one of the reasons thatcommissioning the feedb2_ck loops has been a remarkably
smo•Jth and minirnaliy invasive process.

FEEDBACK CALCULATIONS
The feedhuk algorithm can be summarized in two ,,quations which are baso.::d on the predictor-corrector formalismof digi ta! control theory [3]. This algorithm has previously
been described elsewhere [6] in further detail. The firstcontroller equation estimates the values of states which areassociated with the feedback loop, based on the previous
state estimate, currently implemented actuator set tings,
and measurements.
(1\
\.4.i

where

x.c is the estimate of the state vector on the kth pulse.
iii is the system matrix and describes the dynamics of theaccelerator model.

S12FC02
Feedback Control

415
415

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-S12FC02

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

0

E

...

.s

Ol

c

;;
( I)

(j)

..... -1

c 4
~

.9

'(ii

~
.....
.....

0

a..

0
()

E

ms

x -2

c:o

0
11~1

40

80
120
Time (sec)01607041A3

11--914080120Time (sec)

160
704\M

Figure 4: Actuator Control for Step Functions.

Figure 3: Feedback Response to Step Functions.

r is the control input matrix. It describes how changes
in the actuators should affect the state.
u is the actuator vector. It contains the current actuatorsettings with reference values subtracted.
L is the Kalman filter matrix. Given an error on theestimate of the sensor readings, it applies a correction
term to the estimate of the state vector.
y is the measurement vector.

It contains the current
measurements with reference values subtracted.

H is the output matrix. It maps the state vector tothe output vector. That is, given an estimate of thestates, it gives an estimate of what the sensors should
read.
The matrices ii, r, and H are obtained from the modelof the accelerator. The L matrix is derived from the othermatrices and is designed (via the Linear Quadratic Gaussian method) to minimize the RMS error on the estimateof the state.
The second controller equation calculates the actuatorsettings based on the estimated state vector.

(2)
where
K is the gain matrix. It is derived in a manner similar

to L. It is designed to minimize the RMS of selectedstate vector elements.
N is the controller-reference-input matrix. It maps thereference vector to actuator settings and is directly
derivable from the model of the accelerator.
r is the reference vector which contains setpoints for thestates controlled by the loop.

DIAGNOSTIC CAPABILITY
The micros save measurement, state and actuator data
for the last few hundred iterations in a ring buffer; thisdata is available for display upon user request. These ringbuffer displays are one of the most useful diagnostics ofthe system, enabling analysis of perturbations and beamlosses after they have taken place. If the user requests
the display within a minute or so after such an event, theassociated data is usually available. This functionality isalso useful for studies of beam jitter and other phenomena.
Figure 3 shows how a feedback-controlled beam positionchanges with time. Figure 4 shows the associated corrector
values during the same time period. During this period,
two step functions were purposely introduced to perturb
the beam upstream of the feedback loop in order to test
the feedback response; one can see how each perturbation is corrected within several pulses. Typically, the first
pulse after a large perturbation is rejected by the feedback
filtering software as spurious and then the new state estimate is exponentially averaged over several pulses. Newly
calculated settings are usually implemented within one or
two pulses for most types of actuators.
Additional analysis capabilities include Fourier transforms and plots of the ring buffer data. The same data
may be formatted onto disk files which are compatible
with offiine analysis packa,ges. Beam orbit plots are available to graphically display the beam trajectory throughthe range of each feedback loop for comparison with tlie
model-predicted orbit. A history plot ·capability enables
review of feedback control over a period of days, weeks ormonths. Figure 5 shows how a feedback-controlled beam
position differs from its setpoint value over a period offifteen days. The tolerance lines show that for most of
the period shown the feedback loop controlled the beam
successfully.

S12FC02416

Feedback Control
416

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

ICALEPCS1991, Tsukuba, Japan

E

c

·.a
(!)

0.1

······ ~!?.l?.~.~.!cil~:a..~~~ .................. ,....... .

0

CJ)

C:

.Q

.'!:!

Lower Tolerance

-0.1

(/)

0

c..
·0.2

1

11·~1

10

15

Time (days)

7o-41M

5

Figure 5: History Plot of Feedback Control.

TESTING ENVIRON1IENT
ADDITIONAL FEATURES
Many system features have been added to the basic algorithm to handle exceptions, improve robustness and add
flexibility to the system. For example, a gain factor is implemented as a modification to the second controller equation (actuator calculation), allowing online adjustment of
the loop response. The matrices are set up to provide optimal control with a gain factor of 1.0 but it is convenient
to allow operators to modify this in response to various
operational problems.
An additional capability is the handling of "gold orbits"
and loop setpoints. A gold orbit is saved by operators
when the state of the accelerator in the region of a feedback loop is believed to be well-tuned. This results in saving the current measurement values and actuator settings.
The "gold" measurements are used as offsets in the controller equations. In general the feedback loop will try tocontrol the beam to maintain the gold orbit measurements.
The gold orbit values are saved in configuration files which
can be rc:loaded at a 11-.ter time, facilitating easy reproduction of a particular machine configuration. The operators
may wish to tune the machine while the feedback is on bychanging the setpoints which control the associated statevalues. Setpoints may be entered manually, or they may
be assigned to a knob and adjusted by turning the knob.
In order to insure that the feedback system does not
misbehave, a large part of the micro software involves exception handling. In fact only a small part of the micro software is required for implementing the basic control algorithm. The measurement and actuator values arechecked to verify that they are within reasonable limits.
If measurements are out of range, have bad status or are
not received by the controller, the "expected" values areused in the calculation, based upon the previous state estimates. This allows feedback loops which control bothelectron and positron beams to continue controlling one
beam when the other beam is absent. In order to insurethat a single wild pulse does not adversely impact the
feedback response, two types of filtering are implemented.
Firstly, measurements which vary significantly from theprevious pulse are not used unless the value is ·between

In order to test the initial system as well as new developments, a hard\vare-based feedback test system has beendeveloped. The typical test feedback loop has three measurements, two states and two actuators. The hardware
simulator modifies the values of the measurements to respond to changes in the actuators. A function generator
introduces variances in the measurements such as sinewaves or step functions. In addition to facilitating debugging and testing of software features without impacting
operation of the SLC, the simulator enables the study of
feedback response for various system changes.

OPERATIONAL EXPERIENCE
The feedback system was first commissioned in the SLC
in November 1990. Since then seventeen feedback loops
have been implemented, with more planner!. These areshown in Figure 1. At the front end of the machine a
new feedback loop will soon control the intensity of thebeam from the polarized laser gun. Steering loops control
the beam trajectory from the injector into the linac andalso into the damping rings. Additional loops steer thebeams out of the damping rings, down the LINAC andinto the final focus. An energy loop controls the electron
and positron beams into the damping rings. A specialpurpose calculation is used to control the energy of theelectron beam into the positron target. Furthermore, theprototypical systems for energy control at the end of the
LINAC and interaction point collision control are scheduled to be replaced by the generalized software in the near
future. Additional steering and energy loops are planned
for the new Final Focus Test Beam facility.
The numher of feedback loops implemented is muchlarger than originally planned. More loops were added
because of the success of the initial l9ops and the easeof commissioning. The system worked much better than
anticipated. Loops which involve a single micro could be
added just by setting up database entries, without requiring any additional hardware or software. Most feedback
loops were commissioned by turning them on with a small
gain factor, gradually turning up the gain, and monitoring

S12FC02
Feedback Control

417

417

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

that of the two previous pulses. Secondly, an exponential
filtering mechanism is built into the matrices to improvestability .
A calibration function is provided for online measurement of how the beam states change with actuator settings. After the calibration is performed, the user may
compare the resulting matrices with the model values andwith the currently implemented matrices. An option isprovided to implement the new values. This function facilitates diagnosis of how well the feedback loop is performing in addition to improving the feedback responsewhen the mo<lel is imperfect.

0.2
.§.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC02

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 Publishing

the loop response by looking at the feedback displays. Oneof the feedback loops was commissioned "accidentally" byan operator who didn't realize the loop wasn't ready; hejust turned it on and it worked.
Fa.st feedback has become an important pa.rt of the SLC
Control System and is heavily relied upon for stabilizing
the machine. It is now much easier to reproduce a particular machine state after interruptions. Furthermore, operators who were previously occupied with keeping the beams
stable have been freed to work on more subtle aspects ofmachine tuning. Since the system was implemented, theaverage rate of steering knob turns has decreased by afactor of five. The LIN AC is now steered every few days
instead of once a shift. The orbit bumps required to minimize the beam emittance are now stable for weeks insteadof hours. There are fewer machine protection trips because
the scavenger energy feedback keeps the beams centered.
Since the feedback system was implemented, accelerator
performance has been greatly improved and much of thisimprovement is attributable to fast feedback. All of the
major operational goals for the SLC in the last running
period were met or exceeded.

date the transport matrices. The adaption calculations
are based upon the SEquential Regression (SER) algorithm [7], adapted for use in the SLC feedback system [8].
The adaption is an iterative process which has as inputs the calculated states for a feedback loop and thesame states as calculated by an upstream loop. Averaged
over time, the transported upstream states should equal
the downstream states. The adaption process calculates
a transfer matrix which minimizes the difference between
the transported upstream and downstream states. This
process runs on the same micro as the feedback controller
but is implemented as a separate task, allowing the adaption to run more slowly and at a lower priority in order tominimize the CPU impact.
The algorithm is as follows: On each pulse for which thetransport matrix is to be updated the following is calculated:(3)
S Q(k - l)Yc(k)doi:10.18429/JACoW-ICALEPCS1991-S12FC02='Y = a + YcT(k)S
-a

Q(k)

(4)

= ±(Q(k - 1) - ~ssT)(5)

where:"CASCADED" FAST FEEDBACK
One problem encountered in operation was predicted by
the initial simulations and is a result of the large stringof steering loops down the LIN AC. In the current system,
these loops a.re a.II controlling the same para.meters, resulting in overcorrection of upstream perturbations andamplification of beam noise. As a temporary measure, thegain factors of several feedback loops have been decreased,
but this reduces the system's effectiveness.
An enhancement to the feedback system, called "Cascading", is currently under development. It enables a series of fa.st feedback loops to communicate, eliminating
overcorrection problems and allowing the use of optima.I
gain factors. In the new system, each upstream loop sends
its calculated state vector to the adjacent downstream
loop. It is not necessary for an upstream loop to communicate with all loops downstream of it. The downstream
loop controls the difference between state elements calculated from downstream beam position monitors and thetransported values of the associated states calculated by
the upstream feedback loop. This results in each loop correcting only those perturbations not already removed by
the upstream loops.
This coordination between feedback loops depends upona reliable method for mathematically transporting the position and angle at one point to the position and angle
at a downstream location. The model of the accelerator,
based upon a knowledge of the focusing strengths of the
LINAC qua.drupoles, provides a basis for this transport,
but it is believed that the model is not acceptably accurate over the distances involved. Furthermore, the physical transport characteristics may change during operation.
Therefore adaptive methods a.re used to dynamically up-

Yc(k) is the state vector from the upstream loop with
setpoints subtracted.

k is the beam pulse number.
Q is the estimate of the inverse of the covariance matrixof Ye·
S, / are intermediate results.
and

(6)
where
r is the number of pulses for covariance matrix averaging,typically 50.
A large / means the beam fluctuation has suddenly increased, which could cause the transport calculation to beunstable. Therefore the following equations which update
the transport matrix are calculated only if I is less thana cutoff value, typically 20.
e= (raw state vector)- (raw state setpoints)(7)-Tc(k)yc(k)Ti(k + 1) =Ti(k)+
11Q(k)yq(k)c;

(8)

where
T; is the estimate of the i 1h row of the transport matrix
Tc.
1J is the learning rate or gain, typically 0.1 or 0.2.

S12FC02418

Feedback Control418

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

ICALEPCS1991, Tsukuba, JapanThe calculation of T; must be evaluated for all i, that isfor each row of the transport matrix. If there are changes
to the physical model the T and Q matrices converge to
new values within a few minutes.
Simulations indicate that this method will behave reliably and will improve the feedback response. It should
completely eliminate the overcorrection problems previously experienced. The new system is scheduled to beready for commissioning by the end of 1991.

REFERENCES

JACoW Publishing

CONCLUSIONSThe new fast feedback system has been a remarkably successful addition to the SLC Control System. The generalized approach enables easy addition of new loops and expansion of functionality. Commissioning of new loops hascaused relatively little negative operational impact, due to
use of simulation and offiine testing. The database-driven
design and reliance upon existing hardware also helps tominimize commissioning effort. The user interface is easy
for operators to use and provides extensive analysis capability. Most importantly, the system has improved thestability and tuning of the SLC, enabling operational goals
to be met.

[1] G. Abrams et a.!., "Fast Energy and Energy Spectrum Feedback in the SI;C LINAC," SLAC-PUB4183, in Proceedings of the Particle Accelerator Conference, Stanford Linear Accelerator Center, March 1987.
[2] F. Rouse et aL, "Maintaining micron size beams in collision at the Stanford Linear Collider," SLAC-PT;B5512, in Proceedings of the IEEE Particle Accelerator Conference, Stanford Linear Accelerator Center,May 1991.
[3] Gene F. Franklin and J. David Powell, Digital Control
of Dynamic Systems, Addison-Wesley, 1980.
[4] F. Rouse et al., "Design of VAX Software for a generalized feedback system," SLAC-PUB-5511, in Proceedings of the IEEE Particle Accelerator Conference,

Stanford Linear Accelerator Center, May 1991.
[5] K. Krauter and D. Nelson, "SLC's Adaptation of the
ALS High Performance Serial Link," in Proceedingsof the IEEE Particle Accelerator Conference, Stanford
Linear Accelerator Center, May 1991.
[6] T. Himel, L. Hendrickson, F. Rouse and H. Shoaee,"Use of Digital Control Theory State Space Formalism for Feedback at SLC," SLAC-PUB-5470, in Proceedings of the IEEE Particle Accelerator Conference,

ACKNOWLEDGEMENTS
The authors wish to thank J. Zicker and S. Castillo for
their work on the system\Ve also appreciate
the software contributions of P. Grossberg, R. Hall and
L. Patmore.

Stanford Linear Accelerator Center, May 1991.
[7] Bernard Widrow and Samuel D. Stearns, Adaptive Signal Processing, Prentice-Hall, Inc., 1985.
[8] T. Himel, "Requirements and Design Overview for
Adaptive Cascaded Feedback," Internal SLAC document, St~nford Linear Accelerator Center, September 1991.

S12FC02
Feedback Control

419
419

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-S12FC02

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

ICALEPCS1991, Tsukuba, Japant'

MCCVAXSLC VAX(Dev Only)

t

--

-

Ethernet,,~

SLCNet

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC03

t

r

-

Beam Pattern

·~

r

~

--

MPG
Micro

~

Beam Rate Request

~--

'

~

SerialHighway

-- --

SLC
Micro

,

SLC
CAM AC
CratesPIG
Modulett t tt

~

_..

1553
Interface

CAM AC
Dataway~

1553
Inter- 'Iflace'.... ~'To PICs~---

Algorithm
Processor

,,

'

11/

MPS
Supervisor

~

~
,~

LDIM
Module
A!iAAlA

1111111,1;

To Digital Devices

SerialHighway

CA MAC
Data way

- -

~

SLC
Micro

-

-'

SLC
CAM AC
CratesPIC
Module-~ii

tt f tf"

To PICs-'

Algorithm
Processor

-

_,,,

1553
Interface
Two of n SLC Micros areshown. Each micro can have any
number of CAMAC Crates and
MPS Modules connected to it.

~

LDIM
Module,.....

AA AA AJA

1111111
To Digital Devices

Figure 2.

Two of several Algorithm
Processors are shown. APs cancollect data from MPS modules
associated with multiple SLC
Micros limited only by the
number of port addresses andtransmission length of 1553
interface.

MPS computers and network.

S12FC03
Feedback Control

421

421

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

Fast

Slow

Integrator

Integrator

L------+--+
SensorRegisters DAC~ICALEPCS1991, Tsukuba, Japan

Multiplexed
ADC
CAMAC Read

Discriminators

Mll-1553
Read

CA MAC

Write

11-91
7045A3Figure 3.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC03

PIC Electronics.

be implemented in clusters structured around functional elements of the accelerator (Linac, Arcs, Final Focus, etc), or
around subsystems (injector, positron system, etc.) as appropriate. A modular approach allows new systems to be phased
into the overall machine protection system on an incremental
basis.
The architecture is modular and consists of CAMAC sensor cards that condition sensor signals and generate go-nogo
signals to an Array Processor, which scans these signals andpasses on its own summary go-nogo signal to the next level supervisory array processor. The summary process leads to the
MPG (see Fig. 2), which sequences the accelerator.
The system is being implemented first in the positron production system, supporting Protection Ion Chambers (PIC's).
These Ion Chambers use custom CAMAC modules which interface the radiation sensor and implement the severity levelmeasurements driving the go or no-go signal to the Array processor. Limit levels for the various machine repetition rates areloaded into the PIC from the SLC control system, and scale theacceptable radiation at each beam rate with some hysteresis forstability and automatic return to higher beam rates after thefaults are resolved. A facility has been provided via the SLC
control system to recover analog measurements from the PIC's
for comparison or correlation.
These analog data channels originate in fast and slow integrators in the CAMAC electronics (see Fig. 3), which also drive
preset table discriminators that provide the level control signals
monitored by the array processors. The system also provides
facilities for providing secure changes to level setpoints, and deliberate trips on these control signals to confirm the functionality of the full system and the correctness of the protection
system logic.
Future hardware developments will include latched digital
status inputs (LDIM), RTD temperature inputs, and Long ion
chamber (PLIC). These devices will be set by the SLC control
system, and communicate with the array processors via the1553 bus as do the current PIC's.

System control and data connections are implemented using standard hardware and communication protocols. The realtime control connections between the sensors, the array processors, and the MPG are implemented using MIL STD 1553 asa secure, low- overhead, multidrop communication link (withtechnology borrowed from Fermilab and CERN). The separate
Ethernet link, employing TCP /IP, is used for downloading configuration files, and provides the control room message link forpassing the location and nature of any system faults. Both ofthese links are well-characterized standards, which offer flexibility, reliability, and convenience.
Array Processors (AP) are essentially programmable logic
arrays implemented in firmware. These scanners are built from
VME 68030 processors running C code on top of a real-time
executive. These devices scan the various binary sensor inputs,
and evaluate the significance of the signals based on configuration and response tables down-loaded from the VAX via Ethernet. These tables come from a special configuration editor andcompiler resident on the VAX. Special security facilities control
the integrity of the table transfers, and periodically confirm
that no unauthorized or uncommanded changes have occurredin the AP database.
Supervisory Array Processors (SAP) are essentially AP's
which combine the outputs of the AP's in the cluster, signal the
MPG for beam rate control, and monitor the MPG's responses.
This hierarchical model provides for flexibility in grouping MPS
sensors, and provides rapid evaluation response by distributing the scan task. A SAP can interrupt the MPG's pipe-lined
beam control sequence in 2-3 pulses before accelerator damage
can occur. A SAP also has hard-wired access to the injector
interlock system should it be necessary to override the MPG.

SOFTWARE IMPLEMENTATION
A configuration editor has been developed so that devices
can quickly and accurately be added to the configuration files,
using the appropriate boolean operators. This facility provides
for the loading of action set-points, device limit parameter,
normal device status, and accelerator operation configuration.
These files are then compiled into the database for the arrayprocessor. The configuration editor then downloads data to
the AP's via the Ethernet, and provides a change history anda verification facility to insure system integrity. There is a secure copy of an original or "gold" version of the configuration
file which is maintained separately as a global check against all
subsequent modifications.
There is a security facility that records equipment bypass
actions as they are initiated, and requires that they be reauthorized by senior machine operators at the start of every shift.
These listings serve as both a reminder of machine condition
and a log of corrective actions yet to be accomplished.
Self-test software is being developed which allows the VAX
to test the entire MPS network for continuity, as well as forthe correctness of the trip logic. The VAX can initiate trip
signals to any selected sensor module and channel, which will
be acted upon by the array processors. The test demonstrates
a closed loop in the system, and the type of response (limit or shut-down) demonstrates that the logic, limits, and response
severity are as specified in the configuration database.
The communication networks were selected for their convenience and for conformance to accepted industry standards.
The 1553 bus offers a fast, secure, low-overhead, and multidrop channel for communication between signal conditioning
CAMAC cards and the various levels of array processors.

S12FC03422

Feedback Control422

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

ICALEPCS1991, Tsukuba, Japan

Ethernet with TCP /IP was selected for the message anddata links since the messages can be long and there is no requirement for a. real-time deterministic type of facility. Thistied in nicely with the Ethernet remote debugger purchasedwith the development environment.

SOFTWARE DEVELOPMENT ENVIRONMENTThe Control Room User Interface includes facilities tomonitor the performance of the system, a.nd track rate limits,
faults, and recoveries. Touch panels are used for control, and aseries of X-window a<:reens indicate status, faults, and the analysis data from the various applications packages.

The MPS Application Software and array processor
firmware were developed on the SLC VAX cluster. All software and firmware were developed in Ansi C, and commerciallyavailable development tools (such as remote network debuggers, real-time kernel facilities, and standard networks) wereused extensively. The microprocessor firmware was developedin a cross-compilation environment and run on the pSOS kernel(Software Components Group).

S12FC03
Feedback Control

423

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

USER INTERFACE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC03

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, Japanof random fluctuations which causes self-excitation of thehigh power rf field. Frequency of self-excitation is equal tothe eigenfrequency of the AS due to the high quality of theaccelerating cavity ( Q= 10 000 ) .

been based on the measurements and computer analysis of
the system's responses to a step reference signal input.
Control program in the CCS station use both integral andproportional procedures for controlling. System's
parameters has been chosen to minimize settling time andovershoot of a step response to a step reference input. The
temperature of water is stabilized to an accuracy of 0.02°C.
Settling time of a controlling parameter response to a stepreference signal is about 100 s.

of power feeding.
The thennoregulating system (Fig.2) consists of avalve (V) and a voltage controlled thermoelectrical heater(TH) ofa total powerofl 4 kW. The water flow is controlled
by valve V and measured by flowmeter FM. The
temperature of coolant is measured by two termistors T1
and Tz, located at the input and output of the AS. The flow
relay (FR) checks for the presence of coolant flow andsupplies alarm blocking signal. The valve is actuated by aasynchronous motor under computer control . The CCS
checks rating value of coolant flow through optocoupled
ADC connected to FM.

Digital temperature feedback control system.

Analogue resonance frequency feedback
control loop.
The feedback loop of analogue feedback control system ofresonance frequency is closing after rf power has been fed
and external RS excitation has been switched on. At thesame time feedback loop of digital temperature control
system is opening by the order from the CCS. The error
signal for the control system of resonance frequency issupplied by PD:z (Fig.I) which compares the phases of theAS field and incident field. It is correct due to the relation
between phase shift and frequency shift: F= ~~tg(<;D)
where F -frequency shift, Fo- resonance frequency, ({J phase difference, Q - quality of cavity. The presence ofadjusting phase shifter PS3 ensures the ability of the sensor
to operate in a zero-point, quite linear, domain of staticthecharacteristic. The necessary phase shift is set up
respective adjusting phase shifter by an order
the CCS. When two rf signals with amplitudes of As and
Ar are fed to input ports of PD, two low frequency
output signals are expressed as:
2

Vs =

2

- (As +In order to feed and support rf power in AS, it isnecessary to ensure equality between self-excitation
frequency and frequency of the reference signal . The
discrete-time computer control system has been designed
for temperature tracking . Control system consist ofcooling system of the AS, ADC sensors and DAC. It is
possible to model the system in the form of "the secondorder system with transport delay". Identification has

2+Ar + 2AsArcos(tJ>)- 2AsArcos(tJ>))

where <P- is the phase difference between Ar and As.
Input circuits of analogue control systems consist ofoperational amplifier (OA) which is summing up two input
signals Vr and Vs. The resulting signal is proportional tothe cosine of the phase difference .
We have used PI-compensator circuits with optimized
parameters in our system . The object of controlling has
been described as a second order system with a transportdelay. The model transfer function of the system is:Yi( )s =(Tls+l)(T2s+1)

Fig.2 Outline of thermoregulating system ofaccelerating section.

-sTd

The standard parameters of this model
0.067,Tdreal objects and are: Tl• ll.I s ,Tl• 3.6
S.5 s (flow of coolant - 0.41/ s). At this poin1, we have used
the same model and method as for digital temperature
control system to optimize the analogue controller, but
in continuous-time domain. The bandwidth of analogue
regulator has been limited to 40Hz, because noise
fluctuations with higher frequencies of controllingparameter are physically impossible. The analogue
regulator consists of a sensor amplifier, a low pass filter,
and PI-compensator circuits. We increased gain of open
loop. The system remained stable and steady state error
decreased due to a low frequency of an up edge of thesystem's bandwidth. The choice of optimal parameters ofthe model of PI-compensator circuits has been based upon

S12FC04
Feedback Control

425

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

The AS resonance frequency is regulated by varying thetemperature of water coolant. The resonance frequency
decreases due to thermoelastic deformation of the AS andheating of the coolant after the rt power supply system has
been switched on :JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC04

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 Publishingthe desired characteristics of the system: settling time andovershoot of a controlling parameter's step respose.
Optimal parameters of the PI-compensator model are: gain
K-10.0, integrity time Ti-8.0s, proportional coefficient
Kp-1.5. The resonance frequency stability which isprovided by this control system, is +/-2 kHz for all realfluctuations in the system.

thermoheater's thyristors with main frequencies of 50
and 150 Hz. Accuracy of the rf amplitude stabilization of
about 0.1 % of relative error has been achieved. The pinattenuator is controled by current, which is supplied by ananalogue board of the amplitude feedback control system.
Static characteristic of the attenuator is quite linear in
the operating domain. The operating point has beenchosen in the region of 0.5 mA which corresponds to 4
dB of rf attenuation. Internal construction of the
microstrip attenuator resulted in an rf phase shift dependence from the controlling current (Fig.3). This"bad" property caused an internal bond of the amplitude
and the phase feedback control loop, which wasnecessary to take into consideration during the later designof feedback loops.

doi:10.18429/JACoW-ICALEPCS1991-S12FC04

IV. AMPLITUDE FEEDBACK
CONTROL SYSTEM.
In order to ensure the stable rf field in AS, an
amplitude control feedback system h~s been designed.
Accuracy of field tracking must be 10- of relative error.
It was difficult to anticipate all possible sources of noisein the system, so the bandwidth has been chosen up to 50
kHz. We have aspired to make the system responce ina closed loop within 10 mks, which is equal to the fill timeof AS. These early conditions demanded from designers
efforts both in improvement of micros trip pin-attenuatorsand the creation of original analog circuits with fast
operational amplifiers. Furthermore, the electron circuit
solves the problem of nonstop operational checking of some
important parameters of different accelerator systems,
such as the level of the reflected wave, low vacuum,
presence of coolant in AS and the klystrons. Information
about faults is transmitted to the top level of the CCS and
rf inputs of klystrons are closed. Important parameters,on which the safety of the accelerator depends, aremonitored twice with different sensors. One of thefunction of the circuit is to control rf switch, whichcloses the rf feedback loop. Each element in the feedback
loop, from the OA to the voltage controlled attenuator,
has been measured to determine ts time responses andfrequency-dependent characteristics. Both proportional
and integral controls have been used in the feedback
control circuits. A prototype of the system has been tested
assuming a mini-computer controlled testing panel. The
analog model of AS, which consist of OA and RC circuits,
has been used. The step responses have been measured
with a CAMAC fast ADC (50ns freq. of discret). Random
fluctuations of rf amplitude have been measured in realconditions of a working accelerator by using a digitalspectrum analyzer. Measurements have been made inclosed and open loops. The major noise sources are thehigh voltage supplies
ofthe klystrons
andV. PHASE FEEDBACK CONTROL LOOP.
The phase feedback control loop has been designed at thelast stage of complete feedback control system of AS rf
parameters designing. Phase control systems guarantee
stable phase shifts for every AS, depending on AS locationin the linac. PD1 is used as sensor and PS1 is used as acontroller. An analog phase feedback control system has
been created on the basis of the described above analog
systems. Sensor circuits is equal to the sensor circuits of theresonance frequency feedback control loop. Regulating
circuits are equal to the fast circuits of rf amplitude
feedback control loop. The accuracy of the system is about
0.5°.Settling time of a controlling parameter response
depends on the type of phase controller. A varactor phaseshifter provides a settling time of about 10 mks. A ferrite
phase shifter yields 5ms, due to inductance.

VI. CONCLUSION.
The feedback control systems described above were
tested , for the first time, during experiments in thecapture section of RTM linac [2 ]. Circuits and methodsof designing were improved simultaneously. Models of all
systems have been calculated and simulated with the aid oforiginal software. All the systems together with the top
level of CCS have ensured stable, safe and comfortableprocedure for feeding of power and experimenting with AS.

ACKNOWLEDGEMENT.
The authors would like to express their thanks toprofessor B.S. Ishkhanov and doctor V.I. Shvedunov who
provided enormouse help for the successful designing andtesting of the feedback systems.

REFERENCES.
[1] A.S. Chepurnov, I. V. Gribov, S. Yu. Morozov, A. V.
Shumakov and S. V. Zinoviev Moscow University RaceTrack Microtron Control System: Ideas and Development.
These proceedings.

......... Phaso shlt(Dog.) ......,._ AttonuW<>n(dB)

Fig3. Microstrip pin-attenuator performance
characteristic.

[2] A.S. Alimov, V.G. Gevokyan, I. V. Gribov et al. Beam
Acceleration Experiments in the capture section of CW
Race-Track Microtron, Preprint NIIYAF MGU, 8961I138, Moscow, 1989. (in English).

S12FC04426

Feedback Control426

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

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 Publishingaccuracy less than 30 µm, wide dynamic range, long timestability, is under development. There are 9 beam position
monitors(BPM) in each period which totals 108 BPM'saround the 12-period storage ring chamber. Each BPM
consists of four button pickup electrodes and signal processing electronics. We designed two types of processing
electronics. One of 9 BPM's per period is a wide banddetector which has 2M position measurement rate to beable to trace the electron orbit turn by turn in the single bunch operation mode. This novel BPM system canbe used for the machine study and development as well as
for the commissioning of the storage ring. Other BPM's
are narrow band processors tuned to 500M Hz rf frequency
for the accurate measurement and correction of the closed
orbit.
PLS BPM system should satisfy the following requirements. For the closed orbit measurement; 20µm resolution in the whole range of operation, 150µm absolute accuracy including mechanical and thermal errors, life-timeorbit stability within the small fraction of beam size at ID
chamber and the capability of 15H z real-time closed orbit feedback. Wide band detector electronics should haveover 2M position measurement rate for the first single turnmeasurement during the commissioning or turn by turn
position measurement in the single bunch operation. Thissystem should also meet the same operational requirement
for the closed orbit measurement. During the commissioning, however, 500µm accuracy would be enough.

These ferrite bushings damp out various kind of rf resonances as well. Kyocera-SMA feedthrus are welded to
be vacuum tight in pairs to the BPM flanges and connected to the electrodes by means of rf spring contacts. In
this way, the position of the electrodes will not be affectedby the position offset of feedthroughs. The diameter ofan electrode is 9.5mm which is comparable to the bunch
length. The maximum sensitivity in the linear region isabout 10%/mm. Within the lOmm circle, it has shown
good linearity. The short bunch signals are picked up by
four electrodes and delivered to the electronic detector via
coaxial cables. The beam spectrum extends fiat to very
high frequency with the 3dB corner at 9G Hz and has thehigh-pass shoulder at 160M Hz, well below the 500M Hz
working frequency. Signal voltage at 500M Hz is about
22mV[6].

doi:10.18429/JACoW-ICALEPCS1991-S12FC05

Figure 1: Schematic of the PLS Beam Position Monitor
Since the PLS vacuum chamber is machined from thickaluminum plates, and top and bottom plates are welded
together to form the vacuum chamber[5], PLS BPM electrodes are assembled as modular units and mounted on thevacuum chamber with Helicofiex vacuum seals as shown in
Figure 1. This modular electrode units have advantage intesting and calibration of BPM modules before installation. In each BPM modules, two electrodes are tightly positioned with ferrite bushings in precisely machined holes.

Figure 2: PLS BPM Detector Electronics
A schematic block diagram of BPM detector electronics is shown in Figure 2. Narrow band detector will be
used mainly for closed orbit measurement. However thisBPM can also be used as the beam-finding tool during thecommissioning: by watching whether the beam signal is induced or not on a certain pickup electrode, e.g., button A,
we can conclude whether the beam has passed or not. Thiscan also be applied as the first-turn beam position measurement system by four injection beams. By detecting
four button signals alternatively induced by four sequentially injected beams, we can measure the first turn beam
orbit. There are several narrow band detector systems recently developed, e.g., NSLS[7], ALS[8] and ELETTRA[9]BPM systems. PLS BPM electronics consists of four channel rf switch and a single channel detector. Four pickup signals are scanned via a fast four channel switch and detected
in a common processor. After scanning four switches, thefifth clock is used for the detection of the system offset,
which is then subtracted from the electrode signals. To
avoid the transient periods at both the rising and fallingedges of the switching and sampling signal, ADC gate will
be set well within the rf switch-on period. Total scanning
time is about lOOµsec. Fast GaAs rf switch, e.g., SW-254,
has low insertion loss, good linearity up to 33dBm andgood thermal stability; <33 absolute and <0.4% relative
drift in the temperature range of 10"'50°C. To protect
rf switch from the high-power high-frequency components,
SLP-600 low pass filter is used before the input to the rf

S12FC05428

Feedback Control428

switch. Button signal is again filtered by the band pass filter and mixed down to 10.7 MHz with a Vectron C0-233
local oscillator and a SRA-lW mixer. Finally detected signal is digitized by 12bit ADC and interfaced to VMEbus.
A wide band detector will be installed on ea.ch period of
the lattice and used for both the single turn measurement
and the closed orbit measurement. After the first-tum
commissioning, most of the fluorescent screens innstalledon ID chambers will be removed when the insertion devices
are installed. Wide band detectors are then particularly
useful for the trouble-shooting and the recommissionings.
A commercially available hybrid junction device, OmniSpectra Monopulse Comparator Network, will be used as
the signal processor. It outputs difference and sum signals
from four electrode signals. For the fast tum-by-turn measurement, a 1024-byte FIFO is used to store each sum anddifference signals.
With the VMEbus based design of BPM detector boards
we have great flexibility in the beam position measurement
and feedback operation. One of the novel feature is thecapability of broadening the measurement dynamic range
by using digitally controllable attenuator in front of themrxer.

There are several kinds of closed orbit correction
and local beam steering methods: harmonic correction
method,minimization method, the eigenvector method, local bump method, etc[lO]. In the Pohang
Lil::ht Source there are 108 BPM's and 72 horizontal andve;tical corrector magnets as the lumped coil windings.
Slow drift of closed orbit can be corrected very accurately
with these all BPM's and correctors. However real-timecorrection with those many BPM's and correctors are impossible without using extraordinary hardwares dedicatedto the orbit correction system. In the PLS, we want to utilize high-performance PLS computer control system, without
the basic control system structure, for thereal time orbit correction system. Test results show that
only a few number of correction magnets and BPM's can
suppress the closed orbit distortion to about one-tenth byapplying harmonic correction method[ll]. Since the harmonic contents of the orbit distortion is dominant near
the machine tune value, we can damp out orbit distortion
efficiently bysmall number of BP:\f's and correctors.
There are 9 BPM's and 6 H/V corrector magnets in aperiod of PLS
lattice. One section is shown in Figure 3. Two BPM's and a correction magnet in the center of
the achromat will be used for the real time orbit correction
system, and four
correctors and two BPM's at bothsides of the ID chamber will be used for the local beamsteering system. In ELETTRA, much has been progressedin this kind of real-time orbit correction system(12].
Photon beam position monitors on an ID beamline may
also be used a.s the position detector. However, in the firstphase of the PLS construction there will be no insertion
devices.Therefore, only computer control system for the

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC05

ID Chamber

Achromlll: eeom Position Mon1lor: HIV Correction Magnet

Figure 3: PLS BPM and Corrector Magnet Lattice forReal-Time Orbit Correction
local beam
will be provided without photon beam
position monitors. According to the operation mode, thenumber and locations of correction magnets and BPM's
can be flexibly selected.
Slow closed orbit correction program will be run at theconsole computer. Instead, an SCC and 12
MIU's based on the VMEbus and Motorola. 68030 microprocessor are dedicated for the real-time closed orbit correction system. The overall structure of the real-time orbit correction system is shown in Figure 4. In each lattice
period, a BPM/PS MIU is located for the beam position
measurement and correction magnet power supply control.
Each BPM/PS MIU crate is also equipped with Motorola
68030 CPU. SCC and MIU's are connected by Mil-1553B
data communication network.
Each beam position data read by BPM/PS MIU istransferred to sec through the serial data communication
network, Mil-1553B. In the SCC, harmonics of the orbit
distortion are
and correction magnet str·ensi:tr1s
are computed. The correction magnet strengths are thentransferred back to twelve BPM/PS MIU's to set the correction
power supply currents.
Theof the real time feedback system is limitedby time delays in the control system and phase delays inthe magnet power supply, correction magnet and vacuum
chamber. Dominant portion of the time delay in the control system is attributed to the serial data communication time through the Mil-1553B field network andsize matrix computations in the SCC. For the matrLx computation, a VMEbus based DSP board will be used. To
achieve 15H z realtime feedback frequency with two BPM'sand one corrector magnet in each lattice period, total timedelay should enter within 8.33msec for the corrections inboth horizontal and vertical direction. By analyzing timedelays in detail we have got the numbers:- 100 µsec for the beam position reading- 110 µsec for the computations in the MIU- 2400 µsec for the position data transfer from MIU to SCC- 6600 µsec for the matrix multiplications in sec- 1440 µsec for the current data transfer from MIU to SCC-4µsec for the setting of magnet current

S12FC05
Feedback Control

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

429

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

Pos!t1on
Noise

...

-

ICALEPCS1991, Tsukuba, Japanboard for the computations in SCC. Total time delay forthe digital processes in feedback system is significantly reduced with DSP board. With an appropriate phase compensation circuit for the phase delay by the vacuum chamber, we can realize 15H z global orbit correction system for
PLS.
Another sound feature is that the local beam steeringsystem runs in MIU independent of SCC. In this manner, the local beam steering speed depends almost only tovacuum chamber. Higher than 30H z local orbit feedback
speed is expected.

Orb1t
Distortion

Feed1backPower Supply

BPM Detectors

16 bit DIO

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC05

12b!t ADC

VXlbus lnterfece(MIU)
Mil-Std-1553B Network lnterf~ce

JJ

References[1].T.Katsura, Y.Kamiya, K.Haga and T.Mitsuhashi, A
Beam Position Feedback System for Beam Lines at
the Photon Factory, Proc. 1987 IEEE PAC.

Ml1-Std-1553B Network lnterfece
VMEbus SBC(SCC)[2].Conceptual Design Report, PLS, 1990.

DSP[3].Moohyun Yoon and Taeyeon Lee,Closed Orbit Distortion and Correction in a Storage Ring, PLS TR/BD
91-05.

Figure 4: Real-Time Closed Orbit Feedback System
which totals 10.6msec. This amount of time delay 1s
too large for the purposed feedback system. With a DSP
board, computation time in sec can be reduced to below 600µsec giving 4.6msec time delay in real time orbit
control system.
Time delay budget allocated for the corrector magnet
power supply, corrector magnet and vacuum chamber isthen 3.7:lmsec. Converting this into the equivalent phasevalue, we get the phase delay ¢n = 40.3° at the cutoff
frequency 30H z. Since the most phase delay will be taken
by aluminum chamber because of its eddy current effect,
we will try to make the thickness of the correction magnet
chamber as thin as possible. Test result conducted in Advanced Photon Source(APS) shows that with an appropriate phase and amplitude compensation circuit, ph1L5e delay
in power supply + magnet + aluminum vacuum chamber
can be reduced to within 40° at 30H z[13].
Local beam steering for each ID photon beamline is performed by BPM/PS MIU independent of SCC. Time delays for the beam position reading and computation of thecorrection magnet current is less than 500µse c. In thiscase, real-time feedback speed can be extended to the eddy
current limited speed of the vacuum chamber. We expect
higher than 30H z local orbit feedback speed.
IV. Summary and Conclusion

96 narrow band BPM detectors and 12 wide band BPM
detectors are designed for the closed orbit measurement,
real-time orbit correction, commissioning and machinestudies. All the BPM's are designed to be VMEbus compatible and are housed in VXIbus crates to fit the fastcomputer control system.
An SCC and 12 BPM/PS MIU's constitute PLS realtirne orbit correction system. To achieve 15H z realtime feedback speed, we adopted fully programmable DSP[4].S.C.\Von, S.S.Chang, J.Y.IIuang, Jinwon Lee, Jae
W.Lee, et al. Status Report on the PLS Control System Development, presented in this conference.
[5).C.K.Kim, K.II.Gil, W.C.Choi and S.Y.Park, PLS Vacuum Chamber Design, J. Korean Vac. Soc., vol.l,
1991.
[6].J.Y.Huang, M.K.Park, E.R.Kim, S.S.Chang and
S.C.Won, Analysis of the Electrical Signal Induced ona Pickup Electrode in the PLS Beam Position Monitoring System, Proc. 4th Asia Pacific Phys. Conf.
[7] .R.Biscardi and J. W .Bittner, Switched Detector for
Beam Position Monitor, Proc. 1989 IEEE PAC.
[8].J.Hinkson, J.Johnston and LKo, Advanced Light
Source Beam Position Monitor, LBL-25973, 1989.
[9].J.-C.Denard, A.Carnie!, R.Aiello and T.Mona.ci, Beam
Position Monitoring Sy8tem for ELETTRA, Proc.
1989 European Acee!. Conf.
[10].Alan Jackson, Closed Orbit Correction in the SRS
Storage Ring, SRS/NS/76/103.

[11].L.H.Yu, Orbit Stability and Feedback Control in Synchrotron Radiation Rings, Proc. 1989 IEEE PAC. also
see R.J.Nawrocky et al, Automatic Beam Steering in
the NSLS Storage Ring Using Closed Orbit Feedback,Nucl. Inst. Meth. Phys. Res., A266, 164(1990).
(12].D.Bulfone, The Real Time Orbit-Position Feedback
System for the ELETTRA Storage Ring, Nucl. Inst.
Meth. Phys. Res., A293, 292(1990).
[13].Y.Chung, Compensation for the Eddy Current, ANLAPS Note, 1990.

S12FC05
430

Feedback Control
430

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, Japanpositioning units, we can bring the table position to within
the dynamic range of the piezoelectric actuator.
The fine active alignment of five degrees of freedom, X, Y,
Bx, By and 8z is achieved by the feedback of the table
position. We must use a high-speed controller because the fastsampling time and the on-line geometrical calcwation are
required for the high gain feedback control to suppress thevibration disturbance. The adoption of the VME modules as
the controller enables us to use the commercially available
boards and the multi CPU structure. Figure 3 shows aschematic illustration of the control system. For the CPU's,
we use MC68020 with a clock signal of 20 :MHz and obtain asampling time of 2 ms for the fine active alignment.

VAX,EWS,etc

MonitorEthernet
Development
EnvironmentPC

RS-232C

Alignment Controller(a) With the personal computer.

VAX,EWS,ctc

i' r...ai,

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC06

Development Environment
and Monitor

1·-·-·1

Ethernet

JtMJlC!~llUI , ~ -~:,.:
I i ....,...
c--1·

i.!.o~~-·_; 11::··--···········J: ,--·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-

Alignment Controller

I"'~~y=:
:

•

j

!

:

VME bu>'•-·1(b)With the VME module having an Ethernet port.

iFig.4 Possible network configurations.

:.. +.

IV. TESTFig.3 Schematic illustration of the control system.
When we want to connect the control system with a hostcomputer, it is necessary to monitor the data and the status andto change the status by the host computer. We have alreadymade a real-time data monitoring system by using RS-232C
as shown in Fig.3. Ethernet is available via a personal
computer with this monitoring system. Direct communication
between the host computer and this control system with
Ethernet is also possible by using the VME module with an
Ethernet port and the necessary software. Figure 4 shows somepossible network configurations of this VME-based alignment
system.

We have tested the precision of the level positioner. The
test results are described in rms values of 100 trials as shownin table 1. Positions and tilts of the table have been measured
by three laser interferometers in the vertical direction and two
capacitance microsensors in the horizontal direction.
As for the fine alignment, we have tested the control
performance of three degrees of freedom, Y, Bx and &z using
laser interferometers whose resolution is 10 nm. To
investigate the response of the active alignment system tovibration, we have added a white noise with a cutoff frequencyof 3 Hz as disturbance to one of the laser interferometer
feedback data. The noise has caused imaginary random
vibration which simulates the ground motion of Y, Bx and()z. In Fig.5 showing the response in the time domain, we cansee the vibration of amplitude of 1.5 µm peak to peak isdamped to less than 0.2 µm.
Table 1 Precision of the level positioner.
Positioning Accuracy (RMS)x

0.217 µmy0.750 µm

ov
oy

3.00 µradoz

1.29 µrad2.27 µrad

S12FC06432

Feedback Control

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC06

Fig.5 Damping response against the white noise with
3 Hz cutoff frequency.

V. REFERENCES(1] K.Yokoya, Proceedings of the First Workshop on Japan
Linear Collider, KEK, October 1989, pp.26.
[2] N.Ishihara et al., Proceedings of the Second International
Workshop on Accelerator Alignment, DESY, September
1990, pp.453.

S12FC06
Feedback Control

433

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-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

Pattern generation
The pattern aesory devices are designed to generate
the patterns of en accelerating frequency, an accelerating voltage, a ferrite bias current, e bias of beu
position, and en accelerating voltuse correction.
In the co~puter of man-machine interface, date points ofthe patterns are given by the foraula firstly and can becorrected after by the operator. These pattern data aresent to the computer (RF conputer) which control acceleration s¥ste@ direct!~. The date size of one pattern
aust be less than 128k words. For each kind of pattern
there are two mexory units. One menory unit is used tocontrol each device, end the another aeaor• unit is used
to change the pattern data in it. \fith these hrn~e1ories the pattern data can be changed without stop of
the s¥steo. This aake system tuning easy.
To output the pattern data froJ the 1e~ory to thecontrol devices, t10 kinds of pulses are used to change
the pointer address. One is clock pulse of 50 kHz (Tclock) end the another is the pulse of increoent (ordecrement) of the dipole nagnetic field CB-clock). One
pulse of the B+-clock (B--clock) corresponds to 0.2
Gauss increment (decreaent). To generate the patterndata with these clocks, puttern ~ecorles are divided
into follo~ing three regions.
I) region-I
T-clock is used to generate the pattern data,~h!ch determine the pattern in the f let base.
2) region-2
B-clock is used to generate the pattern of theacceleratine period.
3) region-3
T-clock ls used again to generate the pattern inthe flat top.
An event pulse of the bee= capture starts to ndvnnce
the pattern 1esory address of reglon-1 with T-clock. To
start thd beau acceleration, nn event pulse changes the
T-clock to B-clock and jump to the ~emorr address in
reglon-2 1hcre the output frequencr date Is same as thetest data in the aemorf region-I. To stop the bean acceleration in the flat top, an event pulse of the f lut
top changes the meaorJ address to the first address of
the region-3. If there is difference between the last
output data and the data of the head address Jn

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC07

region-3, the output value is aoved to the data of thehead address with one bit step. This function make thechange of the output value smooth end Is inportant not
to loss the bee~.
Bea~::ionitors

The electrostatic pick-up beaa monitors of position(AR) and phase (A¢) have been developed, which aredescribed in the other paperlJ. In the following only
specific features are listed:
1) The developed monitors can be used at the lowest
beam intensitJ of the HIMAC synchrotron (J07ppp),
and the output errors of the A¢ and liRoonitors ure ±3 des. and ±3m: with the Jo~est
beat1 intensit)', respectively. The FJonitor gains
can be selected from OdB to IOOdB ~ith IOdB step.
2) Response of the both 1onitors ere fest enough touse for the feed back loops. The delay times ofD. ¢ and AR aonitors for step function are 7 µ.s
end 20µs, respectively.
Digital control circuit
To control the wide range accelerating frequency
stablt, ~e heve adopted the digital control circuit
which is shown in Fis.2. The AR and A <f; analog sir
nuls are converted tu digital data ever~ 2µ.s iii theleven blts (+sign bit) ADCs which are located near the
rt cavit~ together with the beam monitor electronics.
One bit corresponds to 2.4i;V (0.052i!lil in the fi.R monitor
end 0.087' in the A 9 ilonitor). In the control lliodule,
the fi.R digital data is biased firstly to control thebealli center at optiaulli position. Then the start-stop
function of the feed beck with ti1e constant of about
IOOµs are fol lowed. The .6.R and the A¢ date nre added
after adjustments of a proportional loop gain in the A¢ feed back, and proportional and integral loop gains
in the AR feed back. This su11 data is further added to
the frequency pattern data from the ~e~ory module. The
data of t1>enty bits Is used to drive the DS, and one bitcorresponds to !OHz. Clock frequenc• of IOYHz is used
for the digital processing, and tine delay between
digitizing the analog date (AR and!::,.¢) and driving
the DS with new data is 2µ. s.

~!:.ZAM:;~~:S"-,"'-'-y-...---i:,,.;.--_..;_ __en F.O.
~TC'"!>---Q<>4'-!J.

S.iC4>~.'.;})

Fig.2

Digital control circuit

S12FC07
Feedback Control

435

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

20

x

x x

deg.

To check the effectiveness of the A¢ feed backloop, an open loop transfer function has been calculated. In this calculation response delays of the following parts have been considered.
I) 7 µ s in the A¢ bean aonitor.
2) Jµs and 2µs for the digitizing the analog data
and the digital processing, respectively,3) l.5µs in the DS.
4) I.5µs in the RF cavity.
The calculated result with the critical damping cond ition is shown in Fig.3. From this result the response of
the A¢ feed back is fast enough to damp thesynchrotron oscillation of 4kHz, which is max iaum
frequency in HIMAC synchrotron.

90

XXRC

c

c

0

c

c

0

c

c

c

c

-20

D

-90
*x

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC07

Test of the feed back loop with the simulator circuit

f 8 = 4kHz

dB

ICALEPCS1991, Tsukuba, Japanx-160-40.__....._,_._u.u...__,_.........
....................
10- 1
101
~w....

~

frequency (kHz)Fig . 3 Calculated open loop transfer function of A¢
feed back loop. O;galn, X ;phase .

a)

a)

b)

b)

c)

c)

t

accelera tion

B --rTsta rt s

clock changeIjt
feedback on
Fig.4 Da1ping test of the synchrotron oscillation withA¢ feed back rlth the sl1ulator circuit. The test were
perfor1ed with S¥nchrotron oscillation fr equenc ies of a)
4kHz, b) 6kHz. and c) 7kHz. The Input signal voltage ata first FET a1pllfier ls 41V(p- p) and frf=lMHz.

Fig.5. Outputs of the bea1 monitors. Upper trace is thebeaa intensity, middle trace is AR, and lower trace isA¢ in each picture. Strength of the A¢ feed backlo op is a) cri tical da1ping b) five times of a). Fig. 5c) shows a cor r esponding fi e ld pattern of the dipole
magnet. The acceleration period was 4.46 sec.

S12FC07436

Feedback Control436

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

To test the .6. ¢ feed back loop further, we haveused a new!~ developed simulator which is a circuit togenerated the s¥nchrotron like oscillation. It has thesimilar transfer function as the synchrotron oscillation. The test was performed rlth the condition that
frt=I MHz end f 6 (frequency of the s~nchrotron
oscillation)= 4, 6, and 7kHz. As shown In Fh.4, thefeed back loop could damp the oscillation of 6kHz
quickly. From these results, It is clear that the .6. ¢feed back loop has fast response which is good enoughtor our purpose, because the maximu~ frequency of thesynchrotron oscillation ls 4 kHz.

electrode end the B-clock step of 0.2 Gauss In the HINAC
RF system, it will be possible to accelerate the beam
without large beem loss.
Acknowledgements
We would like to express our gratitude to Dr. Y.lrie,
Dr.S.Ninomiye, end the !embers of the Division of Accelerator Research of NIRS for their support. We also
wish to thunk Dr. T.Keteyama, Mr.T.Watanabe end the 1embers of Accelerator Research Division of INS for theirstrong support ln operation of the TARN-II.

Test of beam acceleration

Reference

Ii there is e large phase jump when the accelerating
frequency ls swept, the accelerated beam 1<ill be lost.
To make sure that there ls no large phase jump in ourOS, we have perfor1ed the beam test. To do the beam test
at TARN-II, 1e have Joined our RF control srstem(computer, th1ing generuter, memory module, digital low
level electronics, digital synthesizer, bee~ mQnitor
electronics) 11th the RF srstem of TARN-l!2J,3J. In thisbeam test, we could not prepare our B-clock generator of
0.2 Gauss clock. Though the B clock of TARN-II is generated every I Gauss increment of the dipole aagnetic
field, this B-clock 1as used In the beam test. To see
the effect of the corresponding frequency step in the
beam acceleration, we huve tried to accelerate the beam
1<ithout the filter which smoothes the step function in
the analog RF control systea of TARN-II. Though there
existed e clear effect of the step function, the bee~
could be accelerated. We have decided to use the I Gauss
clock for our digital control system, which hes no eleaent to smooth the frequency step in this dig!tai sys-I) M.Kanazawu et al., "Beam Monitors for RF Control in
the Synchrotron TARN-I!", Proc. of the 7th Symp. on
Acc. Science and Technology, (1989) 210.
2) K.Sato et e!,"RF Accelerating System for TARN-II",11th Int. Conf. on Cyclotrons and their Application,(1987) 333.
3) T.Katayame et al., "RF Acceleration Srstem for TARN
-ll", Proc. of 7th Sup. on Acc. Science andTechnoloin•, (1989) 80.

teB.

Firstly in the beam test, we have adjusted the position bias in the .6.R feedback loop. If the adjustment
was not correct, the beam was lost when the b.R feedback loop was turned on. The next step was to adjust thestrength of the feedback I oop on b. R and A¢ . As thebeaa intensity was low, the low pass tilter of lkHz
inserted in the AR position monitor. From this fuct thestrength of the AR feedback loop has been set at weakvalue. About the .6. ¢ feedback, the strength of thecritical damping condition was not enough. As sho~n in
Fig.5, the best strength of the /';; ¢ feedback loop was
about five times stronger than the strength of thecritical daaplng condition at the flat base.
Conclusion
have constructed the RF control system with thedied tal synthesizer. The .6. </> feed back loop has beenchecked successfully with the simulator circuit in thefactory. In the be11 test, we could accelerate the He2+
bea1 from IOMeV/u to 160MeV/u. These energies correspondto the acceleration frequencies of I.I MHz and 4.0 MHz,
respectively. The tuning of the control system was very
siaple and easy to succeed in the beam acceleration.
This is the characteristic feature of the digital control system and iaportent in the medical accelerator.
The acceleration eff lclency was about 55%. The possible
reasons of the beam loss are;!) The low beaa intensity which makes large noisein the bees monitors, which Is due to white
noise ln the FET of the first amplifier.
2) The RF noise whose effect was enlarged with the
low beam Intensity.
3) The B-clock step of I Gauss which sakes thelongitudinal bee; emittance growth. (In theanalog system, we can use the filter to smooth
this B-clock step.)

Improving these things with the longer beem monitor

S12FC07
Feedback Control

437
437

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-S12FC07

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC08

narned MVME050A (Motorola, Inc.,
U.S.A.), which has functions or bus(4 line<)arbitration, system reset, system clock
Re11l·Timc
Pttwfr/P-hn~cRFl!totln~generationand serial clock generation.
RF
lko!lng
Conlrol
Control Sv>lcm
Srstem (4 units)
S111tu.i:
C11mputcr
A host computer of the workstation
l nJ<'<llnn ON/OFF
NO! llcofln~
Nm 11 ... 11n~Sun3/140M (Sun Microsystems, Inc ..
j System (14 units) ,Centro! Sntcm
Stntu'U.S.A.) is provided for developing theV1v1E microcomputer programs underL
a Unix operating system, where C
language is available.
Three MC88100 based RISCs
A
l'ccdbm:knamed MVME181 (Motorola, Inc.,
Control
U.S.A.) are equipped in the rack A.
Computer
The 32-bi.t RISC computer, which
ll-1.:nll rs
supports floating arithmetic, operates
l'.f:nll
M
lJCll'·Coll I'S
at 25 MHz along with two 16Cnrrrn!
kilobyte cashe memories named~~-'-'-"1_1o_~c__________I
T-ColllviC88200,
One of those (CPU#l) isA.___c_·u_rr_e_ni_ _ _ _M_ng_n_ct_ir: Scn~rt s;im1lf(
F..!cctro·M•inelk kdedicatedforcollection of the magnetic
l>eleciors
probe signals and coil currents,
llh1~nn•lkS)·!lcm
calculation of the state variables ofplasma current and position, and tileplasma vertical posit.ion control. The
Fig. 1 Dn!fl flow in the JT-60lJ pbsma control systemothers (CPWi2 and CPU#3) executethe fer,.,dback control of plasma current,
The response of the plasma ccntrol system for the JT-60 horizontfil position and the height of X-poit from the divenor
Upgrade must be more than three times faster than that of the plate, and the calculations for the protective interlock of theoriginal system from the vie.,vpoint of the vertical positional coil system.
stability of the plasma. However, it is very difficult to reduce
The rack A is also equipped with a MC68030 based
funhcr the execution tirnc required for tll<:: d~~L.! input/output microcomputer named MVIvfEl"i7 (Motorola, Inc., U.S.A.),and more accurate calculation b".;rnuse the original JT-60 which communicates with the three RISCs through VME bus
plasma control system, where the minicomputers and the and with L'1e host computer through a local area network of
microprocessor were equipped with accuracy of 16 bit and Ethernet. The communication programs are executed under aclocks of 2 to 2.5 YiHz, was designed about ten years ago.
real-time operating system named Vx\Vorks (Wind River
Although adoption of a.'1alog controllers may be one of the System, Inc., U.S.A.).
In the racks B, C and D, analog-to-digirnl converters
methods to satisfy the alxwe requirements from the viewpointof control response, it is hard wurk to keep the controllers ix; (ADCs) and up-down counters (UDCs), which have beenin good condition and it takes much time to develop their newly developed, are provided for digitizing the coil currents
control algoriL'1m for sophisticated control.
and integrating the magnetic probe signals respectively. The
A Vl\ffi bus system has the features that (l) we can utilize ADC has eight input channels and its resolution andthe fastest processor with 32-bit or more accuracy at present, conversion time are 12 bits and 5 µsec respectively. The(2) its system clock (16 MHz) is faster than the CAl\1.AC UDC has four 16-bit up-down counters for the input of thesystem clock (5 Hz at maximum), (3) VlviE bus modules pulse signals with a maximum frequency of 2 lv!Hz frominterfacing with CAJ\.1AC systems are on the market, etc .. voltage to frequency converters. A digital input/output board
Hence, we have decided to replace the 16-bit minicomputer and named ivfVME340A (Motorola, Inc., U.S.A.) is equipped in
microprocessor based system with a VJ\.ffi multi-processor order that event signals from the plant and plasma cansystem where 32-bit reduced instruction set computers interrupt the computers and that the computers can put out(RISCs) of MC88100 and 32-bit microcomputers MC68030 interlock signals LO the actuators. A digital-to-analog
arc adopted for the plasma f~dback control and magnet coil converter named DT1403-4 (Data Translation, Inc., U.S.A.) iscurrent control respectively.
used for feeding the plasma current to the DOC.
As shown in Fig. 2, the VME multi-processor system is
A CA.MAC crate is provided for transferring data between
composed of 4 V1'.1E racks, which are connected with each the RISCs in the VME system and its supervisory control
other through 6 bus repeater/expanders (PT-VYIE902A-l, computers and betwe.::n the RISCs and the DOCs. The VI>1E
Perfonnance Technologies, Inc., U.S.A.). One of the racks is system is connected through a CAMAC branch driver narned
dedicated for microcomputers and the others for I/Os. The first CBD82 J 0 (Creative Electronic Systems, Switzerland), a
slot in the rack A is occupied by a system controller
branch highway and a type A2 crate controller (CCA.2,
G•I< Vollnj!cGa• lnjttlor
Control Sv•tem

Gu lnjeclnr

r

j

s

i

S12FC08
Feedback Control

439
439

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-S12FC08

1>i..1.:Ji,u1ic Ci.u.i1ru1
f-l~ffAitl..

:lluU Cuu.Jol'Ulcr.
Cuu.pwlcr
II~ Cum1-u1tcr
WwUt.11lkNI .......................... ................... Wurli.M.uliun
Scr~I'

Agll~hinyi::.'::;'fiJMU.11 Signilf

C
CA

:.
VMI::
1<•"1< A

Un1m;b Ui1:bwa7z

GctcMIJll.luk'
C:i«~.'l'u IJllC:

25ll/SOOµ.
...................................
.

cp

s
y
s

u

c

I

c

c c u u

u

u

u

3

0

I'
l

• 2

II
II
#
J

A

A

I>

l)

l)

c

c

I' R

I'

II
II

I

VMI::
R•ck U~

MVM£1~7(MC680JO)

Cl'll#l'#J: lllSC Cl'U
MVM£11!l(MCl!!llOOJ
SYS: Sy>klll Cuntrull<r
UllHl,U6: VMU Uw
Hcpcutcr
CUil: C..:1\MAC
llruuch Uril·cr
Cl'<l : Cluck l'ulst

Gcncr:atur
UIH: : ll11·lluw11 CounterUr.u<bll~hWilJ

UAC: lligitul·lu·AnulugCun)'t:rler/lllC : /lnulug·lu·Uigitul

In rruptiunc l) c• l)ll cA Gp

B
R

Cl'UUO: Micr0<:muputcr

C.:un)'crtcr

I()

UI() : lligitul luput
Jligilal Output
llO : lligilul Output
Fl~I : Fun In Muduk

VMI::
l<.ck

Tr-tG: TimiHl: (jcm:rt.ilurc

ACU: Aitxiliury
Cuntrullcr with U-l'urt>-+-+-+-4--l--f-..+-_.µu;u:·•uctK Sc11wr/\CU : Au<iliury
Cuntrullcr wilh Un.melt
Highway Purl

Sii:u:.ibl"'l....i..,.-rr...L.n-'-n....l.rr'-rr'-r-M,.....,-rU....,,.....
U,.., J'ru1x:s 1c•
Vhtl::
l<uck UU D

C C""":·kb
u;..u••K:l<L
flux

luuv:lkh

C.:C.:1\2: Type 112 <.:rat<
fbyrhti:r Firing, Au&I~·~

Cuutrullcr

Fig. 2 V:ME multi-processor system for the IT-60U plasma control system

Standard Engineering Corp., U.S.A.). All the CAMAC
system parameters such as addresses, functions and data word
length are mapped on the V:ME address field in the branch
driver, which also has a multi crate addressing capability. The
branch driver is, hence, suitable for fast and large amount ofdata transfer in the plasma control.
The CAMAC crate is equipped with an auxiliary controller
with D-port (ACD, Kokusai Electric Co., Ltd., Japan), which
is provided for transferring the discharge result data from the
VME system to the discharge control computer. The control
commands are directly transferred to the DDCs throughauxiliary controllers with branch highway port (ACB, Kokusai
Electric Co., Ltd., Japan). Many timing modules are also
installed in the CAMAC crate for generating, receiving,transmitting and masking clock pulses and trigger signals.

3. SYS1EM CHARACTERISTICS
3. 1 Pipeline processing
Figure 3 shows the plasma control time chart of the
VME system including the DDC control system. The VME
multi-processor system for the IT-60U control is a pipe-lined
system with two kinds of sampling clock of 250 µsec and 500µsec. The former is for the control of the plasma vertical
position and the latter for the control of the other parameters.

The CPU#l first collects the data from the magnetic
sensors and the magnet coil power supply shown in Table 1
with a sampling period of 250 µsec. The time required for thedata collection is less than 50 µsec. The CPU#l, then,calculates the plasma state variables with the signals frommagnetic probes and flux loops. The CPU#l also executes
the calculation for the plasma vertical control and transfers thecalculated command of the current or voltage to the DDC in
the horizontal field coil power supply (H-DDC) with a cycleof 250 µsec. The time required for the above execution is lessthan 250 µsec.
The CPU#2 and the CPU#3 execute the calculation for thecontrol of the other parameters such as the plasma current, thehorizontal position and the X-point position and the interlock
calculation for protecting the magnet coils and the first wallcomponents, following which they transfer their control
commands to the DDCs except the H-DDC .every 500 µsec.
The time required for the execution in these CPUs is less thanabout 300 µsec. Since the DDCs execute their control
calculations in 250-500 µsec, the delay in the plasma control
system for the vertical position control is less than 500 µsec
and the delay for the other parameter control is less than 800µsec. The plasma vertical position control loop including themagnet power supply and the magnetic measurement system,
hence, has a sampling period of 250 µsec and a delay of about
2 msec in total.

S12FC08440

Feedback Control

440

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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC08~~--....,.~C.~l~ru~~-1ioo--r--~F~~--..---..~--,.;-~~c-·:-k1.!-~-h-·w..,...,~,~"'Jl---.-~-.-~~-~-w Sai.t.:otHrwd
Oo.np:ut S:~~
Input
of Stsu
Cu.ruroi 01.11p-ul .:~~'--~-'-'-l'-ara~-_...ltn,;.;..;.•C-•l<v;.;;.,;.l>~l~~l..___..._~•+~~~P-•_n_.,,,,._.,.._.._~C.•'-b_·i._1_;.,,,_._~~--~w~•·( lp,ll!\pn,,Xp
Ul.Cclll:

VMtCPUfl(~)

v~u:crun(Sl)Oµ>e<)

Fig. 4 JT-60U plasma shape andthe controlled parameters

Fig. 3 Control time chan of the VlvfE multi-processor system

3. 2 Plasma Control Perfomwnce
Figure 4 shows the shape of the JT-6DU plasma alongwith its comrolled parameters, Le. the plasma current (Ip), theplasma horizontal position (.0.Rp), the plasma vertical
position (~p), and the divertcr X-point position (Xp). In theinitial operation of the JT-60U, the feedback control systemwell controls these p:lrameters by PD (proportional anddifferential) control with malrix g::iin and stable divl'.rtOr
plasmas with pl2.sma cuITent of 5MA have been obtained. As
an example of the control performance, che step response of
the vertical position LlZp is shown in Figure 5.
Theamplitude of the fluctuation is less than 5 mm and the settling
time is Jess than 10 msec short, though we observe them•crshoot which may not give bad influence on plasma5.
4. SUMMARYThe V:M:E multi-processor system, where three RISC
computers are adopted, have b->...en newly developed for the JT60 plasma control. The new system makes it possible toexecute more accurntc and faster control of the plasma positionand shape. In the initial JT-60U experiments performed fromthe last Aprii through October, stable divertor plasmas withthe current of 5 MA have been obtained with this control
system.

5.lJ HUil

L..~~-'--::'..,..-~. ....._-'-:-:~~~-:'-:--....4.-'-~~"
If iiJJ

Fig. 5 Step Response of the Plasma Vertical Positionin the Feedbacl: Control

ACKNOWLEDGE:tvffiNTS
The authors wish to lhank the other members of Divisionof JT-60 Facility I at JAERI for their collaboration in thedevelopment of this plasma control system.

REFERENCES[l] T. Kimura, et al., "VME Multi-processor System for PlasmaControl at the IT-60 Upgrade," IEEE Trans. on Nuclear
Science, vol.35, 1989, pp.1554-1558[2] M. Matukawa., et sl., "JT-60U System Design," in Proceedingsof the 15th Symposium on Fusion Technology, Utrecht,
1988.

S12FC08
Feedback Control

441
441

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

VMECl'UH!

ICALEPCS1991, Tsukuba, Japan

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 Control442

discharge, (2) managing the time-sequence and (3) collecting
and transferring data of coils' currents and voltages to the
ZENKEI after the discharge. Functions of real-time processing
are taldng in instructions of a feedback control computer IIb ofthe ZEiW..EI and in currents and voltages of coils which aremeasured by direct current current transfonners (DCCT) andvoltage dividers (VD), calculating minimum time responsecontrol and non-interactive control algorithms and giving out
the Ee value to the PHC every 0.25, 0.5 and 1 ms as shownin Fig.1.

B. Original and old DDC system
The original DDC system consists of five CAJ\1AC crates
correspond to five converters of PFPS and one crate forcollecting data. Each crate has many modules as shown in
Fig. 2. Functions of the modules are as follows. An ACM
module with a 5 MHz i8086 microprocessor is mostimportant module and performs almost all control of the
DOC. An ACB module is communication crate between the
ZENKE! rind the DDC CAMAC by branch highway (BH). An
IN'ffi mo<lule is taking in the timing clock and the interacting
events. j\1any AI modules are taking in coil-currents andvoltages, DO modules are giving the instructions of start/stopof operation, on/off of bypJSs pair(BP.P) operation2 and Ee
values cclculated to PHC.
Purposes of adopting the DDC in PFPS are not only fast
processin6, but also having the flexibility in the control.
However, the programmings written by assembler language
were very complicated and were very hard to change. Because
the 16-bit microprc.'Cessor was very primitive in 1984 and it
h:id to execute many processing during lms. In order to solve
the problems, a developing a new system was tryed. In thesystem a mini-computer ECLIPSE-MY was used instead of
the ACM and Ada was used as the language. The system could
operate preliminarily, but it was special and expensive.

1--·

I
I
I
I

Timir>Q
SystemINTR
Ai
DI

CootrolCcm;;<1ftf( ib lL. __,ZENKE!

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S12FC09

III. NEW DDC SYSTEM
A. Objectives and configurations of new system
In JT-60U, plasma current increases to 6 MA and plasmas
have large volume of 100 m3 with vertically elongation3. Inorder to suppress intrinsic vertical instabilities of elongatedplasmas, there needs faster processing and more flexible control
in DOC to change the control algorithms easily and to protect
over-currents of coil-power-supply systems4. The target ofprocessing time is under 0.5 ms and is hopeful under 0.25
ms5. The flexibility of the control is as follows; (1) switching
operation modes from circulating current mode to non circulating current mode, (2) changing control method from coils'
current feedback control (ACR) to coils' voltage control (VR),(3) starting and stopping thyristor converters with many
patterns such as gate-shifting, BPP and so on. For these
purposes old DOC microcomputers and their softwares were
too old in h3.rdware and too complicated in software.
In order to fulfill above-mentioned requirements, a new
DDC system had to be made, and the configurations of thesystem are as follows.
it has lr'..en adopted to a newest
and fastest microcomputer to write programs used by highleve1 language C and to execute the floating calcul:ition,
because the programmings and maintenance of the system will
be easy. Second, the system has been made under the envibecause the uNIX has been ready forronment of
debugging, editing, using many application programs :md so
on very strongly. Third, the network had to be adopted to I.he
standard communication software, because there need noprograms of communicntion. Finally, we divided the functions
possessed original microcomputer i8086 in the on~Uneprocessing and the real-tiine processing. Because we want toprogram under the environment of useful and strong
operational system(OS) which is equipped with a work
station(WS). The WS, however, is very hard to process thereal-time processing very fast, so this processing is executedby the microcomputer under an adequate OS.

B. Hardwares
An architecture of DDC systerri developed and made for
the JT-60U is shown in Fig. 3. The main components of thesystem are a host computer AS3260 (Toshiba Corp.) , five
microcomputers MVME 147 (Motorola Inc.) and five
CAMAC crates correspond to five conveners of the PFPS.
The AS3260 which is the same specifications of WS Sun
3/60 is connected with a cthemet cable of the ZENKE! by a 8channel transceiver and a bridge, and also connected with aethernet.cab!e of MVE crates by two 8-channel transceivers,
two optical remote repeaters and two splice boxes through a
optical fiber. The microcomputers which consist of a 32-bit,
20 MHz microprocessor MC 68030 and a floating point
coprocessor MC 68882 on the MVEbus are mounted onchassis possessed V~fE backplans and power supply. The
chassis encloses a CA.MAC branch drivers CBD 8210

DO
F~~

ICALEPCS1991, Tsukuba, Japan

BUFF

ACM
(180861ACB~
DOC CAMAC
CRATE

Figure 2. Schematic diagram of original CAMAC carte of
DOC system in PFPSS12FC09
Feedback Control

443

443

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-S12FC09,------------,

lI "ZENKEI"l

Host ComputerI

lL.____
Host Computer____ Jl

AS 3260

D D A A CAMAC
I

0 C 2

B

crote

PS F

Figure 3. Architecture of new DOC system of poloidal field coil power supply(Creative Electronic Systems) which connects the VME crate
und a A.2 module of the CAMAC crate by the brunch highway
und a 1/0 transition module MV"M'.E 712M. Except the ACM
module, the CAi\iAC crate is quite same as the originalarchitecture explained as the former section, namely it consistsof a ACB module which is connected the ZENKE! Ilb by BH
and DO, DI, AI and INTR modules which are connected a
PHC, DCCTs and so on. The system has still anotherhardwares such a V11E crate for collecting data and a WS
AS3160 and a CAMAC crate for testing the system

C. Softwares

Microcomputers whose OS ar:e VxWorks (Wind River
Systems, Inc.) carry out real-time processing. The main
programs written by C language are' a real-time processingtask, an interrupt processing task and a communication task.
The communication task performs watching and executing of
the command to the CAMAC and the referencing/changing
memories of CPU instructed from the host computer by
TCP/IP protocol. The real-time processing task is set by themain task of the CPU, and then it begin to execute the realtime processing at the time of LAM (look at me) interrupting
signal from CBD. The sequence of the real-time processing is
as follows: it catches the LAM signal from the ADC of the
CAMAC, then it takes in currents and voltages of coils,

An organization of the DDC software is shown in Fig.4.
The host computer whose OS is UNIX performs on-line
processing described in section II.A. The main programs are
an on-line processing task, a ZENKE! communication task
and a microcomputer communication task. The configurationof the ZENKE! communication task are as follows: (1) theprocessing execute each power supply separately, (2) thecommunication protocol is TCP/IP, (3) the connection
between the ZENKEI and the AS3260 is set by actively and(4) the client is the ZENK.EI IIb and the server is the AS3260.
Second, the configuration .of the microcomputercommunication task are nearly the same as that of the
ZENKE! communication task only except that the client isAS3260 and the server is each microcomputer. Finally, theon-line processing task performs as follows: (I) setting the
DDC system under conditions of the discharge such asreasonable check of the power supply circuit and of constantsvalues of many control tables and diagnosis of the crates and
PHC before the discharge instructed by the ZENKEI and thenanswering back, (2) collecting and trans-ferring data of coils'
currents and voltages to the ZENKE I.

...,.....------,I AS 3260
ON- LINE
PROCESSINGCOMMUNJCATIONPROGRAM

TCP/JP

Figure 4. Organization of new DDC software

S12FC09444

Feedback Control444

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingcalculates the control-algorithms and gives out the Ee value tothe PHC every 0.25, 0.5 and 1 ms. Finally, the interrupt
routine works from the interrupting signal of the CBD. The
routine perfonns reS-<cis of ti1•; PHC by the BPP-command nndof !.he Ee vu!ues of the PHC at the repair of thyristors, and it
do also start-preet~sing of the rccl-time processing.

the vertical instability of plasmas, and the results showed thatthe oscillation amplitude of the vertical instabilities decrease
from 4.5 cm to 3.2 cm as changing the clock time from l ms
to 0.25 ms, rcsp~tively 5.

IV. TESTS .A.ND RESULTS
I~·Je-:~v !)DC systen1 ha5 been m3de anrl tcstt:r.t J.\. precessing
time which is measured from input of data to output of Ee
calculated is si10wn in Table 1.

PSF

PSV

V/ith (~.{~
328
Without C.C 258

304

335

261

294

267

267

237

238

PSH

PSQ

PSM

350

27B

264

230

299
_,,.,
?".!"".

185

_

190

c

u

/,_CR: Auto Current Regulationl~.cgu lc1tion
C.C:
1,,u."'"''"lS Cum::nt
Table 1.
(. "~,achieving the target that thetirne is und~:r 0.5 m~:.
tirne of 216 tis in
C.C mockcn:tlll1smg ili,:; ck:ck: timethe m1cr1JC{Jm1pu:ter :tviC 68030
from 20 MHz to 32 MHz s.

5 shews waveforms of currents onof PSHpower m.rpply. An upper wnveform is a current of plus
a middle one is a minus one and a lower one is a:mJ mi.nus ,:.1in:•:nts. A I :-1 c:U·:.n
PSH1 OI>f:i PSH2 power
which deliver plus andminus current,
11
which is a half ofAt ltk: current
current, PSHl stops and5.
\V:n',:;forms

currents controlled

new DDC system

V. CONCLUSIONS
W<; hc1v1;. indified ;Jircr.;[
control (DDC) system of
converters in JT-60 poloicl11 powertopnx:css quickly and to have the flexibility in the control.
Results ofshowed that these modifications h::lve

PSH2 works. The const:mt current of 12 Jr.A is continued
1.5 S£;",cond, and then it decreases. At 0 point of 4.4 kA

1.vhich is 20% of thecurrent, PSHl works again, andthen tlH; roil CUIT•Jnt switches from minus 10 plus. At the endof thePSHl and PSH2 are to termin:ot<:~ in gate-in hwerter
for reducing
the coil Clh-rent quickly, and the results are very satisfactory.
In orcier to achieve this operation, some new aigorithms andWe would like to thank 1vfr. K. Ujiie for his helpful
discussions as DDC. \Ve also wish to ti'lank our colleagues of
JT-60 Power Supply Group for help with these works.

computer simulations we.re perfonncd.
~rhe ne~~v l)DC syst,;:;ni has been n1ad~-~ 1;:.;sted and ""·'"~'''""

T<.EFEREl'TCES

on five coil-currents' power supplies, and the results showedvery smoothly about the very
that the system
sophisticated control such as switching operation modes,changing control method from ACR to VR and stnrting andstopping of BPP of thyristor e>:)nverters during the real-time
control. ivforeovcr, the new system was applied to controlling

1. L Kondo al., Fu.~ionand design 5 (1987) 69
2. R.Shimada et al., ibid.
3. H.Ninomiya et al., Plasma Devices and Or;-erntions, 1(1990)·i3
4. Y. Matsuzar,,i et cl., Pree. of 16th SOFT (1990) 1482
5. M.Ta.kaha.<;hi ct aL, L'lls conference

S12FC09
Feedback Control

445

445

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-S12FC09

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 Workstations446

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

ICALEPCS1991, Tsukuba, Japan

provide yet full benefit of DEC's special hardware such as BI

communicate with the process computers from theworkstations.
The ~uipment interface in the CERN-PS complex is awell-defined, strict syntax interface. The arguments of themain procedures are: equipment identifier, "property" (selector
inside a fixed set), event condition (CERN-PS timing) arid
data. Tne data is constrained to simple tyye.s (char, int, double,etc.) and to one dimension only. There is also a very limiteds,::t of procedures,
Ml the ex:iuipment definition (name, class, host computer,numlx~r, description, etc.) is maintained in a central data-base.
These two aspects have many advantages for integrating
equipment access into any environment: small number ofprocedures and simple argument types ma.ke it easy, even in acommercial tool like a spreadsheet. In addition, once all thedifferent communication channels are supported, any
equipment clefirmd in the data-base is accessible, without
explicit knowledge of !he network topology.
The equipment interface in the workstations is a loc::~ldispatcher to I.he equipment interface in the process computers.
It provides network abstre.ction: the equipment identifiers haveno correlation with their physical implementation (network,
host. .. ). This is maml:!tory in order w t:e ablr: lO move
01-iuipment from old computers to new one without interferingmuch with the applications,
An additional softwareisgeneric
applications which need to operate on a wide range ofequipment types without integrating equipment-specific code.
For e;;:imple, how VJ displ::iy the status of a power supply or
ho\v to conuol it} need not to be re-defined in c~·1ch
application. All specific cbta and code rebtcd to the different
equipment class, like labels, com.ml words or transition
functions are maintaine<l in this library layer.

B. System Software
The base system software is the common Ultrix
distribution: UWX programming environment, TCP/IP, NFS,
etc. with minimal additions from public-domain orcommercial sources. To remain vendor-independent, we try tofollow the evolution of industD; standards a'i close as possible,
111
espccblly OSF 1's products. We ruwe replnced DEC-winc!ows
with Motif since 1989. We did not anticipate 1.he distributionof the OSF/lm operating system nor of DCE™ (Distributed
Computing Environment), but we will use the vendor's
versions.
The basic programming environment on our platforms
consists of a C progrnmming environment, composed of theUNIX tools (compiler, debugger, l'vllikc, SCCS ... ) with thec.ddition of GNU Emacs2 and of interactive tools, like DECFuse™.

C. Dal.a basethe first major additional component to thebase system softwnre is a data management system. We are
a commercial relational data-base: Oracle™ which is !hestandard database in use at CERN. Most of the conlrol systemdata is manag1;<l through it equipment definition, ai::nm codes
c'r computer definitions, for instance.
A client interface is ::rvailublc on every syswm, Forms ;.me\
SQL are use<l for the various software exploii.ation ta.sks:
software module
equipment
etc, Programs
manipulating complex or archivable
like the beam's
cycles editor and the error servers use a central cbt1-base via

cmbcddt;<l SQL.
J\ tlcdic3ted serv0r i.s providing "on-line" Orncle service fur

E. User lnterftu:ethe two acceler:1tor divisions. In addition, critical and rc<idonly data which require efficient access, like equipment
description, are distributed from Or'.lc!e into dbm3 data-baseson the different sub-networks.

The last major part of base environment is the userintcrfac:c.
This part is mainly composed of the Motif tools:
interaction objects ("widgets") like buttons, menus or dialog
windows, gener:.11 libraries and a user-interface definition
bnguagc (UlL). fvfotif is 2n aclditional byer on top of Xwindow and we u-y to ensure that prograrnmers need only use
I.his upp.;r(i.e. minimal use of X-lib).
The basic widget set in the Motif distribution address mostof the user-interaction issues. However, it does not provide
many tools for data presentation nor for complex parameter
control. These two parts requires progrrrmming ut a lower
levels: X-window (Xlib) or toolkits "intrinsics".
One solution in avoiding the duplication of such functions
by different programmers is to add widgets for unsupporte-dfunctions. Adding library functions like graphs in the fonn ofadditional widgets has the benefit of providing a uniform final
programming environmenL As no widgets were available as acommon well-accepted solution, we developed our own
widgets for these functions.

Interface
The next building block is communication with the
hardware. An equipment acc~s interface is available onprocess computers: old ones
Data® and PDPl 1®) andnew ones (DSC). Remote procedure calls (RPC) are used to

IosF : Open Softv<are Foundation
is a trademark of Digital Equipment
Corporation™ OSF/l and DCE are trademarks of the Open Software
Foundation.
Emacs is a programming oriented editor from the Free
Software Foundation.
TM DEC Fuse is a trademark of Digital Equipment Corporation
3dbm is a simple data-base system in UNIX
•M DEC windows

2Gr-ruS13MMI01
Man-Machine Interface and Workstations

447

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

and DSSI.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

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

We provide programmers with widgets for data
presentation: alpha-numeric or graphics which also support
some major features in our environment like high refresh rate
without blinking or variable parameter types.
We also provide a single widget for parameter control withdedicated functionalities like familiar interface (compared toprevious hardware devices) or multiple input modes (mouse,arrow keys, numeric key-pad ..).

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

.~..

-T\

..!. U.:::. -· .Q.. --y-·u.9..° .Q. .Q.. .!,o .Q.. - e .... _
;;0

I

-

rr. ;:_

-

"-

-

"'

Pl

-

--

-

""~

, _ _ llllJU

..

.....
... ..
"..
..
...

..

...

Figure 1. Motif application using home-made widgets
The development of widgets is a rather costly process
which requires some proficient programmers but developing
these functions as widgets has simplified greatly most of our
Motif applications.
For end-users, the Motif programming environment is avery complete environment but requires some specifictraining. Courses have been organized and a support activity
has been provided.
We are now introducing interactive editors for producing
user-interface definition in a Motif-standard format: UIL or C.
Such tools are available from various sources, like DEC or
Siemens. If strictly based on Motif, without any specific datastructure, library or language, they have limited prototyping
facilities but produce tool-independent applications.The major
work in integrating these tools in our environment is toinclude our "user-defined" widgets which is an extra cost to
their development.
III. GENERIC APPUCATIONSGeneric applications are programs which are not bound to a
specific operation nor to a specific piece of equipment The
two main categories are general console utilities andequipment oriented applications.

Figure 2. Generic applications

A. Application management
A console utility is required for handling the different
functions available when the user logs in: program
presentation, global condition selection and general facilities
control (alarms and errors).
\.
Some window management is also required in addition to
the functions which are already available via the Motif window
manager. The initial position and size of the windows need tobe managed in order to distribute the application windows on
the screen properly. The windows of the different programs
which belong to the same operation context (same accelerator,
same condition) also need to be handled as a set: common
identifiers
in
the
title
bar
and
globaliconification/raising/destruction. In addition, starting anapplication, bringing its window to front or "de-iconifying" it
are connected to a unique interaction element
One major issue in this area is window overlapping. In ourcontext, the set of concurrent application which an operator
will activate is not well defined; it is then difficult to define a
fixed layout. Therefore, screen zones are defined mainly
through program types. For example: control panels should
appear in the bottom left comer of the screen, while equipment
tables are on the right partB. Parameter tables

The first equipment-oriented generic application is a

dedicated application for displaying operational parameters in atabular format
Each piece of equipment (power-supply, timing, etc.)
belonging to a user-defined "working set" is presented alongwith a list of equipment-related values like status,
controVacquisition value, unit and a color indication. The tool
can be set to refresh the data every machine cycle if necessary(1.2 s).

S13MMI01
448

Man-Machine Interface and Workstations

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

ICALEPCS1991, Tsukuba, JapanThe functions of this tool are multiple: to present the listof equipment, to support the selection by the user of aparticular piece of equipment, to provide an interface forsimple commands (On, Off ... ) and to activate control panels
on request

activated from the same operation context appear in the same
main window (i.e. "shell window"). The exact layout of thecontrol panels depends on the type of the equipment; however,parameters are usually presented in a similar way : name,buttons for discrete commands, display of the status, a"whcelswitch" widget for controlling the continuous
parameter, the display of the parameter acquisition, etc.
We are modifying the tool in order to be completely datadriven : we do not want to have to extend the tool for eachnew type of equipment Therefore, all the data and code which
are ne;;essary for the user-interface are moved lo the cquipmentinterface library.

Another implementation of the same kind offunctionalities are synoptics presentations of a part of themachine.
Synoptics present the major and critical control element ofthat part of the machine and indicate their status by means of
the color. They also present the position of some beam
monitors. Like parameter tables, they include selection,
simple commands and control panel activation.
These displays provide less detail than tables (no current
values) but in a more synthetic way. They are used mainly forbeam-transfer sections and not yet for circular parts.
The major problem for their implementation is thatsynoptics require user-interface information, which is not partof the equipment description available in the control systemdat.~1-base. In our context, two types of information were notregistered in data-base: the topological infomiation which isused for positioning the icons and u'le type of physical clement
which is necessary for selecting the icon to display.
We opted for a data-driven solution : topologicalinforrnation and equipment specifications are entered in asynoptic-sp;.:cific file. Another synoptic applic.::ition realized forthe control of the Proton Linac [5] includes :.i. graphic
interactive editor for entering this information.
Interactive editing, based on home-made tools or oncommercial ones (data-presentationor user-interface
editors), provides the end-user with a complete solution forbuilding the synoptics themselves. Otherwise, one more
maintainable solution is to exploit central data-baseinformation shared with other programs, like AutoCAD™ or
JViAD but such a database does not exist yet in our context.

D. Control panels
i\ third important generic application is the directinteraction with pieces of equipment by means of "control
panels", which are dedicated dialog boxes.
The user can activate individual control for a particularpiece of equipment (power-supply, kicker, gun ... ) fromdifferent parts of the environment: from the application
management layer, vh! buttons, from the parameter tables andthe synoptics, via double clicks on the icon or via menus.
Individual control activation can also be implemented in usertools, like spreadsheets by means of an external function.
Wherever the request is made from, the control panels arehandled by the same server application. It was implemented inthis way for the sake of homogeneity and interface simplicity.
As fill additional homogeneity feature, all the control panels™AutoCAD is a trademark of Autodesk Corporation.

IV. USER-ORIENTED TOOLSThe basic Motif environment is very suitable for producing
interactive applications. However, end-users as well as genericapplication makers can greatly benefit from the integration ofhigher-level or more user-friendly tools.
Most of these tools are from commercial sources and, as
Motif is a rather recent market, the majority of them are juststarting to be available in production version.
The inte>:'Tation of a commercial tool usually requires aninterface tospecific functions, like equipment-interface Md
to provide support ro end-use.rs if possible.

;ur

A. Nodal and Console Emulation
The first user-oriented tool is CERN-source£!. Nodal is aninterpreter bnguage which is widely used in control
applications at CERN.
The workstation version includes the c{juipment interface
and mme user-interface facilities based on Motif [6].
In addition, most of the facilities which were supported on
the previous consoles (touch-panels, alpha-numeric displays,knobs) are avnilablc by mc~rns of emul<:ltion throughcompatible funcLions.
Nodal was the major programming environment for the
consoles and is ver1 farniliar to CERN's staff. The Nod:il
environment on the workstations provides n very valuable wayof porting existing applications and introduce many users to
the workstations.
Having emulation facilities is critical in order to be able totransport, in a short time period, the whole set of applicationsof one accelerator from traditional consoles to workstations
while focusing only on a few critical parts of them. It also
adds some familiarity in the end users context.

B. Dma Presentation
In the X-window/Motif environment is now possible toacquire commercial tools, like DataViews™· which includes a
lot of data-presentation functions, like multiple 2D and 3Dgraph formats. Some also include a Motif look-and-foci(buttons shadows ... ) which provide consistent presentation and

ni Data Views is a trademark ofV.

I. Corporation

S13MMI01
Man-Machine Interface and Workstations

449

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

C. Synoptics

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

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

interaction for end-users. Such tools usually support only a
sub-set of the Motif facilities for handling the user interaction
but are very powerful for data-presentation.
Such a tool can be very useful for the implementation ofsynoptic-like applications, i.e. applications with dynamic
colors, shapes or graphs but without much computation or
many options. This can provide the end users with a very
productive solution for synoptic-like applications.
We also plan to integrate PRIGS as soon as there is a needof a high-level graphics library.

E. Maihematical package

C. Motif-based
Another major category of tools are user-interface building
tools with dynamic programming support such as interpreted
languages. We'll provide such a tool (UIMJX™ ) for fastproduction of simple applications.
The environment is a graphical editor for building up theuser-interface of the application and a C interpreter for testing
the application from the editor. By-passing most of the UNIX
compilation process, the development of the application ismuch improved. Programmers still need to be trained to Motif
but can use a very efficient envirorunent.
One limit of such solutions is that applications are tooldependent instead of being just Motif-dependent. However,run-time support is usually not a big financial issue and it canbe envisaged to re-work the application when it is stableenough in order to transform it to Motif-only (some tools
include this facility).

D. Spreadsheet
High-level spread-sheet programs, like Microsoft-Excei'u
are every-day tools of much of the scientific staff. These tools
include many presentation facilities and embedded functions.
However, up to a recent date, the Motif market was rather poorin this area. As products are appearing now, we are integratingthem (we have started to do this with Wingz™)
These tools have many applications: quick prototyping ofcontrol algorithms by the specialists themselves, dynamict.reatment and presentation of the data, etc. One major area forthem are the machine development applications. The controlof the CERN Isolde separators is strongly based on such tools
and this application of a spreadsheet is very spectacular [7].
We are porting one off-line PC application to on-line. As
one production version of this program has been alreadyrealized in the plain C-Motif environment, we will be able tocompare the two solutions in area like flexibility,
development and maintenance cost, user-interface efficiency orrobustness.

™ UIM/X is a trademark of Visual Edge Software Ltd™ Excel is a trademark of Microsoft Corporation.
™ Wingz is a trademark oflnforrnix Software, Inc.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

Mathematical packages including symbolic computationand graphical data-presentation are becoming popular tools
among our scientific users. Mathematica™ is a good example
and we are providing this tool on workstations.
Such a package can be used for prototyping algorithms in avery efficient way provided that the specialist is used to it or is
assisted by an expert in the package.
One interesting feature of these tools is that a production
version of the program may be implemented in an operationoriented environment supporting standard facilities(instruments control, timing conditions, archives ...) with
communications to a separate mathematical process
supporting the computation.
Fortran is also available and the MAD optic program is
cWTently being ported.
V. CONCLUSION

One main objective of this first period dedicated to set-up
the workstation environment was to provide a complete
production environment with low costs in development andmaintenance of the system software and with small man-power
resources for the system exploitation. The current situation israther satisfying from this point of view. The environment has
proved to be convenient for application production, although
there are still a lot of improvements to introduce, both inperformances and functionalities.
The two more important evenlS which occured during thisset-up phase are the suddenly increasing range of solidindustrial standards supported by the major hardware vendors
and the jump of the software vendors into the Motif market
There are probably two directions where we will improve
our environment and expertise. The first one is the integrationof analysis and design tools to enhance production andmaintenance of complex "made to measure" programs. The
second one is to continue the effort of implementing useroriented tools for making life easier for application-makers or
to enhance (replace?) the specification process.
V. REFERENCES
[l]

[2]

[3]

The PS and SL Control Groups, PS/SL Controls
Consolidation Project, Technical Report, CERN PS/91-09(CO), CERN SI./91-12 (CO), April 1991.
R. Rausch, Ch. Serre (Editors), Common Control System for
the CERN PS and SPS accelerators, Nov. 1991, these
Proceedings (ICALEPCS, Tsukuba, Japan, Nov. 1991).
M. Arruat, M. Boutheon, L. Cons, Y. Dcloose,
F. Di Maio, D. Gueugnon, R. Hoh, M. Martini,
K. Priestnall, J.P. Riunaud, "New Controls for the CERN/PS
Hadron Injection Process using Operating Tools and HighLevel Modelling Accelerator Programs", these Proceedings(1CALEPCS, Tsuk-uba, Japan, N0v. 1991).

™Mathematica is a trademark of Wolfram Research, Inc.

S13MMI01
450

Man-Machine Interface and Workstations

(4]

[5]

(6]
(7]

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI01

M. Boutheon, F. Di Maio, A. Pace, General Man-MachineInterface used in accelerator Controls: some applications in
CERN/PS Control system rejuvenation, Nov. 1991, these
Proceedings, (ICALEPCS, Tsukuba, Japan, 1991 ).
J.M. Nonglaton, U. Raich, Porting Linac Application
Programs to a Windowing Environment, Nov. 1991, these
Proceedings, (ICALEPCS, Tsukuba, Japan, 1991 ).
F. Perriollat, G. Cuisinier, A. Gagnaire, "Nodal", PS/CO
Note 91-20, November 1991.
R. Billinge, A. Bret, I. Deloose, A. Pace and G. Shering, "A
PC Based Control System for the CERN Isolde Sepatators",
these Proceedings (ICALEPCS, Tsulruba, Japan, Nov. 1991).

S13MMI01
Man-Machine Interface and Workstations

451

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-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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI02

The complete design of the user interface for thecomputer control system will consist of specifying all the
Applications. The structure is Beam Oriented rather than
Hardware Oriented as suggested by figure 1.
III TYPE OF CONTROL TOOLS
We considered in this study that the only interacting tools
would be a mouse, and a keyboard. The (software) tools
contained in an Application can be classified according to thedifferent stages of a process. We have selected:

Synoptics
They are used to visualize the whole process covered in
the Application, namely the pictorial display showing theof hardware constituting the sub processes, on which
the user can act. This figure gives on line the status of theapparatus, at least along the beam path if exact geographicalrepresentation is not possible. Moreover the synoptics isthrough which other tools can bemade of selectable
accessed.

Individual Controls
Each piece of hardware in the Application must beeither to act on the beam itself, or to adjust
measurement devices to obtain beam properties. This is done
through "knob-like" tools which can be attached to any
pnrameter,
incremental actions, on/off type action,and several other moves, for ex. return to initial value. The
refreshed acquisition value is also displayed.
Individual controls are also concentrated in a parameter
list table which gives a complete infomiation on status,
control and acquisition values relevant for this Application
area. Any line of this list is a selectable object calling acontrol knob.
This list is similar to the Synoptics, but gives other pieces
of infommtion: in that way List and Synoptics arecomplementary instruments.
The two classes above are entirely valid in any
Application: they are what we called "generic application
programs" [6].
Remark: we do not deal here with the question of data
management (database use) which is entirely a part of theControl Systems specifications.

figure 2: one example of :i Workstation screen showing some of the toob
and presentation used for the PSB-CPS l GeV transfer and injection prototype.
l= the Synoptics window including all sub process elemcnlll, with Controls menu
2.= Closed Orbit Dillp!ay, in graphical view, and its Controls pull-dov:.n mt'llU
3= the Closed Orl:Jit Display sub window with the syncluoniution commands

4= three (5 possible) "knob-lil::e" tools, controlling power •upplies (hudw, units)
5= the main window· Application manager. giving toUll 11ccess to 11!1 program•This class of tools has no special structure, being too
linked to the particularities of the process. Nevertheless, twotypes of measurement tools are distinguished :• special measurements: the apparatus used, the diagnoses,
the parameters involved are present only in the processdeveloped
covered by the Application. These tools are(sorr:etimes using complicated computations) according to
specific needs. They only obey the presentation rules: e.g. theTransverse Emittance measurement.
• dedication of general interest measurement: here themeasurement is performed through a tool with conditions
related to the Application (synchronism, sensitivity, ..etc .. )~rom which the tool is called. Then, this measure is "generic",
1.e. usable from several Applications but each of them sees it
as if it was specially written. In the prototype, the Closed
Orbit Display serves as an example [9].

Physical Parameters. Some hardware variables like Voltage, Intensity... are
hidden. So an accelerator physicist can adjust parameters
directly in normalized position units, meters, radians, gauss,corresponding to the physics involved in the process [7].
Generally the two types of variables are linked by a linear
equation system seen as a matrix which can be inverted toplay in both directions. Going further this way [8] we cantreat the synchronization of pulsed process (here the CPS
1 GeV Injection) with this method, the matrix being the
cabling lay·out.

One other class can exist:

Optimization
Of course, these programs are specially designed for an
Application; each of them depends only on the process
analyzed. In the prototype the Betatron Oscillations
Minimization [8] was developed; others are foreseen. Thereagain no standards are anticipated, only the interactions andpresentation rules are adopted; the only decision taken was to

S13MMI02
Man-Machine Interface and Workstations

453

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, Japanpropose computed corrections to the user
closed loops were introduced.

When opening an Application, a main window is opened
and proposes the list of available programs in this subprocess. At any time, even with a screen full of running
displays, you can clean the entire screen by storing this main
window into an icon . And the reverse action puts back on thescreen all your Application working environment, exactly as
it was, in one go. This facility has been found extremely
useful, allowing a fast glance at another subject without
interrupting our main task.

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

no automatic

These five types of tools will be present in any
Application of the man-machine interface. Their relative
weight will depend on the sub process characteristics.

IV SCREEN MANAGEMENT

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI02

The different tools from the 5 classes above constitute aworking environment. The user is facing a Workstation
screen: we had to define some standards of data presentation
which could be used in the whole control interface (10]. We
are not talking here about the Standards selected for theComputer Controls System: for screen picturing, XWindows™ and Motif'™ were used (see [6]) and theirstandards accepted.

Data presentation
We concluded from past experience that in any display
exists a dichotomy of data presentation: graphics or tables .
Due to the user personality, or the type of data, or the modeof operation ... etc .. it is difficult to eliminate one of them. We
tried to keep at will the two displays (example: Closed Orbit
Display).
The synoptics and parameter lists arethemselves applications of this concept.

Windows use

Each type of controls tools is running in a proper window
with a menu bar and its associated pull-down menus. We
intend to propose at this level a common choice which can beenlarged according to the sub process. In the prototype FILE,
VIEW, CONJROLS, OPTIONS.. HELP are the common
factor; it is too early to freeze the proposal, but the subject isimportant.
Another point of interest consists of the windows
movements. Experience has shown that windows must be
opened at the same place every time they are called, and,hardly ever need re-dimensioning. It is a task for a manmachine interface study to define an Application in order toverify that this request is satisfied. If necessary, the freedomof re-dimensioning a window is not given. Whenever possible
sub windows should not mask present windows.

Icon use

Such facilities are powerful tools for screen management.
Here also, to make an efficient use of time in an Application
we imposed some rules, and introduced a hierarchy on theicon transformations.
With the exception of some windows waiting for a
specific response or being the last of a tree structure, eachwindow can be put into an icon. The latter is kept itself in awindow (bottom of the login screen) and can be re-opened toits full scale. By the way, we decided also that no window
should occupy the whole screen.

figure 3: another Workswion screen including tools showing other views
and means of controls associated to the PSB-Cl'S I GeV injection process, andcomplementing the figure 2. All these tools can be activated together orsuccessively by the way of icons.
I= Parameter List of the power supplies, giving complete numerical information
2= the Beam Profile Measurement window and related Emiuance computation
3= several knobs, linked to normalized coordinate units here (physical units)
4= the main window • Application manager. see figure 2
5= the Synoptics view kept in background, e.g. giving instantaneous st.ams info.

Workstation use
Every Workstation will be independent, see Chap. V.
It is foreseen that only one Application will be opened (i.e.
"alive") at the same time on a Workstation screen. This is not
introduced as a rule, but a suggestion. The hierarchy principle
implemented in icons use will ease the fast exchange between
several Applications on one Workstation.
Updating data

As said in Chap.I, an Application is related to an
accelerator cycle providing a user with a beam; it was
requested that all the programmes belonging to an
Application display a set of coherent data, i.e. presenting
values acquired on the same machine cycle. At least awarning sign must indicate clearly if it is not the case forwhatever reason. In principle, several Applications could coexist on a Workstation, and updating rate problems could be
anticipated. This is why we considered that probably only one
Application will be "full screen" at a time on one
Workstation.

S13MMI02
454

Man-Machine Interface and Workstations

V ANTICIPA1ED CON'IROLCEl\1TEiR

Workstation relationshipWorkstation will be independent, i.e. can open any
Application
defined in Chap.I), and there will be no
mutual interaction between any other Workstation. If needed,several Workstations will (the system will allow it) open thesame
in order to get a larger screen surface.
Controls will be granted on the basis of first in - first served,
and the command values will be refreshed with the last[9] more precisely).
updatingThegave us an idea as to the needsfromthean accelerator complex, and how the present
central control room • from which ten machines are driven will be T"e11uvema1teu. Thanks to the non-dedication of any tools
has been(the present
the PS acceleratorsfor
operated from 8 simultaneously active entry
several years.
For reasons of screen surface we concluded frome;qf}er1ertce that we need 3 stations to
one console,call a "work place". For the timethemultiplexing system will
foreseenin theControl
construct asystem using
terminal.
Workstations
We think that the central control room of the PS connpl<~xwill include at least 25 Workstations, with a mean value ofthree
on one accelerator at a time. One extra
improvement will be to increase by a factor of 3 the numberof entry

Assignment
At a work
it is foreseen that two workstations will
support thedefined here, and the third one will
be mainly used to cope with theAlarms,Messages, Radiations Survey, Statistics, and so on.
CONCLUSION
The Man-Machine Interface specifications summarized
here and introduced in this protolype are not final. Other
important points are still being debated. For instancespreadsheet(like the EXCELThf product available
in our Personal Computer network [12]) could
development programs if not operational tools. WINC:izTM iscurrently under evaluation (9J.
On the other side a few topics were left aside but will haveto be defined correctly before the user environment definition
will be abandoned. Designing the Data Archiving and Error
Handling and Presentation systems is a must.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI02

For several months the Booster-to-CPS transfer andthrough one
injection process at 1 GeV has been
Application, built from the specifications given above. This
Application constitutes a global environment providing theusers with the controls, analysis, visualization of a part of anaccelerator. This was defined as a prototype for the new era in
man-machine interface using graphical displays associatedwith a distributed network of powerful workstations, The factthat this prototype was readily accepted by the operation
teams without a long training period encourages us to extend
the principles used. A second beam line is already treated in
the same way.
The PS
Computer Controls Rejuvenation projectwill now take care of an ensemble of three machines: the
LEP pre-injectors (2 Lepton Linear accelerators + 600 MeV
collecting
A large pa.1: of the prototype programs
will be used for thatto the benefit of users.

VII REFERENCES[1] F.Pcrriollat and C.Serre, "Problems ina Control
System and Plans for lhe CER.i"l' Proton Synchrotron (CPS)"
Nuclear Instruments and Methods in
Research A293
(1990) pp. 81-86.
[2] PS and SL Control Groups editors, "PS/SL Controls
Consolidation, Technical Report, CERN Internal rep.
PS/91-09(CO) ·CERN SLl91-12(CO) April 1991.
[3] R.Rauch and Ch.Serre editors, "Common Control
forthe CERN PS and SPS Accelerators", t.1-iese(ICALEPS, Tsukuba, Japan Nov. 1991).
[4] I.Boillot, M.Boutheon and al. , "Operation oriented L:o1np1lter
Con!rols for the CERN-PS Complex", IEEE Trans. on Nucl.
Science, Vol. NS-28, nr 3, p.2261 (1981}.
[SJ J.Boillot, G.Daems and al. , "Pulse-to-Pulse Modulation of theBeam Characteristics and Utilization in the CERN-PS
Accelerator, IEEE Trans. on NucL Science, Vol , NS28, nr 3, p.2191 (1981).
[ 6] P.Antonsanti md al. , "Workstations as Coru;oles for the
CERN-PS
Setting-Up an Environment", these
Proceedings (ICALEPS, Tsukuba, Japan Nov. 1991).
[7] I.Boillot, G.Daems and al. , ibid.
[8] M.Arruat and al. , "New Controls for the CERN/PS Hadron
Injection Process
Tools andModelling
Accelerator Programs",
lhese Proceedings(ICALEPS, Tsukuba,
Nov. 1991).
[9] P.i\ntonsanti and al. , ibid.
[10] M.Boutheon and A.Pace, "A Proposal For a Genernl ManWorkstation Interface used in Accelerators Controls", Internalreport PS/OP/Note 90-10, March 1990 (contains a
Reference list).
[11} B.Franunery, "nvuv~= for a VXI digitized Signal Observation, Intern. rep. PS/OP/Note 91-30,
System for the PS
Oct. 1991.
[12} A.Pace, "Office Local Area network at the PS Division", Intern.
rep. CERN/PS 91-45 (OP), Sept. 1991.
[13] G.Benincasa, and al. , "Rejuvenation of the CPS Control
Systems: the First Slice", presented at the Particle Accelerator
Conference
1991 May, San Francisco, Internal rep.
CERN/PS/91-14(C0)1991.

S13MMI02
Man-Machine Interface and Workstations

455

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-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 Workstations456

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

GOALS AND NEEDS FOR TOUCHTERMINAL REPLACEMENT

Client (AAOper)

In the years 1988-89, it was increasingly clear that themini-CAMAC crate based TT's, although cheap compared tothe conventional fully-fledged minicomputer based operator
consoles, were at least a factor three more expensive than amodem, commercial office Personal Computer (PC). Withlimited spare hardware and expensive repair/maintenance possibilities, it was obvious that the TT's, thanks to the simplicity
of usage and direct connection to the front-end computer,
could be replaced by a powerful PC using a standard VGA orsuper-VGA (1024 x 768 pixels) graphics card and ethemet,
TCP/IP links.
With vast and running investment in thousands of lines
of application software and very limited annual accelerator
shutdown time(< two months every winter), the primary goal
was to literally emulate the complete TT facilities on a PC,
using multiple windows to provide the pseudo-touch (click bymouse on touch area), graphics window and the terminal keyboard echo window. The accelerator dependent applications
suite of programs [6] and automated processes in the AAC represent a large number of man-years of software refinement
and effort and CERN's ongoing physics programmes did nothave the resources to ma..ke any extensive alterations or modifications; hence the original applications code had to run on the
new PC-based TT as well as being transparent to the old TT's
at the san1e time. This cohabitation of the new with the old anda graceful transition during the normal accelerator running(>6000 hours/year) was an important issue that precipitated theidea of a fully-fledged TT Emulator.
At the same time, the CERN management had mooted
the idea to dismantle the AAC and re-assemble it in the USSRat the UNK complex, with a view to collaborate and continue
the proton-antiproton Collider programme in the Te V range.
It was considered essential that the hardware and software be
maintainable for several years if this move did occur [7]; thePC-based Emulator fitted this criterion ideally.
With the adapting of the PS Complex controls system toindustry standards and trends at least at the operator
interaction level, the TT Emulator also needed to work undera modern RISC architecture workstation, running UNIX, XWindows and MOTIF tool kit. In this manner the AAC could
converge to the same chosen standard interaction means as therest of the PS complex as well as SPS-LEP. Hence an ultimate
aim was also to be able to do this, based on DEC-3100
workstations.

Ethernet

AA

FileServer

Fig. 2 : Network layout

accelerator control. This then establishes the identical environment under which the existing TT's run. Subsequently, theEmulator creates the three windows on the single PC screen
emulating the three screens of the TT namely, the touch
screen, the graphics/alphanumeric display screen and theterminal VDU. Having established the communications, log-in
and respective emulated windows, the main function of theemulator reduces to the correct detection, interpretation, redirection to the right window and insertion of byte streams and'escape sequences', just as was done by the TT microprocessor.
An essential difference of course was that the created pseudotouch buttons on the touch window have to be clicked by themouse; this and other features like the moving, re-sizing andautomatic re-scaling of every window and provision of essential services like the hard-copy printout of any window, graceful exit, etc meant that a continual scan of the keyboard, mouseand communications input buffer (TCP/IP) is necessary in the.
main loop of the Emulator. Initially, the DOS-based Emulator
was developed in Microsoft 'C' and used a self-written graphical window manager for this application. This has been replaced to run under MS-Windows 3.0, using the standard tools
available under Windows 3.0 and including the Software
Development Kit (SDK) for Windows. The Windows version
permits increased flexibility and compatibility with normal
Windows 3.0 applications and uses interrupts for keyboard andmouse instead of a continual scan. Using a high resolution
graphics board and a larger screen, two concurrent Touch
Terminals can be run on the same PC. Figure 3 shows theschematic Emulator layout in the current PC environment andthe respective links. Figure 4 illustrates a typical PC threcwindow Emulator screen dump, as used by an accelerator
application program.

FACILITIES ON DEC-3100 WORKSTATIONSThe success of the PC-based Emulator augured well fornext stage of the project to have the same facilities on a DEC3100 workstation running Ultrix. The PS Complex has

EMULATOR DESCRIPTION AND
PC-BASED FACILITIESApplication (AAOper)

The Emulator work commenced in early 1990 using an
office Olivetti 386 PC running MS-DOS as a target system.
The PS Division has a network of office PC's, connected via
ethernet and the controls computer are also interconnected via
ethernet and TCP/IP protocols to the office network. Figure 2
illustrates a simple schematic layout of this connection to the
AA front-end computer controlling both the AA and AC rings.
The Emulator task was developed such that it automaticallyestablishes a two-way socket stream (telnet) to the AA computer at start-up, using the low-level suite of TCP/IP socket
library routines. Immediately afterwards, remote log-in iscarried out and the necessary procedures are automaticallyestablished to access real-time Nodal facilities, permitting fullSoo<eo~I\ ~SDKMS-Windows
DOS

I

I
AA

I I

I
PC-Server

I

Fig. 3 : Software levels for Windows 3 (PC)S13MMI03
Man-Machine Interface and Workstations

457

457

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-S13MMI03

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

Fig. 4. Emulator running under Windows 3 on a PC.
standardized on this hardware recently, togethei with the X-11
library and MOTIF tool kit at the inte~mediate level. .The
Emulator was specified to use the full chent-server relat10nships based on these protocols on top ~f t~e T~P/IP s.ocket
library implementation for the commumcat10n lmk as m thePC case. Figure 5 shows a schematic layout and interconnection of the Emulator software on a DEC-3100 workstation.
TI1e DEC-3100 workstation provides increased speed due tothe RISC architecture; it also has a larger screen as a standard
compared to a normal office PC, providing high resolution,
convenience and ease-of-use for the three window TT emulation. Much of the low-level source code was ported from the
PC-Emulator to the DEC-3 l 00. Figure 6 shows the screen
output of the complete three-window emulator runn~ng an
operational application program on DEC-3100 workstation.

CHARACTER AND GRAPHICS FACILITIESThe Emulator package uses the original definitions forthe character and graphics facilities as were defined for the TT(8, 9]. In the TT, the high-level commands to d~aw ~ha:a~ters,
vectors, circles, polygons, etc. are broken down mto md1v1dual
Application (AAOper)

I ~!
I

I

Socket libraryuIL
XToolkit

XLib
UNIX

I
I

AA

I
I

I

ServerFig. 5 : Software levels for X-Windows (Unix)

I

dot commands which are then output to the display through the
Display Memory (DIME) module. Hence, for the Emulator,
the essential task was to convert the character and graphics
escape sequences into C-language based calls for both the PC
or the DEC-3100. The major difference is due to the fact thatsince multiple windows are needed for creating the pseudotouch panel, graphics display and the terminal-echo, respective
memory buffers are required and used at every instance suchthat correct re-size, re-direction or hide/expose events can takeplace for each window. For the graphics window, separate
memory buffers are required for both the graphics and text
,information. The graphics display continues to support a
resolution of 768 x 576 pixels while for the character display,
the standard size text is supported for 24 lines with 64 characters, reduced to 12 x 32 for large size text. Full technicaldetails of all the definitions and additional features of theEmulator are given elsewhere (10].

PORTING APPLICATION PROGRAMS ANDPERFORMANCEThe whole suite of accelerator dependent application
programs and procedures for the AAC Complex have undergone the ultimate trial in usage from both the PC or the DEC3100 workstations, without needing any changes. In fact, theoriginal three Trs in the local control room have not been decommisssioned from use, hence the de facto cohabitation is anabsolute necessity. Maintenance of a unique set of accelerator
application programs limits the software interventions to thislevel only, independent of the three variants (TT, PC or DEC3100) possible at the operator interaction level. The application programs have been routinely used for accelerator operations by the shift crew on both the Emulators. While there may
be little difference between a PC or DEC-3100 based
Emulator, the operators have experienced a considerable improvement in speed over the old Trs. The aspects of window
hard-copy and multiple window printouts on a single page
have provided an improved facility, highly appreciated as apaper-saving, ecological solution.

S13MMI03
458

Man-Machine Interface and Workstations458

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

l(l. 0+

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI03

1991-10-22-1s:<2:12/

SLV-21050-139. 9

t'l'1

---'

18. 0

~
~

"

1944 46 <:8 50 52 54 56 kH:

0300

While the Emulator benefits from the modem ethemet
TCP/IP links, the response time is
to a large extent
on the front-end Norsk-Data controls computer; however, forthe final display features and facilities, the modem graphics
hardware and software provide a large factor of improvementin speed. Overall, the net effect is a factor three gain in speed
over the terminal connection IT's in the main control roomand factor ten gain in the local control room.

CONCLUSIONS

pair of Emulator workstations, each running two concurrent
consoles.

REFERENCES
[l]

[2]

The Emulator has been put into routine operation using
both the DEC-3100 and the Windows 3 PC environment.
There has been a total and welcome acceptance of these facilities by the operations crew without any great need for additional training on usage; the latter aspect permitted installation
and usage even during normal accelerator runs for physics.
Within the usual accelerator shutdown constraints andplanned hardware maintenance, upgrades and spending profiles
over several years, the Emulator has provided a tremendous
bonus in permitting multivendor modem hardware and software to be successfully introduced in parallel with the partial
and graceful de-commissioning of existing, aging IT's. The
ethemet links across the accelerator laboratory and offices
permits further advantage in ease of accelerator supervisionand initial trouble-shooting, without recourse to urgent visits
to the control room.
For the future, since the Emulator package permits theuse of up to two concurrent consoles on the same, larger
screen workstation, a significant amount of flexibility andsubstantial saving in hardware is possible in the local control
room; a graceful de-commissioning of the three old-style IT's
has been planned over the next two years, to be replaced by a

-300

[3]
[4]

[5]
[6]

[7]
[8]
[9]
[10]

P. Anderssen et al., "The Touch Terminal", CERN/SPS/81-15(AOP), Proc. of the Topical Conf. on Application of Microprocessors in High Energy Physics Experiments, Geneva,
Switzerland, May 1981.
G. Shering, Proc. of Europhysics Conf. on Computing in
Accelerator Design and Operation, Lecture Notes in Phys. 215,
Springer 1984, p.481.
G. Shering, "The Touch Terminal for AA", CERN/PS/AA
Mem. 80-10, 1980.
D. Blechschmidt et al., IEEE Trans. Nucl. Sci., NS-28, 1981,
p. 2258.
V. Chohan, Proc. of the int. Conf on Accelerator and Large
Experimental Physics Control Systems, Vancouver, BC,
Canada, 1989, Nucl. Instrum. Methods, A293, 1990, p. 93.
V. Chohan , S. Van der Meer, Proc. of the int. Conf. on
Accelerator and Large Experimental Physics Control Systems,
Vancouver, BC, Canada, 1989, Nucl. Instrum. and Methods,
A293, 1990, p. 98.
V. Chohan , "The Future of AAC Controls System: Options
for Discussion", CERN/PS/AR/Note 89-8, August 1989.
P. Anderssen, "Programming the SPS Consoles", CERN
SPS/82-1 (ACC)
P. Anderssen et al., "User Manual for the New 68000 DICO"
CER.N/SPS/ACC-CC/Note 82-42, July 1983.
I. Deloose et al , "User Manual for the PC and DEC3100
Workstation Based Touch Terminal Emulator'', CERN PS/OPAR Note (to be published).

S13MMI03
Man-Machine Interface and Workstations

459

459

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

SHV-1211ICALEPCS1991, Tsukuba, Japan

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 Workstations460

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingphase, we can profit by the centralized organization of the data, the display, of rotating, translating or resizing it, confirmed
exploit all the advanced features of the adopted graphic system the inadequacy of this library for the synoptic representation ofand make graphic conventions and interactions rules consistent our storage ring.
We therefore opted for the adoption of PRIGS
and comprehensible.
Objects are the graphic representation of the controlled (Programmers' Hierarchical Interactive Graphics Library) for
devices. They retain, as far as possible, their original vectorial graphics. Actual implementations of this standard
planimetrical shape and location, without any additional (ISO-IS in 1988) move towards its complete integration into
graphic coding. They are quite similar to the other graphic the Xl 1 graphic interface and event handling merging [5][6].
primitives inside the environment, like buildings and The PEX (Phigs Extended X) extension of the X protocol,
planimetrical references, but they can also be selected and now appearing in its first implementations, provides theactivated, and their representation can be changed according to transfer of both bit-mapped and vectorial primitives over the
network. The advanced display list organization of Phigs into
their state.
Each object is associated to one or more control panels, a hierarchical tree structure of primitives [7] perfectly matcheswithin which users can operate on the virtual controls to .our requirements for the centralized database. Moreover, thismodify the values of a specific controlled device.
standard supports unique definition of primitive attributes that
Interaction paradigms vary between the different parts. includes transformation matrices, in addition to all common
Users can interactively navigate inside the environment, vectorial libraries features like archiving and single primitive
specifying theand the size of the view. A hierarchical picking. Maximum performance in different hardware
organization into layers of the visualized data and a well platforms is
as all primitives suitable of acceleration
can easily overcome the high density are downloaded to the graphic subsystem, as
defined set ofin theof information inside the environment.
can be standard.
typical graphic acceleration of IM
selectively
while further detail and information in vectors/s can begained with no optional graphic
text form can be automatically obtained as a threshold function subsystem. The constant trend of hardware makers towards theof the scale;related objects can be highlighted or adoption
2D or even 3D graphic accelerators as thedefault configuration of their workstations, guarantees the""a"'"'''-' in scale to improve readability.
acquisition of advanced graphic features, such as real timenavigation over a
database, with no additional cost.
The Elettra Control System has a fully distributed
architecture,
into three layers of computers: conlrol
mom, local process computers and equipment interface units.
Two networks interconnect the adjacent computer layers. At
control room level UNIX workstations are used as operators'
consoles [l]. This architecture, however highly adaptive tofuture developments, implies the adoption of heterogeneous
ha.'liware and software between the two networks. Whereas thebytransparency of the lower operative system is
the Remote Procedure Call application protocol
namingconventions and servers location among the process levelcomputers are stillat console level.
We havethe X Window System Version 11 as our
windowing
and basic graphic library, together with the
OSF/.Motif window manager, Xt and Xm libraries [3][4]. TI1e
Motif widget set had to be extended with several home-madewidgets to fulfil typical accelerator control requirements. The
wide application of this GUI to accelerator controls has led toan active collaboration and exchange of infonnation between
several institutes. This might be a good starting point for adefinition of common requirements.
Although Xl l includes a reasonable number of routines forcreating basic graphic primitives and for modifying attributes,
it is definitely limited as far as display-list organization andmass storage is concerned. It is mainly a bit-mapped oriented
library and the download of visualized portions of graphs is the
only storage method available. The lack of any fonn of data
structure within a display list in memory and the consequentimpossibility of recognizing a single graphic primitive within

A The graphic database
The naming convention adopted in our system is both
simple and effective. Any device is definedits fourcomponent string, which specifies the family to which thedevice belongs, the member within the family, the type ofaction requested (current read, fault reset, etc.), and the mode in
real, write integer array,[8].
which data is transferred
The main effort in the definition of an exact rep:resent.aticmof the storage ring was actually thecomponents in real size through a graphic editor. As this task
is always accomplishedcommon CAD programs, andthe machine assembly needs an identical database, we thoughtof importing the data from our CAD stations via a filtereddownload of the graphic primitives. The only modification to
the CAD database was the addition of a label to each object,specifying its family and member. The link to the control
system database was therefore obtained. We imported the preexistent organization into layers, providing a logicalseparation between the various parts of the machine, and added
the hierarchical structure respecting our naming convention,
inserting a further "group" node between layers and families.
We developed a parser that translates Autocad DXF format
files and generates a Phigs CSS (Centralized Structure Store).
This parser recognizes the notion of blocks and layers andgenerates the tree structure shown in fig. 1. Buildings andother non-blocked graphic information are also imported anddistinguished from the active objects by the absence of a

S13MMI04
Man-Machine Interface and Workstations

461

461

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-S13MMI04

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 Publishingnaming label. The resulting structure is a tree of deepness five,ordered in root, layers, groups, families, members and objects.
We tested the good integration of Phigs into Xl I defining
a widget which loads a generic graphic structure from a file,and provides navigation and primitive picking with no otherpanuneters than the filename inside the Xt widget creation call.

We shall distinguish two operative modes from now
forward: an edit mode, in which we use CPE to create or
modify the panels associated to an object; a run mode, inwhich we select an object, activate the respective panel and act
on the correspondent controls {fig. 2).
TI1e basic interaction tasks (BITs) [10] used in selecting,positioning and resizing widgets inside a control panel arestrictly those specified in the OSF/Motif Style Guide
document, and are almost identical to those used in other wellknown GUis with the same desk-top metaphor. The possibilityof interactively change selected properties of the widgets thatare being edited allows users to have an immediate feedback as
the property is changed. We deliberately limited the number ofmodifiable properties to a definable set, avoiding the change of
those properties with an explicit coding, like colour, and of
those with an unwanted effect to the interface, or an unknown
meaning to the user.

doi:10.18429/JACoW-ICALEPCS1991-S13MMI04

non·pickable layers

databases

Figure 1. Hierarchical organization of graphic primitives inside
the environment.
Figure 2. Schematic layout of the Control Panel Editor.

B. The Control Panel Editor

The time spent in the generation of the code required for atypical composition of widgets inside a control panel was
estimated to be excessive when related to the number of panels
to be provided to the users. A fundamental problem was also
the defmition of the types and positions of the widgets chosen
for the control of a specified device. The possibility of
adopting further application packages on top of those above
listed has been carefully investigated. Several programs havetherefore been examined in our and in other institutes [9). Our
opinion is that the integration with the underlaying standards
is not yet acceptable, with the exception of widget-based
interface generators, in which external data connection andhome-made widget inclusion is still quite hard. As a result we
decided to invest our time in the development of a fullyinteractive Control Panel Editor (CPE).

A complete transparency even to naming convention andserver location of '¥ was possible with the integration of CPE
with the graphic database. Introducing the notion of
association, which is the only complex interaction task in ourinterface, we are able to specify a complete data connection
with a device.
Let us follow the steps required to create an association.
While in edit mode, we select the object we want to control
from the synoptic. As the object is picked, its family andmember information is used to access a list of all possible
action and modes from the machine database. The selection of
one of these items highlights all the widgets that are able tohandle the specified type of data. As we place the chosenwidget inside a panel, the association between the selected
device and the widget is defined, and a connection to the

S13MMI04
462

Man-Machine Interface and Workstations467

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

ICALEPCS1991, Tsukuba, Japan

relative equipment is established as soon as we enter the runmode and pop-up the panel.
Internally, CPE generates an interface file, listing allinteractively selected properties in a purely declarative
language. Interface files can be edited with a traditional text
editor, enabling system programmers to quickly configurate '¥with prototyped panels created cutting and pasting properties
among interface files.
The generation of pure Motif C source code after panel
composition is already available: a self-contained main
program is created with explicit callbacks for each edited
widget Application programmers thus have an interactive tool
for the rapid prototyping of the graphic and data connection
parts of their programs. The implementation inside CPE of asmall C interpreter, limited to the recognition of blocks ofcode, could overcome the limitation of the one-way use of theeditor as a C code generator, and guarantees a complete
development environment for application programmers.

[lOj

JACoW Publishing

J. Foley, A van Dam, Computer Graphics principles andpractice, Addison-Wesley, 1990.

V. CONCLUSIONS
The application of artificial reality criteria to controls is by
no means original. Our main effort has been theimplementation of these concepts on top of a standard software
platform, obtaining a high level of portability among different
hardware configurations. The modularity of the various partsof our interface (synoptic, panels, editor} and their consequenteasiness of maintenance and upgrade, assures a longer life of
the system, compared to the adoption of proprietary solutions.

VI. ACKNO\VLEDGEMENTS
We gratefully acknowledge the support of all the othermembers of our group: L. Barbina, D. Bulfone and P.
Michelini. We are indebted to Fabio Barbo for his valuable
work in the definition of the whole graphic database. In
particular we wish to thank Claudio Scafuri for his significant
contribution to the design and development of our interface.

VIL REFERENCES[lJ M. Mignacco,"The ELETTRA Control System", NIM
A293(1990), pp. 44-49.
[2] P. Andersen et al., "User Guide to the Network Compiler
Remote Procedure Call'', LEP Controls Note 97, CERN 1989.
[3] A. Nye, T. O'Reilly. Xll Release 4, vol. 1-5, O'Reilly &Associates Inc, 1990.
[4J OSF/Motif Style Guide I Programmer's Guide, Prentice Hall,
1990.
[5] HP-PHIGS Version 2.11 Reference Manual, Hewlett-Packard
USA, Jan. 1991.
[6] TGS Figaro+ Rel. 3.0 Reference Manual, Liant Software
Corporation, San Diego, Jun. 1991.
[7] T. L. J. Howard et al., ''.A Praclical Introduction to PHIGS andPHIGSplus", Addison Wesley, 1991.
[8] M. C. Crowley-Milling, "Naming Conventions for !lie
ELETTRA Components", Sincrotrone Trieste, ST/M-TN88/13, Sep. 1988.
[9] Di Maio et al., Report on the study group for the selection ofa software package for synoptics, CERN Internal Report, Oct.
1990.

S13MMI04
Man-Machine Interface and Workstations

463

463

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-S13MMI04

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 Workstations464

B. Long haul consoles
The X-server consoles were demonstrated on a variety ofmachines around the lab and at vendors' offices in nearby
communities. Sun workstations, Macintoshes, and a varietyof X-terminals were compared for capability, cost andperformance. Experimenters understanding the capabilities ofX, convenience, and travel cost savings requested control
system access to allow test and development from their homeinstitution. We currently support occasional long haul accessfrom Pennsylvania and Texas. Peformance of a long haul Xserver console is reported as somewhat slower than a local
network connection, but acceptable. The suitability andappropriateness of long haul networks for remote control
system access may be debated.

C. The numbers
With a full complement of 50 V AXstations, the ability tosupport three consoles on a single V AXstation, and the trend
towards providing office accessibility to all programmers, thetotal number of consoles supported by this system is expected
to exceed 100 within a few years.

ill. ADDING VALUE
The tools and services of the accelerator console platform
are evolving and expanding at a rapid rate.

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI05

typically much slower) for a few hundred devices, and plot
retrieval rates of nearly one thousand points per second.
The distributed datalogger offers custom features notpractical in the sole central datalogger such as dynamicallychanging collection rates. Current growth of the distributed
datalogger predicts up to twenty five such loggers will soon
exist, offering datalogging capability for 5000 devices.

C. Supporting development
Users develop applications programs in VAX Fortran or C.
The Management Environment for Controls Console
Applications (MECCA) is a locally written source code
capture system that captures and keeps a public copy of thesource code for each application program on the system.
MECCA forces users to follow strict conventions controlling
the location of include files and user, group, and systemlibraries. Other facilities exist to build user applications withlittle restriction for testing without affecting the production
versions. These test applications are deleted from the systemeach evening.

D. Other software

The exploitation of commercial or Physics community
software is keenly sought. Mathematica and PAW for
example have been installed and demonstrated but have nocurrent operational function.

A. Console library
IV. MULTI-SCREEN CONSOLES
The console subroutine library (CUB) consists of morethan one thousand routines available to application
programmers. More than half of the routines in CUB may beclassified as value added services not practical on the previous
memory limited platform. Programmers have available newdata acquisition, file management, and screen management
tools.
Screen management routines include
movable/resizable/stackable windows, scrolling windows,
complex menus, dialog boxes, and plotting tools. In addition,
many new services for support of tape recorders, sequencer
management, error handling, and display of digitized images
exist.

A major requirement of the Accelerator Operations group
was that control room consoles have multiple screens andsupport the knob and the set-in-the-countertop trackball present
on the old consoles. The X-terrninals which are used for the
additional screens come equipped with a keyboard and pointing
device. Operating a console with multiple keyboards andpointing devices is unwieldy. This problem, coupled with thestrong demand for a physical knob and non-standard pointing
devices, resulted in the development of the locally engineered
knob/pointer/keyboard box.

A. Control Room Console Configuration
B. Datalogging
A distributed, circular datalogger runs on many of theconsoles providing datalogging at rates up to 15 Hz (butA fully equipped main control room console consists offour physical screens, one 19 inch color VAXstation and three
NCD 17 inch color X-terminals. The VAXstation screen

S13MMI05
Man-Machine Interface and Workstations

465

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 Publishingcontains four alphanumeric windows in support of the user's
applications, and the utility window. One X-terminal
displays the alarm window. The remaining two X-tenninals
contain the six graphics windows.

This control system encompasses and serves several control
room environments. Further, setting access is required forengineering test and development, accelerator experiments, andsoftware developers. Tools and applications have beendeveloped to allow the Accelerator Operations group to
configure the accessibility of programs and devices.
Each console is a member of one or more classes of
consoles that determine what application programs may be run
and devices set Further each console has a setting lock with avariety of privileges determining its behavior. There are fourways that a user is typically denied setting access:1. cannot run any program. The change-program
lock is locked for this console. It must be unlocked by theMain Control Room.
2. cannot run the program. This console is not amember of the classes of consoles allowed to run the selected
program.
3. program will run but cannot do settings because
this console is not a member of the classes of consoles
allowed to set with this application.
4. program will run but cannot do settings because
the console's setting's lock is locked, and the user is offered no
choices for unlocking, and the Main Control Room elects not
to unlock this user remotely or is not able to unlock the user
remotely.
When settings are performed, infonnation about thesettings are queued, then sent to a central settings logger.
Application programs exist to view logged settings with avariety of presentations. An X-server console on the Main
Control Room crew chiefs desk is normally configured todisplay in real time the settings performed from consoles notin a control room environment. That number of settings issmall, and coupled with the run and set control imposed on
applications and devices offers the operating crew theconfidence that they are in control of the accelerator.

doi:10.18429/JACoW-ICALEPCS1991-S13MMI05

B. Knob/Pointer/Keyboard Box
The knob/pointer/keyboard box interfaces the knob shaft
encoder, preferred by the operations staff, to the console. It
allows a single keyboard and pointing device to provide key
input and pointer motion to any of the four display devices.
Finally, it supports the Digital and NCD mice and a variety of
trackballs as pointing devices. No user consensus can beobtained on the best pointing device. Consequently, up to
four pointing devices are ORed together into one logicalpointing device which is sent to the selected screen. This
allows for left and right-handed trackballs or a variety ofpointing devices for the operator. As the pointer reaches ascreen edge, software on the V AXstation instructs theknob/pointer/keyboard box to switch the pointer and keyboard
to the adjacent display screen.
The box accepts inputs from the following devices:- Digital keyboard (RS423, Digital protocol)- Digital mouse (RS232, Digital protocol)- Mouse-Track trackball (RS232, Digital protocol)- Set-in-the-countertop trackball (pulse-train)- NCD mouse (RS232, Logitech protocol)- Knob shaft encoder (pulse-train)- VAXstation control port (RS232)
The box generates outputs for the following devices:- VAXstation keyboard port (RS423, Digital protocol)- VAXstation mouse port (RS232, Digital protocol)- 3 X-terminal keyboard ports (PS2, PS2 protocol)- 3 X-terminal mouse ports (RS232, Logitech protocol)- VAXstation control port (RS232)

VI. CONCLUSIONS

An internal microprocessor accepts keyboard and pointerdata from the input devices and sends it to the selected output
devices, converting keyboard and pointer protocols ifnecessary. The VAXstation control port is used to receive
screen selection commands from the VAXstation and to send
knob changes to the VAXstation.

The new accelerator consoles are providing greater
accessibility to accelerator information to users and richer tools
and a more productive development environment toprogrammers. The growth in numbers and wide geographicaldispersion of accelerator consoles present throughput andsecurity problems that require continuous attention.

V.SECURITY
Security for access control to accelerator devices and control
programs was an issue long before office and long haul
consoles arrived. Increased numbers of consoles called forchanges to a nearly wide open system. The strategy chosen
attempts to balance protection, implementation cost, and risk,
yielding a system that is accessible and accountable.

S13MMI05
466

Man-Machine Interface and Workstations
466

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI05

VIL REFERENCES(1] Cahill, K.J. and Smedinghoff, J.G. (1989). Converting the
Fermilab Accelerator Control Consoles to X-Window
Workstations, Proceedings of the International Conferenceon Accelerator and Large Experimental Physics Control
Systems, pp. 442-445(2] Briegel, C., Johnson G., and Winterowd, L. (1989). The
Fermilab ACNE'T Upgrade, Proceedings of the International
Conference on Accelerator andExperimental Physics
Control Systems, pp. 235-238[3] Lucas, P.W. (1991) The Status of ACNET - Fermilab
Accelerator Control Network, these proceedings

S13MMI05
Man-Machine Interface and Workstations

467

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-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 Workstations468

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

ICALEPCS1991, Tsukuba, JapanThe operator may choose to create a private color pallette
for his display or share one created for another display. Boththe number of colors and the hue of each color are configurablefrom the editor.
Text is displayed within a bounding box. This allows text
object coordinates to be scaled the same as any other object on
the screen. If a group of objects containing text is scaled then
the text font size is appropriately scaled also. If the exact fontspecified by the operator during display configuration is unavailable in the future, then a reasonable alternative font isthus making it easier to write and maintain.
Both the display manager and editor were carefully written
to use only the parts of the host operating system that are usedby the X window system libraries. This should make it aneasy task to port the operator interface to any of the numerous
environments that currently run the X window system. In
addition, care was taken to place all external variables inallocated memory so that our code would easily port to sharedmemory, multitasking environments such as VxWorks. This
gives us the option of creating a stand-alone system that hosts
both the input-output controller and operator interface software
without the need for a communications network.
Under UNIX, the display manager can run each display
with a separate process or it can run many displays from one
process. The latter provides for improved display startup time,
IY>...cause we don't have to wait for process creation to activate adisplay. A file descriptor manager library based on the systemcall select ( ) provides the display manager with the ability torespond asynchronously to events from both the X window
system and channel access simultaneously.
The display manager does not queue up each update fromchannel access prior to making a graphics update on the screen.
If so the display manager would 6'TOW further and further behind
if updates were generated more rapidly that they could be
consumed in the form of graphics updates. Instead, the display
manager writes each update into memory and sets a modified
data tag. When all updates have been dispatched as above thena list is scanned for modified data and the screen is "!''-=•'"'-'·
This method allows display manager to react asynchronously
when the updates are infrequent and gracefully
to synchronous operation when the updates are continuous.
The display manager and editor both share a common
custom graphical user interface tool kit written specifically forprocess control applications. When the project
the
XView and Motif tool kits were unavailable. The project
sets were available at the time but did
athena and HP
not provide the features we needed. Attempts to use the Xt
subclassing techniques to extend the functionality of these tool
kits still did not
the features we nee.ded.
Another factor contributing to our choice of tool kits was
our decision not to create virtual windows with the X libraries
for each of our output-only graphics devices such as meters,
bars, and indicators. This choice improves start up time anddecreases overhead since some of our displays have anumber of these devices. Keyboard and mouse input events
generated under the X window system are associated with thevirtual window that generated them. The X window system
also provides a shifting type coordinate translation for all drawing operations performed within a virtual window. Both of theabove are the normal benefits of using virtual windows.
However, our output-only graphics devices do not receive
mouse or keyboard input. Similarly, we must already perfonn
a scaling type coordinate translation so that graphics devices
will appear on the display with the proper height, and width as
spedfied by the display list. All X tool kits investigated createa virtual window for each object.
Each of our user input devices such as menus, keyboard
input, valuators, and bottons does have an X library generated
virtual window associated with it We use the hash table routines built into the X libraries to translate window identifica·
lions provided by X into a pointer to our structures containing
the graphics input device configuration and state information.

Graphics primitives may be modified for dynamic operation. For instance, the visibility or color of a rectangle may
be based on the state of a process variable.
Operating displays detect loss of network connection toprocess variables. Any graphics objects which are attached to alost connection are displayed in a special color with the process
variable name and an explanation of the problem. Graphic objects are automatically drawn again in their correct colors once
normal network communication resumes.
Macro subsitution of process variable names allows asingle display description to be used for a series of replicateddevices at run time. For example, when theconfigured the operator could type in$(DEVICE_NUMBER)' for graphic object's process variablename. When theis activated the operator could specify
4' and the resulting process variablename used would be 'POWER_SUPPLY_ 4'.

=

DESIGNWe chose to use an internal display list definition todescribe the contents of the display files
by theeditor and executed by the display manager.
approachgave us the most flexibility to add information into the display
list definition that was specific to process control applications.
Our
list can take either a binary or ASCII form.
We use theform when the display is executed for
improved performance and compact storage. ASCII display
files can beconverted to any future binary display fileformat. This
us to rearrange the binary display fileformat in future releases of the operator interface. This feature
has alreadyitself valuable when we realigned the binary
display file so that it would exet:ute properly on both the
SP ARC and 68k processor architectures. The ASCII display
list format also allows an easy way to convert between thebinary display list formats of incompatible architectures. For
example, one might first convert a big endian processor
architecture display file to ASCII followed by conversion to alittle endian processor architecture binary display file.
Additions to the display list description oftennocode changes to the display configuration editor.
have asource file which describes the binary and ASCII format of thedisplay list This file is run through a macro processor which
generates two C language include files. One of these is abinary description of the display list format in the form of C
structures. The other is a description of the display list format
in the form of arrays of a structure describing structure fields.
It is this additional information that allows the editor toconfigure a new addition to the display list description without,in many cases, writing additional editor code. This design has
significantly reduced the number of lines of code in the editor,

S13MMI06
Man-Machine Interface and Workstations

469

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

used.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI06

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

CONCLUSION
We have been using our new operator interface in someinstallations for over a year now. The ASCII version of thedisplay list has allowed us to continually add new features
without sacrificing upward compatibility.
In both the first and second generation each display could
start up several others. We prefer to set up a hierarchy where
each time a display initiates another we see an increasingly detailed view of the process. The second generation operator interface's order of magnitude improvement in display start uptime has made this organization practical. Likewise, fasterstart up times allow us to draw many reusable small displays
instead of one display with a large portion of the process on it.
Our experience with the X window system has been positive. Finally, we can write graphics code that does not become
obsolete with the graphics hardware. The client private color
table and scaleable fonts that appear to be in release five of
Xll would have saved us effort if they had been available atthe start of this project.
Graphical user interfaces are arguably a revolution in computer accessibility. However, the time spent writing graphicaluser interfaces is a large and growing percentage of the total
time devoted to a project. We have tried to reduce this percentage by providing a software tool that allows process control
based on graphical user interfaces to be configured without
writing any new source code.

References and Comment
I. Our control system has been renamed from LAACS to The
Experimental Physics and Industrial Control System, or
EPICS, since the last ICALPECS to better reflect the collaborative effort now in place.
2. Richard Rothrock, "A Workstation Operator Interface forAccelerator Control Systems: A Method for Separating
Graphics Code from Control Functionality", Europhysics
Conference on Control Systems for Experimental Physics,
Sept. 28 - Oct 2, 1987, Villars sur Ollon, Switzerland.
3. L. R. Dalesio, "The Ground Test Accelerator Operator
The Second Generation", International
Interface:
Conference on Accelerator and Large Experimental Physics
Control Systems, October 30 - November 3, 1989,
Vancouver, Canada.

S13MMI06
470

Man-Machine Interface and Workstations
470

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

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-S13MMI07

SUN SPARC!!>h<>" i.

hERA Proton Ring
hardware of the Vacvum Control S)•stcm

.
"

L

p

wi'.h SEDAC Crn:u

111

lil

2:.i\I P.:1!Y\.?r.-.;.~,V•h-u

2CO Ti11:1n•:!.S Elf,v:,:;:!~ •O Luk Ptrt•C'i~l

S:.iti!im;iliM Pu~

va+.ttFigure 2. 111c Vacuum Control System

vacuum operators and in smaller control rooms like the magnet
tcslhall and at the ZEUS experiment. The X-Clients for these
displays run on one of the VAX-based DCM's (DCMV) in the
cryogenic controls cluster.

II. The Vacuum Control System
A. Components
The insulating vacuum of the superconducting magnets, thebeam pipe of the ring and the insulating vacuum of the helium
distribution line are part of the vacuum control system. We
have inslalled 700 pumps of diffcrenl type, 1200 gauges and360 valves. These devices are controlled by several Sun

SPARCstations and graphic tcnninals. The workstations arelinked by an Ethernet network running the TCP/IP protocol.
One workstation has a hardware connection to all vacuum devices and runs the server program.

a. Communication
The device server program reads out the equipment every
four seconds, checks the status and acts on special situations,writes out error messages, stores measurement and status readings in a database and writes changes of the values to a history
file on disk. AJ! other programs can access the device server by
remote procc<lure calls (RPC) to allow calls from different

j~~

KiflC>')'ln:.'.lDtvleit Oat• ea111

Figure 3. Vacuum Communication

S13MMI07
472

Man-Machine Interface and Workstations472

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

ICALEPCS1991, Tsukuba, Japanworks1a1ions on the network. 1l1c data 1r.msfcr of 1he RPCs isdone in a machine indcpenJcm manner by using external Jata
rcprescnL.1tion (XOR) protocol. 1l1is gives all sorts of cmnputcrs of different ma11ufactures access to the vacuum databaseby means of convening the data to a standard fonnat on the
network.

ncctkd to make life c.1sier. Under DECnet you can call DECnet
objects installed on the application server. Starting up the image and redirecting the output to tlie calling machine is done
automatically.

C. Data Presentation

The ©ta are presented in a grJphical way to the us~r. either
in fonns of diagrams or in piots with time or position tkpendence. Presentation devices are: workstations running Open
Look; Tektroni"~ compatible terminals for use in situations
where hand held terminals -designed by DESY- have to be
used and matrix color printer or postscript printers.
Ti1c Lransport pr1jtC'\:Ol fr1r the workst;1ticns is X 11 (X.
\Vindow) to allow di.'>1Jlays on different types of machines.
The next layer c·n top of the Xlib rcutines of X-Wirnfow is the
XView
an interface to Ov~n Look graphics, w~tich provides a simple access to Xl 1. A further layer is the PlotlOgraphic st<mdard. This additional interface givr;s I.he ability tographics on Tektronix 1n·e tcrmin~Js as well as X 11
\V indo\\'S fro1n one source~
All user interaction is done by mouse input. The operator
can scale plots and diagrams, switch vacuum devices or display windows with history plots or faceplates by a simple
mouse click. A window disphlying the timedepcndence of thepn::ssme is for e:r.~unple gener:iterJ by a click on the gauge
reading in a diagram. Additional services, like printing or refresh rates etc., are provided by puli down menus.

Ill. Reliability

Display call-up:
DEC: S set display/create /nodc:::HOST[(DECnet), TCPIP, LAT, LOCAL)
S run application
SUN: : application -display IP·HOST:O/uanspon=

C. Fiedundancy

Even if the operator docs not have to deal with the proper
X-setup, he will be in trouble if the application server with the
X-client goes down. If possible there is a chance to solve eventhis problem. If the application can be run on a DEC
LAVC(local area VAX cluster) 1r1e X-Client can be started as a
Batch job. Defining t11e queue as generic with queues on other
LA VC members the task will be automatically passed to another machine in the cluster and send the sarne output to the X·
Server. The operator just observes a short blackout before hec::m cominue work. Tiiis is a big advantage compared with host
based applic:i1ions.
D. Leng DistanceEnd of 1990 a demonstration system was installed on an exhibition at CER1-l'. TI1e X-Window communication had to passa ·.veli saturated 64 kbit line between DESY and CERN. The
demo was running ov.::r a long tirne p·:riod with reason~:blc results. 1h: mostexperience was, that thedoes net suffer from longtimes. The display was
slow but stable.

IV. Fonts
A. Standards
Even though the X-Systcrn is a standard, this does notreallymean that you will be nble to run any application on any XWindow tenninal. The X-Window systemseveralstandard fonts. If you keep using these fonts you will normally

A Long term operation
Compared with a J1ost based display, the X-display has torely on the availability of many components like cpu's networks and software. Fortunately the development of soft- andhardware has made a great progress during the 13.sc years. We
are running X-displays from different machines to one XServer over the Etliemd wilhouc major problems.
B. Display Activation

Calling up a host based application is as easy as for any
other application. But calling an X-Display and redirecting it toanother machine is not easy to perform. Specially operators on
a control room should not have to deal witl1 this task. Tools are

Figure 4. Standard X-Window Fonts

S13MMI07
Man-Machine Interface and Workstations

473

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

All application programs are requesting device related information by the specification of a device type, a device position, Ilic type of function to perfonn and tl1e property to transfer. The server responds with rrn error code and a singk data
structure or a data block with actual measurements of several
similar devices or the history of one device.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI07

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-S13MMI07

tocol from DEC designed for LAN transport only.
B. Network Load

Several measurements between different systems using different protocols have shown that the applications we use for the
cryogenic and !lie vacuum conLiols need very rare band widthof the Ethernet. A gmphic with about one hundred bargraphs
updated each second takes less than 0.4% bandwidth. In ll1iscase it was X-Window over DECnet. Using 'pure' DECnet toLiansfor the graphic infonnation took about 0.2%. There is an
overhead for the X-display but the real numbers can not be
drawn from this measurement since the numbers are at the low
end of the resolution of the network monitor we used. All the
relevant infonnations for the display update must be packed
into less than 8 DECnet packets. The same results were measured for the X-display using TCPIP as the transport protocol
between a SUN' and a DEC machine. If client and server areboth connected to the same LAN it seems to be reasonable touse LAT as a transport protocol since LAT uses smaller packages. Since the measurements with LAT were made with a
DEC-X-Terminal which obviously was equipped with a tosmall CPU, measurements with other X-Tenninals should be
made. The only measurable network load occurs during the initialization of the display on the X-Server. But also this takes
only some percent of the bandwidth.

Figure 5. Special Application X-Window Fontsbe able to run this application on any X-Server. Standard fonts
which are not known will be displayed in another font -the onethat fits best-. There are ways to write non standard applications if your program explicitly needs a special set of fonts. In
this case the font will not be replaced by other fonts, but you
will have to load the fonts to your server. Not enough, youwill also have to put them into the right directories and makethem known to the system.
B. Different Systems

If you have to include fonts from other systems you willfind out that there is no standard for the file fonnat of the fonts.
Fortunately there is a way to exchange the font information.
This is done in the Binary Distributed Format (BDF). The files
are ASCII files readable by any system. These files have to becompiled with a font compiler which is special for every system.
Font compiler:
DEC: $ DECW$FONTCOMPILER
SUN'::convenfont

V. Conclusions

Afterwards the fonts must be included in the standard fontdirectories or the actual directory must be included in the font
path.
Font path:
DEC: $ sys$manager:DECW$PR1VATE SERVER SETUP
SUN: : bldfamily-

Almost one year of operating experience showed a reliable
operation of the vacuum control system. The provision of two
network layers between the vacuum equipment and the user
display gives much of freedom in transferring daca and graphics to different sons of computers. It makes good software development capabilities available by allowing application programs to be tested with real daca without interrupting the vacuum process. In general the overhead in speed of the networkis negligible. Only some data bound applications are perfonning better by sending graphics data instead of fetching datafrom the history memory across the network. The integrationof vacuum displays on the cryogenic workstation -and viceversa have proved to be very useful for the operators and will
be expanded in the future.

IV. Networking

VI. References[l]G. Horlitz, "Refrigeration of a 6.4-km Cirumfence, 4.5 Tesla Superconducting M:agnet Ring
System for the Electron Proton Collider HERA",
Proc. 10th Intl. Cryo. Eng. Conf., Butterworth,
Guilford, UK (1984), p.377.

[2]

M. Clausen,"Experience with a Process Control
System for large Scale Cryogenic Systems, Advances in Cryogenic Engineering, Vol. 33, Plenum Press, New York and London

A. Communication Protocols
The X-System is designed to be network and vendor independent The most common protocols on top of which the Xprotocol runs are: TCPIP,DECnet,LAT local. TCP/IP is thecommon protocol for UNIX systems. Also for DEC machines
several implementations of this protocol exist. DECnet is a
proprietary protocol of Digital Equipment. There are several
implementations on other systems i.e. SUN'-OS. LAT is a pro-

S13MMI07
474

Man-Machine Interface and Workstations474

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

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 Publishing

A. General Structure

system to be based on a unique and unduplicatedrepresentation of the context and to build tools for displaying,changing, and checking these values in a way completely
independent from their external format.

doi:10.18429/JACoW-ICALEPCS1991-S13MMI08

The tool kit is built up in a modular way. Each module
apports a well defined and limited function which contributes
to a smooth progression and testing.
Its core module is a shared run-time data base (SOB),
containing all data which are system-wide accessible,
surrounded by a number of peripheral modules, some of them
containing their own data bases (DB) necessary to performthe required function. A server (SDBserver) provides all
modules with access to the shared data base thus permitting
the inter-module communication. Besides that, there is a tool

C. The Shared Data Base Server

The use of a server for the book-keeping of shared data
allows concurrent access and distributed computation in astraightforward manner. The interface to its services has been
designed in terms of Remote Procedure Calls so that every
client module can access the global data in a transparent andlocation independent way, preserving the important issues of
openness and developmental possibilities.
D. The Equipment Data Manager, the Equipment Control
Operation Module, and the Action Sequencer

The Equipment Data Manager (EDM), the Equipment
Control Operation (ECO) module, and the Action Sequencer(AS) implement the more proper control functions.
The EDM keeps the shared data base consistent with the
inputs and outputs of the attached equipment and takes careof the adaptation to special communication protocols. Special
procedures like initialization routines are also located here.
The ECO checks for the occurrence of fault conditions
and treats special events.
The AS takes care of the required sequences, i.e. allchains of actions which have to be performed upon a certain
event or a requested state transition.
All modules are completely driven from their own
configuration and run-time data bases. These contain, in caseof the EDM, the complete description of the equipment, e.g.
module addresses and transformation factors between
electrical and physical values, or, in case of the ECO, alarms
conditions, messages, and emergency actions.

Equipment

b

t-":

•
Fig. 1:

E. The Shared Data Base Link Module

The definition of data which have also to be accessible
from modules at remote sites is made through the Shared
Data Base Link (SDBlink) module, which is in fact nothingelse than a client to all involved data base servers and which
has its proper data base containing the correspondences.

The tool kit architecture and the user interaction

for accessing the different module data bases to configure thedesired application and a graphics editor and animation
system to link elements in the shared data base to screen
objects. The most important items will be discussed below.
B. The Shared Data Base

The shared data base contains all data exchanged withthe outside world at run-time, e.g. an image of all equipment
channels, like voltages or temperatures, but also more
abstract data like the last requested state of the equipment.
Abstracting external data in terms of these values allows theF. Special Interface Modules

Particular attention has to be paid to a clean functional
implantation into the global accelerator control system [1] toallow a correct remote control and propagation of alarms.
For this sake two interface modules are foreseen. The firstone (MCR!ink; already exisiting) permits to access the shareddata base through the RPC mechanism widely in use at
CERN. This module will, in the future, also follow andimplement the new control protocol guidelines·as laid downin [2].
The second one (ALARMlink) is an interface to the

S13MMI08
476

Man-Machine Interface and Workstations476

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

ICALEPCS1991, Tsukuba, Japangeneral alann system. It transfonns the alarms resulting fromthe ECO checks into the required format and feeds it into theexisting software chain.

experiments have started to use it, among those the ZEUS
experiment at HERA [8, 9J.
ADAMO is based on the entity-relationship (E-R) modelof Chen [10]. This model adopts the view that the worldconsists of entities - objects that can be distinctly identified
and have a fixed number of characteristics called attributes and relationships, which are associations between entities. A
data model [11], generally spoken, is a strategy for data
organization which includes fonnally defined data structures,operators to act upon the data, and validation procedures toensure that the data obey the imposed constraints.
The ADAMO system provides all these features in a form
suitable for scientific computing where numerical algorithms
are important. The choice of ADAMO is also supported
through its proven portability to the major hardware
platforms and operating systems used at CERN (in fact, it isbased on the CERN software libraries).

An adequate tool is required to access the special module
data bases, i.e. the tables which allow to tailor theapplication, in a proper and comfortable way. Several
solutions are being considered at the moment, e.g. [3].

H. Synoptics
A tool permitting to generate synoptic images andanimate them in correlation with the shared data basecontents and changes (Syn), based on a commercial userinterface builder, working with X Windows and OSF/Motif,
and producing UJL (User Interface Language) or C code, iscurrently under investigation.

III. TOOL KIT IMPLEMENTATION

A. The Target Environment
The environment in which the tool kit should finally run
is the process controller proposed as standard interface
between the equipment and the accelerator network [1]. in
our case, a diskless industrial PC running under the real time
operating
LynxOS, together with X Windows and
OSF/Motif.

B. The Development Environment
To simulate the target environment we used a diskless
DECstation 5000/125, with a remote workstation acting as
file server. The use of a multi-windowing environment andthe fact that all important tools were already available
pennitted to advance quite rapidly.
To simulate attached equipment electronics we used a) a
HV power supply and a programmableunit built up in
G-64, each controlled by a microprocessor and connected to
the workstation through a terminal server
RS-232 links,
and b) several commercial 1/0 modules on a Bitbus, linked to
the workstation via a SCSI-Bitbus gateway [4]. No additional
driver software was needed.

C. The Data BaseIn an application like this where the reliable access to a
lot of data is essential, the selection of adata basesystem becomes a key issue. Our investigations for a noncommercial product which has proven its quality in similar
applications has led us to the choice of ADAMO [5, 6].
ADAMO (= Aleph DAta MOdel) has been developed
within the ALEPH collaboration at LEP where it is now usedin the fields of data acquisition, detector description, event
reconstruction, and data analysis [7). More recently other

D. CASE Support
CASE (Computer Aided Software Engineering) tools
provide methods for describing graphically and consistently asoftware system in its life cycle through analysis, design,coding, and maintenance [12J thus speeding up thedevelopment.
Such a tool, called SIP (=Software through Pictures, fromInteractive Development Environment), has been employed
for the construction of the tool kit, using an ADAJvIOInterface to the Picture Editor of SIP. This allows, starting

ValueOp

Value

Expression

Condition
triggers

Fig. 2:

causesMessage

E-R diagram of the ECO module (simplified partial
view)

from the design of the data bases in E-R diagrams, togenerate automatically the data structures in a format that canbe accessed and manipulated from the desired programming
language through a run time library.
As an example of the applied technique, figure 2 shows a
simplifiedof the E-R representation of the ECO module
which can be interpreted as follows: A 'Condition' on which
the system should check is made up from 'Expressions' with
'Values' as operands. Such a 'Condition', when fulfilled, can'trigger' an 'Event' which 'causes' either 'Messages' or'ValueOperations'.

S13MMI08
Man-Machine Interface and Workstations

477

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

G. User Access Tool

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI08

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

E. Use of Standard Tools

slow control systems are needed.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI08

To provide a maximum of portability, standard tools havebeen employed wherever possible.
The tool kit itself has been written in C. Since the UNIX
world is our main target the internal communication layer
through Remote Procedure Calls has been implemented using
NCS (Networlc Computing System by Apollo Inc.) [13].
The windowing environment for all interfaces used forcustomizing or output is provided by X Windows and
OSF/Motif.
IV. EXPERIENCE AND RESULTS
A prototype application has been realized which
comprises about 30 digital and analogue J/O channels. On the
DECstation 5000/125, the CPU time needed to perfonn a fullcycle of readings and checks is currently about 45 ms (ofthis, about 30 ms are consumed by the data acquisition andmostly due to the way the equipment has been attached). The
application perfonns very stably.
The allocation of virtual memory is around 6 MB. To
have a safety margin when running in a diskless environment
together with other processes a total memory size of 16 MB
seems adequate.
V. STATUS AND OUTLOOKThe following elements of the tool kit have beencommissioned until now: The shared data base, the data baseserver, equipment managers for Bitbus and multiple RS-232
links, the alarm module, and the RPC interface.
The most prominent future task is to transfer the wholesystem onto the desired target environment, a PC runningunder LynxOS.
Once this has been accomplished, we first plan tostreamline the product in terms of simpler interaction (tableentry and user interface), to add protection mechanisms
against unauthorized use, and to take care of the display ofactual trends, data logging, and re-play of stored data. One of
the more long tenn goals is to provide a higher degree ofsupport for fault finding (on-line help) through theapplication of expert system techniques.
The first test application in a larger project is planned forspring 92.
VI. CONCLUSION
The extensive use of existing tools, like the data
management system ADAMO or the CASE tool StP has
made possible to optimize the cycle between analysis, design,coding, and implementation and to arrive, in a relatively
short period and with little manpower effort, at asatisfactorily working prototype system.
The use of recognized standards for the underlying
mechanisms makes this tool kit a highly portable productwhich could find its application also in other areas where

VII. ACKNOWLEDGEMENTS
The authors would like to thank the members of the
CERN-SL/CO group for their support and for providing thenecessary hardware and software infrastructure.
It is a pleasure to acknowledge the support received fromthe DEC Joint Project Office at CERN.
We are indebted to J. H. Dieperink, S. Fisher, P. Palazzi,
and W. von RUden for their contributions and A. Lovell forhis help.
We would like to thank the organizers of this conference
for their efforts.

VIII. REFERENCES[l] R. Rausch and Ch. Serre, "Common Control System for
the CERN PS and SL Accelerators", this conference.
[2] WOPRO Working Group, reported by G. Benincasa,"Control Protocol: The Proposed New CERN Standard
Access Procedure to Accelerator Equipment: Status
Report", this conference.
[3] A. Aimar, "VERDI, Visual Entity Relationship Data
Interface", thesis, Department of Computer Science,
Torino, Italy, 1989.
[4] A. Aimar et al., "SPS/LEP Beam Transfer Equipment
Control Using Industrial Automation Components", thisconference.
[5] M. G. Green," The ADAMO Data System, An
Introduction for Particle Physicists", Royal Holloway
and Bedford New College, UK, RHBNC 89-01 and
CERN/DD/US/131.
[6] S. M. Fisher and P. Palazzi, "Using a Data Model from
Software Design to Data Analysis: What Have We
Learned?", Comp. Phys. Comm., 57, pp. 169 - 175,
19&9.
[7] Z. Qian et al., "Use of The ADAMO Data Management
System Within ALEPH", Comp. Phys. Comm., 45,
pp. 283 - 298, 1987.
[8J H. Kowalski et al., "Investigation of the ADAMO
Performance in the ZEUS Calorimeter Reconstruction
Program", Comp. Phys. Comm., 57, pp. 222 - 224,
1989.
[9] R. Loveless, "ZEUS Hardware Control System", Comp.
Phys. Comm., 57, pp. 313 - 315, 1987.
[10] P. P. Chen, "The Entity-Relationship Model - Toward a
Unified View of Data", ACM Trans. Database Systems,
1, pp. 9 - 36, 1976.
[11] D. C. Tsichritzis and F. H. Lochovsky, Data Models,
New Jersey: Prentice Hall, Englewood Cliffs, 1982.
[12) D. J. Hatley and I. A. Pirbhai, Strategies for Real-time
System Specification, New York: Dorset House
Publishing, 1987.
[13] M. Kong et al., Network .Computing System Ref Man.
New Jersey: Prentice Hall, Englewood Cliffs, 1987.

S13MMI08
478

Man-Machine Interface and Workstations

478

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

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

access server and a server for starting any PDP-11 application
have been written.

SNS and allow the user to select a limited number ofparameters for control. These parameters are then submitted to
the knob server, who establishes the DecNet connection to the"server" programs on the PDP, pops up a parameter access andcontrol panel on the workstation screen and manages thecommand and data transfers to and from the servers.
Figure 1 shows the interconnections between theapplication programs on the workstations, the newly written"servers" on the PDP-11 and the old parameter access softwareon the PDP.

IV. NEW SOF1WARE ON THE WORKSTATIONS
A. The knob saver
In order to hannonize the user interface for parameter accessof all applications programs a "knob server" has beendeveloped on the workstation. A typical application program
will register all parameters it needs to be updated regularly on

knob
serverI
I
I

DccNet
1og1c
. al
links

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI09

execute single collUllands
I
I

vxs

I

I
I
I

I
I

I

I

I
I
I
I
I

I
I
I

I

I

I

'
I

Application

I
I
I
I

I
I
I
I
I

DecNetlogical
link

I
I
I
I
I
I

--

sns
loop

registerednames
repetitive
acquisition

I
I
I
I
I

I

I

I
I
I

I
I
I

Wark.station

Camac

I
I
I
I
I
I
I
I
I

+ .j,

Parameteraccessrequestprocessor

oldapplications

I

PDP-11 "servers"

existing PDP-11 conrrol software

Figure 1 : The system constituents and their interconnection

B. Single parameter accessIn order to get access to any single parameter a touch panel
simulator has been developed. Each parameter is assigned abutton which can be reached over a touch panel tree.
Activation of a button may have one of three possible effects:
1) display of a new page;2) activation of an application program;3) connect to a parameter through the knob server.
This program has been written as a temporary tool toallow parameter connection and starting of applications until amore performant generic tool of this type (the console
manager) will be available.

C. Synoptics
Many application programs simply show the status of anaccelerator subsystem like a beamline, an RF subsystem, atiming subsystem, etc. A static background picture shows a
representation of the subsystem and active boxes indicate theequipment state with different colors or give their acquisition
values in form of numbers. Those types of applications can begenerated completely interactively using a synoptics editing
tool and its corresponding runtime part The editor reads apreviously designed bitmap (paint programs are available under
Motif) and allows to place active boxes freely on top of the
background picture. The editor allows to select any of theboxes and connect them to an equipment parameter byspecification of the parameter name, and properties likeacquisition only or acquisition and control. A status box
contains a symbol representing the connected parameter and acolor corresponding to the parameters state. For status boxes
we can therefore specify the color for a combination of status
bits and the filename of a bitmap containing the symbol icon.
The result of the editing session is saved on a synoptics
specification file which is consecutively read by the runtime
part of the synoptics package. The runtime part willreconstruct the image, bringing up the background picture andall boxes at the predefined places. Knowing the parameter

S13MMI09
480

Man-Machine Interface and Workstations480

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingnames from the output file of the editor the boxes are activatedby making the necessary calls to the equipment accessroutines. Figure 2 mows an editing session for a synoptics

application while figure 3 shows the running synoptics wherea parameters has been selected for control. The control panel
displayed by the !mob server can be seen.

RF C<inoral Synoptics
Em.pl itudes

BuncherD

Debunchor:sLI. CBJ

LJ\2. Cl1I'2

LAJ . Cl1I'3

LT.LDElO!=.nl J=·nl l=-1Yl

!=.nl

~

lrm.yylLI. CDl

LI. C1l2

j IY

LTEL COE12

l=nl
LT, TRAlO LT. TRA20 LT. TRA30

l=l"fl !=1·11 l=l"flReforence Generator

TankE

LAL C11I'l

DebunchorsLl\2. cru'2

LT. LDEJlO

Acquiaition

ACQ:
REF:

I mo.ocrhl

03587. 500
03600.000

O.K.

controli;;;[!Ju;irn

i:;;rnrn

03600 • 000.TRJl05 LI.TR.\06 Ll\l.TRA07

03600.000-05000.000
05000.000
INI:
03600.000-*-*'-"'-*-*

Reference Generator

l!!t!lt!l!!l l!H!l!!l n ......;.;..~

c::IE3 CI§)RF- Modula tor:

LA.!Jl!OD
LA. TYRSE:ll

Figure 3. A running synoptics application

D. Logs
On the old Control system several log programs areavailable. The logs read the parameter names of the equipment

who's values are to be logged from a file . Then they acquire
the current acquisition values for each of these parameters andwrite them to a file which is consecutively spooled to a printerand then deleted. In order to get Logs to the Workstation the
Log program is remotely executed on the PDP system and the

S13MMI09
Man-Machine Interface and Workstations

481

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-S13MMI09

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-S13MMI09

resulting file is transferred before being spooled. Finally thefile may be displayed on the screen or sent to the local printer.

E. Application programs
Several more complex application programs could not be
ported with the synoptics editor because of their graphicalrepresentation of the acquired data or because of their more
complex data treatment These programs had to be ported
using directly the MOTIF development tools. For the moment
this has been done for the Trace3d, a transfer line modelling
program[2], the beam loss measurement along the Linac andthe transfer lines and the spectrometry measurement The staticpart of user interface has been specified in the User Interface
Language (UIL) while the active part has been written in C
(Motif initialization and callback routines). The emittancemeasurement programs are about to be ported. Here we tried touse an interactive user interface builder (Dec vuit) which
generates UIL at its output. However a big improvement indevelopment efficiency over handwritten UIL has not been
seen, perhaps because of our inexperience using the tool.

V. CONCLUSIONSThe project was driven by two principal problems: The
hardware consoles used at present in the Linac control room
are becoming obsolete and difficult to maintain and access to
the Linac control system was needed from the main control
room. At present most of the daily operation work on the
Linac can be done from the workstations in the MCR. Mostof the programs developed so far will be reusable (with slightchanges due to different equipment access especially for therepetitive acquisition) for the final system. We will have to
finalize the beam diagnostics programs, generate many
synoptics with the described tools and do the final switchoverto the new system layout replacing the PDP-11 computers by
DSCs.

References
[l]

[2)
[3]

F. Perriollat, C. Serre, "Problems in rejuvenating a controlsystem and plans for the Cem Proton Synchrotron (CPS)",
Nuclear Instruments and Methods in Physics Research A293
(1990) 81-86.
U.Raich, "Beam Modelling with a Window Oriented UserInterface", Nuclear Instruments and Methods in Physics
Research A293 (1990) 450-455.
R. Rausch, Ch. Serre (Editors), Common Control System for
the CERN PS and SPS accelerators, Nov. 1991, these
Proceedings (ICALEPCS, Tsukuba, Japan, 1991).

S13MMI09
482

Man-Machine Interface and Workstations

482

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

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, Japansystem consists of 10 workstations as the operator's terminals.
In addition one workstation acts as a file server. Everyworkstation replaces all 14 of the former CRT consoles.
Figure 1 shows the new man/machine system configuration in
ZENKEI.

the discharge result data display, simple and more user-friendly
operation had been also required. Another principle is to be"more flexible", because user friendliness is inevitablycompleted after frequent modifications. The new system must
interface with H-80E system which is linked to eachsubsystem controller composed of JT-60. It minimized the costof modification, and reducec;l the risk in the softwaredevelopment

B. Outline of the dataflow
All data (including plant monitoring and discharge result
data ) are archived in a temporary file by the SVP (supervisor
computer) from the HIDIC-80E ( H-80E) system (former minicomputer system of ZENKE!) using data communicationinterface. There are two different communication routes between
the SVP and the H-80E system. One is a OMA-controlled 16
bit, parallel interface. CLC (computer linkage controller ) is
assigned to small amount of data such as alarms and event
signals. The other communication through a shared memory in
SVP is assigned to a large amount of data such as discharge
result (8.Mbyte/shot ).
Each workstation transfers a comparable large amount of datafrom a common file in SVP and SunSV ( a server workstation )by using NFS ( network file system ) through the Ethernet
TCP/IP protocol is also used for short data transfer, such as
alarms and sequence event data.
The discharge condition is sent from a workstation to the
SVP with NFS.
The discharge condition in SVP buffer
file is sent to H-80E by the operator'smouse operation.

III. SYSIBMCHARACTERISTICS

77'-fJl.1!.

:

7l/7Dot.f~

B. Setting of the discharge condition parameters
The requirements for setting the discharge condition
parameters are a) minimize the number of parameters set by theoperator shot by shot, b) set the parameters as easy as
possible and c) hold consistency among the each discharge
condition parameters. To satisfy the requirements we made thehistogram of the parameters used among the previous 10000
shots.
As the result,the discharge condition parameters were foundout to be classified into 3 groups corresponding to procedure todecide the parameters.

a) group 1; the parameters set by the operator directly.
The parameters such as plasma current, magnetic
configuration (limiter/divertor), heating/joule experiment andintensity of the toroidal field were arranged as main parameters.

fA

MNo

:nmu.

7L-7CNo: "'\73;("l\i517L-70 (;ZQ)~00

llPOllA. Design principles

1.HIH•Cl'"

JUl

1,HH-t•U
LSUU•Ut.HIH:•OJ
l.UIU:•U

OU

2.UHUU

IISU

2.UfH:•U:.tHU:•llnunu

The major functions of the
man/machine interface system are
mentioned in the previous section.
The requirement of the system is to
fully utilize the resource in the H-80E
system which had "survived" for five-year
operation in JT-60. For example,
concerning the discharge sequence control,when the operator hits the sequence start
button on the workstation, the message
is sent to the H-80E and kicks thedischarge sequence logic in the discharge
management computer ( 1b ) through the
SVP~ CLC.
As for setting the discharge condition,
drastic improvement had been required toreduce mis-set of the parameters. As for.

II

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI10

uu~

LntU•U$.¢;Ut•H

IOit
UU)( t.tHtt•H -"""'li;t•'1.Ktft"•tl)
UtH

U.

UM

llH
llM
lln

1.t:i:t•;J

' llM
'' ""
""
'
111'•

Jiu

lfM

"

.

"
fr~

7dl'15 0

ru:m

o

fA

MNo

.....

: ttlO~n::.-1t5;;-~

MOOl ll!llilllQo~M002 W'.Jill

0•-

M003

fo1'¥1~

0

X054

T::J1'1~\li1MI

0 iE1n'1

X055

P::J1'1HZ!i<r.l!W

0 iE1n'1

POOi

77A~v70(ltQ)

4.tUt

n.uu

Fig.2 Display of the preprogramed wavefonn, discharge condition
parameters set by the operator directly and it guidance.

S13MMI10
484

Man-Machine Interface and Workstations484

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Hereafter.the parameters of the fivepoloidal field coils, such as the initial
excitation current value and pre programmed
current waveforms are arranged on the nextscreen. The gas injection valves and preprogrammed pre filling, gas puffing
waveforms are arranged in the same way.
b) group 2; automatic setting

The structural analyses and operational
experience showed that quite a few discharge
condition parameters can be uniquely decided
by the group l parameters.Simple algorithms
are developed in combination with the status
or selection of devices set by the operator asgroup 1 items.
For example, when the operator selects•o~nn+~-~~~~~--'-~~~~-t-"""-"".O
the divertor configuration, the divertor coil"""Ci!'.Cl
power supply is automatically set by
Fig.3 Discharge result data waveform withalgorithm. The beam CW1"ent parameters ofenlargement of the waveform.
NBI are automatically set by the beam
acceleration voltage.
Then the chief physics operator selects a discharge condition
The timing parameters of NBI control system are also and submit it to the next
sequence. The chief physics
automatically set by the data of the initial NB injection timing operator's approval is necessary to start the next sequence.
of the NB injection power waveform. The MG acceleration time Figure 2 shows the typical discharge condition parameteris automatically set by information of the present rotating
display.
and the maximum currents of the coils. These algorithms are
C. Graphics
pe11rnrrm:a whenever the group l item is setc) group 3;fixed discharge condition.
The discharge condition parameters in the group 3 arechanged only in modification of the system configuration andcommissioning of the initial phase of the operation. It contains
the data set of coefficient for the electro-magnetic probes, data
sampling piiches and the value of operational limitation such as
the maximum coil current and the vessel wall temperature.
Limitation/consistency check are performed when theoperator selects the discharge condition parameters. And "userfriendly» consideration for displaying each discharge condition
item such as guide for setting, menu selection , graphic userinterface reduce the risk and load of setting the discharge
condition. Using the mouse, the operator can access to a brief
guidance for the discharge condition parameters; the names of
items, rated value of setting, related consistency check andautomatic setting algorithm.
After the completion, the operator may compare thecomplete set of the discharge condition with another torecognize the different parameters.
Anyone can make a different set of the discharge condition at
the same time. A completed discharge condition file isregistered to a buffer file.

GKS and Sun View software packages are used for graphics,
because they have many tools for screen operation andmultiwindow application. Figure 3 shows an example of thedischarge result data display.
Icon selections are located in the lower position of a screen.
They provide special functions; enlargement of lhe graphs,
digital value display at the cursor( minimum, maximum ,average values within the all sampled data or pointed out times
the mouse operation and calculated values of integration,differentiation through the pointed area), ete.
A
specification table makes it possible to display thegraphs quickly. The ID number of the measured data( PIDNo)
is listed in the utility file. The operator simply selects the
PIO.No to make the graph specification table.
Initially we had used simple text-based interfaces where theoperator had to type using the keyboard.These primitive
interfaces were replaced by using the Sun View package. This
enables the design of graphical interfaces with icons and menus.
The operator interface should be as simple as possible toprevent confusion. So, for instance, in mouse operation, theonly left button is used for application software. Menu is also
used for quick access to objective display.

S13MMI10
Man-Machine Interface and Workstations

485
485

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-S13MMI10

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

lnl~ltlJU8l"t:J..t}tNO~,, ,,-< "...
~1c:o\·;"1n.@ ...

:n EOl4165

5: ; ~p c:o~·; KAl WI%
LH•O,JC•O
SU' Agin9 : .ft

1123 EOl4166
n:

~ !'

KA
1 tml'fUC•O,lC'•O

IU' '91"9 ''24 E0!4166
IJCU,4167... ~ !p

?5 E014163

26 ----

11

4:oi·: HA

l t:!IU't
LH• O,lC• O...

IU' AIJlni; :l\L.-~t-

(~(>)

TS<•>

~.12

H
H1U88 ....
:=tu H ill; t88
Dl-0.U
DX-0.11

u~DX-0.11

oamo.uDt..O,U
DX=0.11n:.. IP • 1.5 KA• 4,05 T
1 OMI'f
LH•O,IC•O
Rr Aglln; : l'I

;~~ M
I
1~rn

~

oa..o.u

Dta<J.U
DX..0.11-·----

I

ii.mi ···.u~

it
ihn&!

n
u.rm

1~f:g& I'"'.U~

I~ r:88

~
liU1

••
•t
jt_

,_

,..-711.oNOl

1

,,

:J

" >

h,.-Jt el UliH~~"~

ltput d UJUU... ,..t.rrtl4t6S
Ll:,·1,l•f.S,U.S-11.h
1t11S.S-U1- The Japanese error messages system is
The detailed
useful for the operator.
infc;>rmation is also available by the mouse
operation.
-The remote maintenance function for each
workstation has developed to maintain thesystem availability high enough.

V. FUTURE PLANh;.ttoCUl41U

Jp,lft'i!m

PH2J:3~More workstations are planned to be added
to the network. It enables us to see the sameI-

- - - '--·-----77,_[!jID][) Cllm1D ~ I (!lil!);I,!, '1& I I i.,~F§l'.Blf I Cm!lJ.~,

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI10

JR1r1tt-nt11m
75;("1'~"ICALEPCS1991, Tsukuba, Japan

OITJ• :.V'O·){fJ?J-2=\-\•

Fig.4 Shot schedule display

infonnation at the office as in the control
room. Improvement of computer capability of
the workstation and the SVP is desired.
Especially speed-up of the message
transfer between the SVP and the H-80E is
important for more quick response.

VI.SUMMARY

D. System design/or graphical user interface
The effort of "quick response " in graphics and copies wasmade by applying the SPARC station in the network.
Another effort was made to design each "picture layout" indetail to satisfy the requirements of simpler operation.
For example, "shot schedule" screen provides entire
information to all of the people in the control room , as shownin Fig 4. In this screen, the chief physics operator can modify
the discharge condition parameters from the previous shot andable to confinn the main parameters and shot result. The duty
manager decides to execute the discharge condition after thechief physics operator approves the discharge condition. Afterthat the duty manager recognizes the discharge condition,
together with both of the limitation check and consistency checkof the error is detected, the sign becomes void.
In addition , the screen displays the progress of the discharge
sequence. The status of the discharge sequence can be seen bychanging the characters correspond to the progress of time

The new ZENKE!, workstation-based operator interface, hasbeen operated for more than half a year. It is accepted by theoperator using mouse operation instead of typing . An improved
features of the new man/machine interface system aresequence.

The authors are grateful for many useful discussions withmembers of the control group; in particular , they would like tothank to Drs. M.Shimizu and T.Kimura for continuing support.
The contributions of all other members are also gratefully
acknowledged.

summarized;l)The setting of the discharge condition parameters isdrastically improved by adoption of automatic setting algorithm
and fixed parameters.
2)The consistency check and graphical user interface reduce
the risk and load of setting the discharge condition.
3) The shot schedule screen has been widely used asinfonnation; modification of the discharge parameters, status
summary of the discharge sequence execution and discharge
result summary.

ACKNOWLEDGEMENTS

IV. LESSONS LEARNED
Some important lessons were learned from initial phase of.
the operation.
- In a few tens of seconds of delay , the operator can not
wait for the discharge display without irritation.
- Although the window size can be changed, it is seldom
used. Icon is very useful and overlapping window is not so hard
to see.
- Automatic photo copy of discharge result data display isseldom used. We provide automatic copy for quick infonnation,
but the operator just display objective graphs.

REFERENCES[1] I.Kondo, et al., "The IT-60 Central Control System," Fusion
Engineering and Design, vol.5, pp.69-84, 1987.
[2] K.Kurihara, et al., "JT-60 Plasma Control System, "Nuclear
Engineering And Design, vol.11, pp.441-454, 1990.
[3] T.Kimura, et al., " VME Multiprocessor System For Control At
The IT-60 Upgrade," IEEE Trans. on Nuclear Science,36 (1989)
pp.1554-1558.

S13MMI10
486

Man-Machine Interface and Workstations

486

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 Publishing

Pictures are drawn interactively using a tablet, like a CAD;
completed picture data are saved into static memories of thedisplay station. A graphics screen consists of a basic picture
and additional modifications of graphic element attributes suchas color, blinking, or a new plot on a graph. Application tasks
can choose any monitor to display. Usually, the FGS control
task automatically assigns the nearest display monitor to thetouch screen which made the application task start
Another feature of FGS is a "picture stack" method. Fig. 2schematically shows how the picture stack works. When an
application task requests a new picture on one of the monitors,
the old picture, if already there, is pushed into the picture
stack. The last requested picture always has the highest
priority to be displayed (it is called to be "active"). The
pushed-in picture is not displayed, but can still be modified bycommands from the application task. It is restored when theactive picture is removed by a free command. Each display
monitor has its own stack of eight layers. Graphic display
stations have no responsibility with stack management,
though the FGS control task in the control computer does.
The FGS control task keeps all infonnation concerning picture
stacks and applied modifies.

independent 20" CRT, each with a resolution of 1280
(horizontal) by 1024 (vertical) dots and 64 colors. It also has
5.5 Mbyte static memories for storing graphic picture data;
this capacity corresponds to 550 standard pictures.
DP-1000 has two operation modes, local and remote. In
the local mode, pictures can be drawn interactively using atablet; no programming is required. Completed pictures are
saved into memories. One of the unique features of DP-1000
is a "tag method'', a co-ordinates-free location method. By
tagging a graphic point(s) with a name, it is possible to pointout pre-defined locations only by calling the tag names. Tag
names can also include informations concerning graphic
attribute, such as color, blinking and font type in addition toco-ordinates. In the remote mode, the host computer is able toselect reserved picture data and to display it on a CRT by
sending a simple command string to DP-1000 through an RS232C link. Modifications on a displayed picture are also easily
done by sending commands; the tag method is effective in thisdoi:10.18429/JACoW-ICALEPCS1991-S13MMI11

case.

5. SOFTWARE DESCRIPTION
5.1. Software Interface to Application Program
One feature of FGS is that an application program is
simply and easily built. FGS serves several FORTRAN
subroutine modules as follows:- DPINZ initializes the FGS environment, called once at thestart of the real-time system.
- DPSET selects a reserved picture and displays it on amonitor. The FGS control task sets pointers of the control
tables, allocates the parameter area and establishes a bindbetween the application task and selected monitor.
- DPMOD modifies the picture. Modifications are effective forboth active pictures (now on display) and inactive ones
(pushed into a stack).
- DPFRE terminates a picture display and sets the monitor free
to other inactive pictures, if any.
Only these four subroutines are sufficient for application
programs to use FGS.

DISPLAY MONITORAPPLICATION TASK

active piclure

inoclive>,picturescoll DPSET

coll DPSET
collDPMOD

5.2. Installation of New Picturescoll DPMOD

The way to install new pictures into FGS is as follows:- Make basic picture on DP-1000 in the local mode using atablet, and save completed picture data into memories.
- Develop modifications on the basic picture using aninteractive test tool on a host computer, and store the final
command strings into a modification record file on the host.
- Define a picture name and add the modification record filemade in a previous step to the FGS command file.
- Install the FGS process into the application program using
FGS service routines.

Fig. 2. Picture stack method of the FGS.

4. INTELLIGENT GRAPHIC DISPLAY STATION
DP-1000 is a VME computer system that was speciallymade for graphics processing by Digital Electronic
Corporation. It has 4 Mbyte screen memories and drives three

S13MMI11
488

Man-Machine Interface and Workstations
488

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI11

6. CONCLUSION
FGS has given us an easy and speedy development ofgraphic presentation in the control system. It has also realized
an effective use of limited resources of display monitors,
owing to its picture stacking architecture.
We now have three display monitors with a single DP1000, and are planning to add one more DP-1000; sixmonitors will eventually be available.
The FGS mechanism is strongly dependent on ourhardware and software environment such as computers, display
stations, network, operating system or programming
language. Although it will therefor be difficult for othercontrol systems to adopt FGS as it is, its conception may be
useful for them.
7. REFERENCES[l] Paper is in preparation.
[2] C. 0. Pak, "The Control System of the Photpn Factory
Storage Ring", Nucl. Instr. Meth. A277 (1989) 501.

S13MMI11
Man-Machine Interface and Workstations

489

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

refresh, the adjusting analog signal value by touch panel
or encoder, the creating system control command, the entering a submenu, the exiting to a last menu, the turning
to a pointed page and the calling user's program, DOS
command or speech library.

acquire the dl,),tum of digital signal and analog signal fromthe database of central computer.
The DM display is to process and display the digital
signal according to the user's setting message from setting
file. Similarly, the AM display is to process and di.splay
the analog signal or TV graph color code signal from thedatabase of central computer, then to process and display
at the region which the user defined in the setting file.
The touch panel process is to respond to opera.tor's instructions, to make the special treatment according to theuser's definition in the setting file, for example, it can turnto the other page, or entry the sub-menu (Each page has
98 aubmenu, on screen can display 4 submenus at the sametime), return to the last menu, and send the control command to central computer etc.
The Executive Program has three running modes, these
are Test, Review and On-line Teat. At the Teat mode, theprogram generate every kind of data for checking the user's
configuration. At the Review mode, the program provides
the user to review the previous operation datum; and at
On-line Test mode, the program obtains all kind of datafrom the database of central computer, and refreshs thedata display every second.

This program is designed for explanation of various specification, machine operation such as operation guider. Also
it can be used for warning some events such as" High Voltage Current is over, Please pay attention!".

III. APPLICATION

I
I

!

ns

TOUCH P.\HEL~::::-~====-?-11,_0C~ESS!HG~
no-,of Exacutlon Program

In genera.I, an accelerator physicist can write the best program to resolve his physics problem as he understands
better than software people. Therefore, he must study
a long time about system configuration software and thenhe should understand the data path from controlled equipment to database and console display. But sometime, it isdifficult for those specialists or physicists who are not familiar with system configuration software. They wouldn't
like to resolve his problem by paying too much time tounderstand the whole configuration software. Considering this reason, comparing various interactive methods andour experience of accelerator operation, a set of utility in·teractive tools are used for control system of PLS 60Mev
LIN AC. The hardware environment of console interface isillustrated in the Fig.3. In the normal case operator caninteract in four ways:*Digital command could be through touch panel* Analog control are adjusted by digitalized encoder ortouch panel
Various digital signal and parameter of accelerator are
shown on the graphic screen.
The voice explanation are used for warning some emergency events to operator.
The major procedure of system configuration using
MMISP as following:
1.Picture edit
Graphic picture displaying various physical requirements
can be edited by PAGE EDITOR easily just as in CAD.
At first, designer should make definition of index pageand chapters such as dividing modulator-klystron chapter,*

D. The Executive ProgramThis program is the core of MMISP. lt is of six parts, shownas Fig. 2. These are the load page & setting file, thedata communication with the central computer, the DM
display, the AM display, the wave & graph display andthe touch panel processing. The loa.d page is to display
the user's page and to get the configuration informationfrom the page setting file. The data communication is to

S13MMI12
Man-Machine Interface and Workstations

491

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

G.Speech Program

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI12

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

beam diagnostics chapter etc. Second, to indicate thoseregion which show parameters and control buttons using
PAGE EDITOR.
2.Setting I/0 signals
Since every signal has its own system signal name, itis easy to point to a position on the designed page. It
includes status indicate (DM), status control (DC), analog
parameter display and control.(AM and AC)
3.Waveform and TV graphic setting
In the normal accelerator control, there are many waveforms such as klystron pulse voltage, pulse current etc. Itvery easy to configure and record as storage oscilloscope.
4. The function of voice explanation is useful to remindor warn operators to pay attention to accelerator.

V. REFERENCE[l] n1nstrumenta.tion & Control System for PLS-IM-T 60Mev
LIN AC", Contributed to control con[erence November 1991
[2] K.Naka.han., I.Abe, K.Furuka.wa and N.Kamikubota.,"An Opera.kn- Console system o[ the Photon Factory Injector
LINAC" Nucl. Instr. and Meth. A293 (1990) 446-449

To Main Computer,.......---JL---

HD 4al4
WI 2M

CPU 286

ng3. Hordwore Environment

IV. CONCLUSION
On other hand, this MMISP could be used in any control
system as a movable console which can be linked to computer network using a communication board inserted to
PC bus.
Sununarized performance of MMISP is follows:* Easy operation as CAD software* Five kind of digital signal display; 150 signals could be
used for one page
* Six kind of analog signal display; 150 signals could be
used for one page
*Ten function of touch panel definition; 150 touch region
Car one page* 10 waveform and 10 graphic display (30K points/1
picture)* 98 sub-pages for one main page
* Easy to add new page into edited user system on realtime

S13MMI12
492

Man-Machine Interface and Workstations492

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

~552.391
B -1768.0·93
STD DEV
4.854
0.1529--0.3425 .Q.1480
D

A

~
40
c:
.....

.E 20

'O 400

~

E
ct!

Q)

a>

0

~·~
~i\)l'\ ~tqi t11;1<trn ~·~<

ll·Q1

179.4

c

Q)

al

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI1370<3ASo.oz.
p~...o.o~ 00~\)iiu\)l'\v

Figure 1. Beam aperture is studied by measuring beam intensity while varying horizontal and vertical position.

?

j
j

300

200

100

UJ

,,..,

0

-20

0
Beam Position

20
(µ)

"""''

32 3.8<l.l

Figure 3.

>=

Control
The user may elect to use either one or two st.ep vari·ables. Most of the variables available to software control
have been implemented. Examples include:" Setpoints of magnets or other analog control de\'ices;e Klystron set points, including amplitude, phase, and Liming;• Timing delays for any triggered device;• Combinations of devices through the Multi knob facility;• Setpoints of feedback loops stabilizing the beam [3,1);
a Time.
For many experiments, the Time step variable provides asimple delay between samples, in order to study t.he tinw
structure of variations in normal running. Users cau study
correlations between sampled variables without modifying
any control parameters. Most of the time, only one slep
variable is used, so a third has not been considered nen·s·sary. When two step variables are used, they define a gridof values, and the second is stepped through the whol<'range for each setting of the first. Figures I and 2 are examples of plots with two step variables.

c:

e 3.4

.'!:
(/)

0

a.

3.0

Figure 2. Optimization of beam position on the positrontarget.

CAPABILITIES

Beam-beam deflection fit at the interaction point.

Monitoring
Correlation plot support is provided to measure or calculate a wide variety of data. Up to 160 variables may besampled within a single acquisition sequence, and up to
100 data points are saved for each. At the current time,measured parameters include beam-related data from po.sition monitors or toroids, and analog values from devices Data Reduction
such as klystrons, magnets, thermocouples, and vacuum
To aid in the analysis of the data, a variety of lit·
pumps, etc. For klystrons, in addition to simple analog ting routines may be selected. The selection of fitting alvalues, the user may sample values derived from an analgorithms may be accomplished through the user interface
ysis of the 64-pulse Fast Time Plot, such as phase andamplitude jitter, energy gain of the station, or perveance. (touch panel) or by application software. Fig me 3 sh ow,:;
This makes it possible to quickly scan the energy gain as the special beam-beam deflection fit used for optimizing
a function of klystron phase to find the optimum setting, collisions and estimating beam cross section at. t h0 int nor to map out buncher jitter as a function of phase-shifter action point.
setting in the SLC injector.
APPLICATIONSOther calculated quantities available include energy,
Varioussoftwareapplications used in the SLC ha\'cenergy spread, particle yield, and beam position or deflection angle at the interaction point. Residual dispersion at been built upon capabilities of the Correlation Plot facilthe collision point may be measured noninvasively by cor- ity. These analysis and control applications include therelating position and angle at the impact point with energy following:
fluctuations. In addition, interfaces to other applications 1. Multivariate correlation plots make it possible to visualize a wealth of data in a focused and informative wm-.
allow sampling of various derived quantities, such as beam
Figure 1 is a plot from a beam aperture study in whi(:listates calculated by feedback and beam sizes, emittancemultistep variables a.I'e used to study beam int.ensit.y inand skew parameters determined from wire scans, beam
three-dimensional space. Figure 2 is an optimizationscans, or profile monitor digitization. These quantities areused in a wide variety of beam optimization procedures.
study of beam position on the positron target. ll'liere

S13MMI13
494

Man-Machine Interface and Workstations

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI13

~ 260
~

Y-A x (X-B) 2 + C'ala"' 220140 .......~.......~~"'---~-'-~~........~---~~
-40
-20
-60
0
20
40
60
11-91

Klystron Phase (degrees)

Figure 4. An automated procedure optimizes
240 SLC klystrons.

2of thefeedback
are used to control horizontal andvertical beam position, and the application calculates
positron yield at each combination of setpoints.
:!. Data collection and optimization applications that calculate optimized values for klystron or magnet settings
are common. Figure 4 displays the fitted beam energy
offset for a single klystron, where an automated procedure steps through the devices, measuring beam energy
as a function of phase in order to determine the optimum
Figure 5 displays a parabolic fit of beam
widthfrom digitized profile monitor data as afunction of quadrupole magnet strength.
CONCLUSIONSThe Correlation Plot facility has proven to be an exLremely powerful tool for the analysis of accelerator functionality, device commissioning, and for building software
applications. The flexibility provided by the different typesof variables that may be controlled and monitored has
allowed opera.tors and physicists to rapidly
andexecute a vast assortment of experiments without any
new orsoftware. In fact, the Correlation Plots
are used so extensively that most experimental data presented comes from this facility, and it is Pvr.rPn1F
that data needs to be plotted offiine. Even forexperiments where further analysis is required, thelation Plots provide the data acquisition and online validation. The Correlation Plots facility has made an essential
11nd invaluable contribution to the SLC development.

-90

-70

-50

-30

1141

™""11

Quadrupole Magnet Strength

Figure 5. Beam emittance is calculated byaquadrupoleand fitting a para.bola to the estimatedbeam width

ACKNOWLEDGMENTS

The authors wish to thank Julian Kupiec, who \\'1'01
the originaland Miguel Flores, who 11dd0J nfeatures.
REFERENCES[1] K. Thompson et al., "Feedback Systems in the SLC, Proc.
12th Particle Accelerator Conf., Washington DC, !lla1cii
1987; SLAC-PUB-,1217.
[2} .M. C. Ross et a.l., "Wire scanners for beam size and emit·ta.nee measurement at the SLC," Proc. 1991 IEEE Particl('
Accelerator Conf., San Francisco, CA; SLAC-PUB-5556.
[3] T. Himel et al., uGeneral, Database Driven Fast Fee<lb;,,d:System for the Stanford Linear Collider, Proc. 19!Jl IEEESLA CParticle Accelerator Conf., San Francisco,PUB-5469.
[1] R. E, Melen, "Centralized Digital Control of Accelerators," Proc.
Conf., Berlin, \Vest Gemrn
September 1983; SLAC-PUB-3218.

S13MMI13
Man-Machine Interface and Workstations

495

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-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 Workstations496

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

ICALEPCS1991, Tsukuba, Japan

should give a feel and a consequentinstantaneous
und~rstandingof
thebeam-parameters to any kind of user.

buckets do not obscure one another to alarge extent. In order to bring hcime theeffect of orientation of the buckets ln
3-dlmenslonal space,
the four lateralsurfaces and the front surface of thebuckets are all to be painted in five
distinctly seperate colours (Figures 2 &The total transverse cross-section ofa beam can be thought of as composed of alarge number of cells, through each ofwhich a beamlet can be thought to be
emitted. Particles occupying a particularcell are characterised by 9
( ie.p (av
x av)
I p ) and ¢
(
le.
p
(
)
I p ) and henceav
y av
the direction of beamlet
ls represented
by these two averaged ·quantities.
Now each beamlet can be represented
by the figure of a solid (Figure 1) of the
shape of a truncated rectangular pyramid.
This bucket-like figure is capable ofcreating the impression of a directional
movement of the beamlet. The presentation
3-dimensional, the orientation of
the beamlet in both x and y directions canbedepicted.
Reducing
the ·arbitrary
cross-sectional area of the cell andincreasing the number of beamlets
over the transverse section of the beam
can create a picture in more detail.
The number of cells can be optimallychosen to produce a suitably accuratewith sufficient details andatthe same time care ls taken so that the3).

PROGRAM-OET AILS

The data about the particle density
and
their
momentum
distribution,asobtained either from the on-line emittancemeasurement devices or from transport
optimization codes ( eg. TRANSPORT, TURTLE,
GIOS etc.), ls assumed to be present ·in
The data file should be
disk file.
actually re-organized as an array ofrecords, each record having four fields.

FigureFigure 2.

A diverging

beam

3.

A converging beam

The field designators are as follows.
posn{ Array of X and Y
co-ordinates of the centre of a unit cellon the transverse plane of the be'am }xmom{Computed
averagemomentumin x-dlrectlon of all
theparticles in the unit cell }ymom{Computed
averagemomentumin y-dlrection of all
the

S13MMI14
Man-Machine Interface and Workstations

497

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

IMPLEMENT ATlON-PLAN

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI14

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 Publishingparticles in the unit cell }density{Total
numberofparticles in the unit cell}Someadditionsinthestandardtransport
calculation
programsoremittance-data acquisition programs aredone to organize the data in above format.
Inreality,themomentumangle
variations are typically in the range of
100 milliradian, a much too small quantity
to be visually resolvable. Hence, for the
purpose of our picture-generation, thisquantity has to be scaled up by a suitablefactor (typically 300) and a proportionate
variation in the angles of buckets canthen be made recognisable on the screen.
In the present version, in absence of
3-Dgraphic
generation
routines,
procedures were written in Turbo-Pascal
language to independently generate the X
and Y-rotation effects on the bucket andthen to combine to create resultant solid
figure. Standard algorithm was utilized toeliminate drawing of hidden surfaces of abucket at various orientations (1].
It was felt that though perspective
views of the buckets can give a clearer
perception, but with a 11 ttle experience
this loss of visual perception will not be
too damaging, to warranty taking up thesetime-consuming computations in a personal
computer. The other problem was to keep
the consistency of depth-perception when
buckets of varying orientations, overlap
one another. In other words, the sequencein which buckets should be drawn would
have to be a difficult and lengthy
algorithm,
in absenceof
any depth
information of the image. This information
is not kept in the present version, since
insufficiency of frame buffer memory in
our PC does not allow any 'benefit from
this
information,
during3-D
image
generation. A simpler scheme has beendevised to give satisfactory results.
Based
on
the
relativeco-ordinate
displacement of the tip of the bucket withrespect to it~ base, the bucket parameterrecords are divided into two groups, named
arbitrarilyas'converging'and'diverging'. Then each group is.internallysorted according to increasing radial
distance of the centre point of the baseof the bucket. For 'converging' group,
bti.ckets are drawn starting from thebeam-centre of the cross-sectional area
towards the periphery whereas for the'diverging' set, they are drawn in thereverse sequence. As far as the individual
sets are concerned, buckets within thatset overlap in the right May.

doi:10.18429/JACoW-ICALEPCS1991-S13MMI14

FUTURE EXPANSION

A 'zoom'
optionwill
allowa
progressive blowing up of the. figure,enabling more detailed observation of
selected zones of· the beam-section. This
option will be helpful if the buckets fillup the space too densely so as to ob~truct
view of the buckets in the background.
A cross-hair cursor (figure 4) can be

Figure 4. An integrated beam-view
taken to any point on the figure andclicked. There would be two output windows
which will show the particle population
distribution along the· x~axis and thatalong the y-axis of the current cursor
position, thus creating the scope forrealisation of relative distribution" ofparticles also. Two other output windows

S13MMI14
498

Man-Machine Interface and Workstations498

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

ICALEPCS1991, Tsukuba, Japan

can give the output in the form of thestandard phase-space ellipses, for the
total beam at the particular longitudinallocation in the beam-line, thus creating
an integrated view of all parameters ofinterest of a particle beam.
Insuitablecases,
animatedmovie-frames[2]
can be generated tosimulate the dynamically changing beamcharacteristics, because of disturbances
introduced naturally or otherwise.

Such views are expected to give an
immediate impression about a beam at any
place and can trigger the lntutlve processof manlpulat~ve operations necessary. on
the beam. In other words, the idea ls a
step in the line that a computer should
provide the designer as well as theoperator, facilities to visualise the beamin an integrated way to closely match his
own way of perclevlng the beam.

The authors are thankful to Dr. P.K.
Sarkar for some active discussions andfruitful suggestions. Shri R.B. Bhole hasvery laboriously helped in testinganddebugging of the codes. We shall like tothank him.
REFERENCES
[1]

N.M.

Moris,

Computer Graphics & CAD

BBC Mlcroverslon, p.159
AlfredoLucclo,"Algorithms
andModelling For The AGS Booster", Nucl.
Instr.
and . Meth. ,
Vol.
A293
(1990), pp.460 - 463

Fundamentals,[2]

S13MMI14
Man-Machine Interface and Workstations

499

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

ACKNOWLEDGEMENTSDISCUSSIONS

The idea of the development ls toincorporate
thecomparatively
easieraccessibility of 3-D graphics in theuser-interface area of certain computer
programs used in accelerator design andcontrol,andtore-lnforce
thestandardized outputting style with a more
physically revealing style. The results
obtained in the current work, though, aresufficiently useful for trained eyes, yet
for those who can afford using powerfulgraphic workstations, they can apply thesame idea and can get more realistic3-dimenslonal views.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S13MMI14

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

Staff Experience
The programmers had already mastered the details of thecontrol system infrastructure. New staff hired for the Booster
Project were given adequate time to become familiar with thecontrol system before learning C + + and addressing the new
Booster-specific programming assignments.

C+ +Lead Programmer
The staff was seeded with one experienced c+ +programmer
to serve as in-house consultant and mentor. During the
succeeding year, the staff members' primary responsibility
became their Booster assignment, and as they addressed thisassignment they adopted C + + as their design language. A
C+ + culture was established within one year, and a classlibrary rapidly accumulated which functioned as a peerdeveloped resource of programming models.

Classification of Classes
The class library was recently examined to acquire asnapshot of its contents (which are still expanding). The
contents have been categorized according to the type ofservices which the classes offer.

Operating System Services
GUI Services
Control System Services
Data Acquisition, Display
Device Tools
Accelerator Tools
Accelerator Physics Tools#Classes
14
4
22
17
12
16
7

36
22
60
53
28
87
44

Although the class library contains a large number of classes,
many of these are intended only for internal use by the tool
modules; a programmer wishing to use these tools needbecome familiar with only a few classes at a time.

Some samples are offered of the classes in each categoryof the class library, along with some methods (function
members) defined for them, in order to exhibit the ways inwhich these classes are applied. The format in this table issimilar to the C + + code from which these examples were
derived:a class-definition line ("class ClassName") isfollowed by a number of lines defining methods for the class("ClassName::method"). The formal parameters (arguments)
for the methods are not displayed, for the sake of simplicity;
likewise, most of the synt.ax of the C + + language is
suppressed, although class derivation is exhibited.

Accelerator Tools - A Special Niche
An object-oriented approach to design of the "accelerator
tools" category seems to offer a special opportunity for
programmers in an accelerator controls environment. It is
often the case that the architecture of the control system
imposes constraints on the hardware designers, constraints
which cause the elements of the accelerator to be artificiallyfragmented into multiple "devices", or "control systemprimitives•. In the AGS control system, the control systemprimitive is called a "logical device". As an example, theengineer designing an interface for a multi-wire profile
monitor or "harp", was obliged to implement the timing
control as one logical device, the gain control as a second
logical device, positin control (insert/retract) as a third logicaldevice, and acquisition of the profile as a fourth logicaldevice. Moreover, gain and timing control were shared
among a collection of several harps in the same beam line.
This complexity is by no means unusual, and is a common
consequence of the necessity to standardize control systemarchitecture and to solve difficult accelerator design problems.

With an object-oriented tool to support program interaction
with a harp, the complexities resulting from the multi-device
interface can be hidden inside the class design. The high-level
programmer can then interact with a single entity-the harp
object--and function much the same way the physicist does
when he views the harp as a single component of theTable I. Class Samples ~ Operating System Services
Class SharedMemory
SharedMemory: :GetLock
SharedMemory: :ReleaseLock
Class MbxMessage
Class ApolloMail : MbxMessage
ApolloMail:: ServerGet
Apollo Mail: :ServerPut
ApolloMail:: ClientGet
Apollo Mail: :ClientPut

II
II
If

Mailbox Message
derived class from MbxMessage
server access to mailbox

IIclient access to mailbox

S14OOP01
Object Oriented Programming & Techniques

501
501

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 DOIClass Examples

among the staff to define and develop generic object-oriented
tool packages.

Class Category

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP01

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

Table II. Class Samples - GUI Services
II
/I
II
11
11
/I
11
II

Class PopupMessage : GenericPopup
PopupMessage: :display
PopupMessage: :display_mono
PopupMessage: :display_ok
PopupMessage: :ask_yn
Class PopuMenu : GenericPopup
PopupMenu: :getchoice
PopupMenu: :getchoices

derived class from Generic Popup
display in proportional fontdisplay in monospaced fontdisplay and await confirmation
ask question, get yes/no reply
derived class from Generic Popup
get a single choice
get multiple choices

Table III. Class Samples - Control System Services
Class Alarm
Alarm::Log
Alarm: :DeLog
Alarm:: Priority
Class Sid : Alarm
Class Controller : AlarmII
II

Log in database
DeLog from databaseII
II

alarm for Sid (Simple Logical Device)alarm for Controller

Table IV. Class Samples - Data Acquisition. Display
Class SldRequest : DataRequest//
derived class from DataRequest
This class is not exported to the public; it is used by DataCollector
Class DataCollector
D ataCollector:: settimeout
set timeout period
11
DataCollector: :setup11
set up list
DataCollector: :getrequest data, wait until it arrives
11
Datacollector:: getimmediate
Datacollector: :getsynchronizedClass GraphMonitor : Monitor
GraphMonitor:resize
resize the graph
11
GraphMonitor:: title
display routinesII
GraphMonitor: :writelabel
GraphMonitor: :writecycle
GraphMonitor: :hardcopy
hardcopy to printerII

Table V. Class Samples - Device Tools
Class FunctionGenerator
FunctionGenerator::menu edit
FunctionGenerator: :load
FunctionGenerator:: readback
FunctionGenerator::set cld names
FunctionGenerator: :set default value
FunctionGenerator: :set start
FunctionGenerator:: set end
FunctionGenerator:: set_ timing_cld_names
FunctionGenerator: :set tolerance

II

/I
II
II

edit function
load it to devices
read the devices
names of complex-logical-devices

S14OOP01
502

Object Oriented Programming & Techniques502

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP01

Table VI. Class Samples - Accelerator Tools
Class Instrument
Instrument: :calibrate
Instrument: :acquire_data
Instrument: :display_data
Instrument: :save_data
Instrument: :read_data
Class HARP : Instrument
HARP::insert
HARP::retract
Class BPM : Instrument
Class XF : Instrument
Class MagnetCalibration
MagnetCalibration::ReadCalibrationDataFile
MagnetCalibration: :Interpc>late
MagnetCalibration:: Readival ues
MagnetCalibration:: ReadBvalues
Class Transient Recorder
T ransientRecorder: :GetLiveReadback
T ransientRecorder:: SaveLiveReadback
T ransientRecorder:: GetSavedReadback
TransientRecorder: :Display Read backII

multi-wire profile monitor

II
II

Booster Position Monitor
Transformer

Table VIL Class Samples - Accelerator Physics Tools
Class ManualHarmonicsCorrector : OrbitCorrector
ManualHarmonicsCorredor: :set harmonic
ManualHarmonicsCorrector: :set_pue_display
ManuaIHarmonicsCorrector: :display_setpoint_hannonics
ManualHarmonicsCorrector: :display_readback_harmonics
ManualHannonicsCorrector::increment coefficient
ManualHannonicsCorrector: :execute correction
Class BoosterOrbitBump
BoosterOrbitBump: :magnet_device_list
BoosterOrbitBump: :pue_device_list
BoosterOrbitBump: :what_bump_order
BoosterOrbitBump: :what_bump_type
BoosterOrbitBump:: magnet_read backs
BoosterOrbitBump:: magnet_measurements
Class TuneModel
TuneModel:: WriteTunelntoSetpoints
II
TuneModel: :ReadSetpointslntoTune
II
TuneModel: :StartMad
II
TuneModel: :TestMadDone
TuneModel: :GetTwissAtElement
11
II
TuneModel:: DisplayTwissAtElement
TuneModel: :DrawBeamLine
II
TuneModel: :DrawEnvelope
II
TuneModel::DrawApertureII
TuneModel: :DrawPhaseEllipseAtEiement

Send setpoints to devices
Read setpoints from devices
Run modeling program MAD
Get Twiss params from model
Popup Twiss param display
Iconic display of beam line
Draw beam envelope
Overlay magnet apertures

S14OOP01
Object Oriented Programming & Techniques

503

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-S14OOP01

accelerator. This opportunity for class design to offer a cleaninterface to accelerator components is characteristic of theseaccelerator tools. With proper class design, a high-level
program can be coded to read as cleanly as the designer's
statement of the program function.

Acknowledgments
The work discussed here was developed over the last two
years by the entire staff of the Controls Section of the AGS;
their contributions made this report possible, and theircooperation made the work a pleasure.

Reference
1. W.T. Weng, Construction and Early Commissioning
Results of the AGS Booster, 1991 Particle Accelerator
Conference (in press).

S14OOP01
504

Object Oriented Programming & Techniques504

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

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

phases of KF-CCS planning a more general fonn of modelling
would have been extremely helpful in understanding the operation of the KAON Factory. With this knowledge in hand, one or

known to most people. Thus, for example, no-one would consider "Magnets" as being part of "Banking".
We can capture the essential details of a domain by making
models. These models take many different forms, for example:• written text, for qualitative domains like medicine, or• written text with embedded mathematical fonnulae, forquantitative domains like physics.
These models usually describe a domain in terms of fiveimportant types of knowledge, namely:• concepts used by experts working within that domain,• facts about the individual concepts,• facts relating two or more concepts,• interactions that occur, and• events and conditions that cause interactions within thedomain.
This time honoured approach to describing domains, in termsof the "things" that experts believe are part of the domain andthe relationships between them, has recently been called "theobject-oriented approach" by designers and builders of softwaresystems. The object-oriented approach has been gathering substantial support from vendors and builders alike in recent years
due to its uniform manner of modelling both problems andMaster Timing
SystemJACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP02

Master Timing
SystemFig. 2 The Object Commwrlcation Diagram for Fig. 1 (inllide the bubble) represents the composition of the KF-CCS in terms of system-objects and the infonnation flows between them and the external
Terminlltor Objects.

more systems analyses could have been performed to ascertain
the suitability of automating various tasks as part of the KF-CCS.
Models that allow the precise description of what is required
to be accomplished in a particular field of interest and when, but
regardless of how it is to be carried out, are tenned domain
models. A complete KAON Factory domain model would show
the desired behavior of the KAON Factory regardless of whether
control systems had been constructed to achieve the behavior orwhether the devices naturally embodied the required behavior.
To precisely define the nature of domain models and their use incontrol system building, a brief introduction to domains follows.
ill.DOMAINS
One way humans organize their knowledge of the world is interms of domains e.g. the domains of banking, physics, art, law,ete. A domain serves as a context within which technical tenns
and expressions usually have a single meaning; for instance, theexpression "The grounds are fine." has completely different
meanings in the domains of electronics, gardening, debating andcoffee making. The term "domain specific language" highlights
this re-use of old words, with new meanings, as an appropriatemanner of describing a domain.
Domains can include other domains (e.g. divorce laws arepart of all laws), can overlap other domains or be completely
independent of each other. The contents of a domain are determined by a set of criteria tenned Domain Criteria. It is implicitly
understood that the criteria for common-place domains are

Fig. 3 The Super-Context Diagram of Fig.1 illustrat.es the "fit" of the
KF-CCS into its inunediate environment.

solutions, and the availability of languages that support"software objects". The support has been a "grass roots" movement, arising initially from an understanding of the benefits
accrued by using object-oriented programming languages on a
project; and later expanding to encompass the earlier analysis
and design modelling phases of a software project
IV. DOMAIN BASED MODEU.ING
One can "view" domain based modelling as being one more
step down the historical path of increasingly structuring systems

S14OOP02
506

Object Oriented Programming & Techniques506

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

ICALEPCS1991, Tsukuba, Japantheir construction. Originally, coding was performed inmachinelater in assembler and today in FORTRAN-likelanguages; structured programming, s!ructured design, objects

Interaction(OID); to model the causal
relationships between the entities.
Domain models are, therefore, models of an entire field ofknowledge in the same way tlUl1 "PV-nRT" is a physicist's
model of an Ideal Gas (a model which could be incorporated into
an object-oriented domain model ofldeal Gases as "viewed" byphysicists).
Domain models can only be validated by:• experimenting with physical entities in the domain (e.g.
RF cavities and Magnets for KAON), or• questioning domain-experts about conceptual entities inthe domain (e.g. a Beam Schedule, Startup Sequence),and comparing the results with predictions from the domain
models. In like m.annec the completeness of domain models canonly be established by consulting a domain expert; but once thedomain models are deemed complete and valid they can serve
as a re-usable resource for projects undertaking the automationof activities in the domain. Domain models serve as the only
criteria against which the "correctness" of any automation
project is established .

are:Extended Entity Relationship Diagrams (EERD); tomodel the entities and concepts in a domain, their properties and lhe relationships between them,• Staie Transition(STD); to model the modes of
behavior of each entity and the causes of transitions between the modes,• Object Structure Diagrams (OSD); to model the processes
inherent in each entity and how these effect entity properties and behavior,

V. MODEILING IN A DOMAIN
To manage the complexity of modelling in a given domain
an observer should represent the domain from a parti.cular viewpoint 'Those features that lhe observer deems essential to thevwWO«Jmt must be included in ilie models while all other irrelevant features are omitted. The resulting model is a particularabstract
domain. The most important viewpoints ofa domain, termed the Canonical Domain Views, are those of thedifferent types of people working in the domain.
The domains relevant to the builders of the KF-CCS weremost
identified from an analysis of all personnel that will
be involved in the production of the 30 GeV proton beams [3].
Asare frequently assigned multiple jobs, thefocussed on eliciting the roles to be played by those personnel inoroduc:ini;z beam. The view of the KAON
perceived byany person
out arole defines a description ofsome relevant (caoonical) domain. As several roles often share
a common or similar view of lhe KAON Factory it follows thatthe number of Canonical Domain Views is limited by the numberof roles identified.
An example KAON
domain-model4) clearly shows the r..1aster Timing System (MTS}, its
interaction with each beamline device and wi!h an Otx~rntl:>r
Personnel assuming the latter role use the MTS to tune the beamin the synchrotrons after all beamline devices have been turned
on. Unlike in Fig. 1, thisdomain model does not distinguish between lhose functions carried out by hardware orsoftware, and corresponds to lhe way Beam Physicists describe
the operation of the KAON Factory.
A complete model of the domain, formed from a union of theCanonical Domain Views, is termed Uie Canonical Domain
Model.

S14OOP02
Object Oriented Programming & Techniques

507

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

and applications were more recently created to manage thecomplexity of large software systems.
A moreunderstanding of Ibis structuring can beobtained by "viewing" it as successful attempts at constructing
new domains wilh associated domain specific languages. The
elements of each new domain were abstractions of useful features from older domains; lhus Structured Design highlighted thecomposition of programs from procedures calling other proced1m11 and passing dalalcontrol coupks. Its approach was language independent in that it abstracted away the details of any
procedure's implementation but maintained the usefulness of
being able to consider groups of statements as producing definite
results from given inputs.
All tr.!!iditlonal and most contemporary, conunercial.ly available object-oriented development methodologies and languages
arenot domain based in that they do not recognise theexistence of domains and their Domain Criteria. In solving a.-.............. problem it is, therefore, possible to incorporate any
what-so-ever into the solution domain. It would strike
most of us as being unusual if asystem specification
requiredbut it does not seemthat a "Control
Sf.1C1[:l1U::at1.1:in should require "VME«.
Both of these
violate the basic structwinR
any domain driventhat attempts toof elements of a(the nroble:m -~··--·,
with elements of asolution (the solution domain).
Most control systems builders support this domain-driven
de">'el01pment heuristic but express it in terms ofdesigns for control systems - a layer's contents,
modifiable without affecting adjacent[6,7]. In suchdesigns, elements from one
do not appear in otherlayer.
e.g. tUtworlr:. links inside the
iuuuvuw•" in a scientific domain has oft.en led to a fonnal
mathematicalof thebetween theimportant concepts in the domain but to a completely informal
treatment of the 4 other types
is a
CA<1u1vu;: of this mooolllin,g """'''"""''hOl:l1ect·-on,enttxi at>Prc'8Cn to modelling in a domain seeks
to redress this imbalance and reduce the emphasis on relationTo achieve this goal, object-oriented domain analysis
embodies a number of model-types that are unfamiliar tophysicists and to most builders of automated systems. The
models-types tlUl1 capture the five types of knowledge, cited

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP02

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

VI. CANONICAL DOMAINS RELEVANT TO
CON'IROL SYSTEM BUILDERS
In the K.AON Factory domain, which is concerned withdelivering a 100 microampere proton beam to 30 GeV, thedifferent types of personnel involved [3] have been used to
identify several canonical domains, for ex.ample:• the beam-delivery domain; in which K.AON Factory
Operators and Beam Physicists concern themselves withproducing an optimum 30 GeV proton beam and gaining
an understanding of the synchrotrons,• the equipment management domain; in which Equipment
Specialists coocero themselves with monitoring and controlling devices required to deliver the proton beam,• the KF-CCS equipment management domain; in which
KF-CCS electronics technicians concern themselves withmaintaining the equipment related to the KF-CCS operation,• the KF-CCS implementation domain; in which KF-CCS
Managers, Analysts, Designers and Programmers concern
themselves with the construction of software according to
specifications deduced from the above domains.
Clearly there are relationships between these domains. The last
2 domains are solution domains for problems arising in the first
2 domains, but not vica versa; that is, in trying to implement therequired behavior of K.AON Factory beam transport devices,
when delivering beam, it is easiest to employ lntellige nt control
system technology to control relatively rm-intelligent, passive
beam transport devices.
We noted earlier that the requirements for the KF-CCS could
have been derived by performing a systems analysis on a relevant
K.AON Factory domain model, had it been available. Similarly,
the requirements for the KF-CCS Implementation could bederived by performing:• a domain analysis of control systems implementation technologies, followed by• a system analysis of the domain to highlight the separationof control system functions between available hardware
and software.
The latte.r analysis was performed during the 1989 K.AON Fae,
tory study for hardware costing purposes, while the former
analysis is presently underway.

The executable images are run within TASKs by a CPU in a
PROCESSOR MODULE. They communicate with each using
ITCs (inter-task communication links). if on the same processor,
and LAN LINKs if on different processors.
:Each beam transport and beam diagnostic DEVICE is interfaced to the processors by a single DEVICE I/O MODULE
placed in a VME CR.ATE
Processors have 2 types of storage: CPU MEMORY inside
the processor and disks mounted in DISK MODULEs. The
fonner provides volatile storage that is lost whenever power
fails, the processor fails, the processor is removed etc., while thelatter provides persistent storage that survives such an occurren-

VII. CONTROL SYSTEMS IMPLEMENTATION DOMAIN

Control systems experts are well aware of their domain ofexpertise. Figure 5 shows an (incomplete) EERD of a traditional,
generic central controls system implementation domain, highlighting the major entities in the domain and some of the relationships between them. A short explanation of the EERD follows
with the entities capitalized for ease of reference the first timethey are referred to.
All working DESIGNERs and PROGRAMMERs use
WORKST ATIONs to create the source classes from the CON1ROL SYSTEM SPECIFICATION. The implementation language, represented by COMPILER, is object-oriented,
supporting the separate compilation of SOURCE CLASSes thatare then linked intoan EXECUTABLE IMAGE by the LINKER.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP02

ces.

/

I

I

I
I

Fig. 4 The Object Interaction Diagram for Fig. 1. This domain modelshows the entities in the domain as circles. Heavy, directed lines areenergy flows while thin-solid and dashed lines me information flows,

VIII. MAPPINGThe CON'IROL SYSTEM SPECIFICATION entity (topright of Fig. 5) is a model of a control system to be buill To
simplify discussions we will postulate this to be fully describedby only one model type, namely an Object Communication
Diagram (OCD); Fig. 2 for example. The OCD is, in tum,composed of:• a set of SYSTEM-OBJECT MODELs,• a set of SYSTEM TERMINATOR MODELs, and• a set of all INTER-OBJECT FLOW MODELs describing
information flows between System Objects and between
System Objects and Terminator Objects.
In addition, each SYSTEM-OBJECT MODEL describes:• the INTRA-OBJECT FLOWs accepted by the object,• the PROCESSes required to convert input flows to output
flows andS14OOP02
508

Object Oriented Programming & Techniques

nQl'fllal

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP02.

relationships

Relationship DUigram of a traditional controls system implementation domain. Entities in the domain
describes the type of relationships between entities.

• the information needed be STOREd to satisfy the
PROCESSes.
Each of the above models is a description of a particular typeof need that entities in the implementation domain must fulfil.
That is, we must find entities in the implementation domain thatare capable ofas required by the models. This
association of a model with rui implementation entity is termed
ma1wtmt. Perfonning a mapping (i.e. translating) is similar tocompiling the description of an algorithm, in a high level language, into an equivalent
in an assembler language.
The latter could , in tum, be assembled, linked and executed.
To illustrate the notion of mapping we will consider thevarious ways of implementing a CONTROL SYSTEM
SPECIFICATION using our suite of implementation entities(Fig. 5).
When all system-object PROCESSes are of the discrete
variety and we are using a traditional processor, we can map{denoted by the"-->" symbol) these models as follows:• both typ...s of "flows" ·-> the MESSAGEs accepted by a
SOURCE CLASS,• "processes" -·> the METHODs of a SOURCE CLASS (anamed-method is invoked by the class receiving a message
with the same name), and• "stores"--> the INSTANCE VARIABLES of a SOURCE
CLASS,
system-object model" -> SOURCE CLASS,•,. "control system specification" --:>APPLICATION, and• "terminators" --> DEVICE IIO MODULEs.
This mapping implies:• the control system software is a single application pro.
gram,
• that it deals with events in the real world sequentially, and• that all tenninator
modules must be in the same VIVi.E
crate.
In a large control system this latter implication is unacceptable. The distributed nature and quantity of terminators will
require a large number of terminatar IIO modules in several
VME crates to interface them to the application software. A local
processor will also be required in each crate to access the J/O
modules in that crate. The relevant application software mustalso be running in that processor.
From the OCD of Fig. 2 one can see that the simplest choiceof application software to be run in a particular processor mustcorrespond to the system-objects for the tenninators interfaced
into that crate. Flows between each terminator and the processor
would then occur within the single crate.
With this choice of allocating system-objects to processors
the original single program now becomes fractured into several
programs. Now flows between these distributed system-objects
cannot all be mapped to messages; those between objects on
different processors must be mapped to LAN LINKS.

ft

S14OOP02
Object Oriented Programming & Techniques

509

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 Publishing

Now consider the changes required when some PROCESSes
are CONTINUOUS TRANSFORMs. As these processes must
be able to proceed independently they must be mapped to
TASKs. In addition the INTRA-OBJECT FLOWs to theseprocesses must be mapped to ITCs (inter-task communication
channels). Now a single system-object may be distributed acrossseveral tasks, and there is no reason for these tasks to reside ona single processor. If a system-object is fractured across proces·sors then its INTER- and INIRA·OBJECT FLOWS must be
mapped to ITCs and LAN LINKs.

X. CONCLUSIONSThe possibility of generating a mapping directly from acontrol system specification now seems feasible. It relies upon:• detailed domain and system models of the control system
implementation architecture (e.g. Fig. 5) and either• a detailed mapping scheme that captures the experience ofcontrol system designers, or• a calculable figure of merit associated with each mappingthat could be minimized, say, to produce the "best" design.
Commercial code generator products have been available forseveral years that are capable of creating executable systems
directly from structured designs. They are feasible because thecommercial computing domain is very mature and code generators tend to work with mainstream transaction management
products for which all interface software is provided.
It is timely to pursue the goal of developing control systems
at a higher "level" of abstraction. There are many benefits to begained by leaving the "technical details" to a new form of"compiler" in much the same way as assemble: programs were
replaced by high level language programs. The final products
will be more uniform in design and more adaptable to technology
changes by "re-compilation". Future control system development work at TRIUMF in support of the KAON Factory will bedirected toward developing such a "control system compiler".

doi:10.18429/JACoW-ICALEPCS1991-S14OOP02

IX. PERFORMING AND EVALUATING THE MAP
Given an application program, implemented as a set of traditional communicating programs running on a set of processors,
there are many reasons for selecting a particular arrangement ofprograms to processors. Criteria such as:• access to critical resources e.g. particular 1/0 modules,• communications volume to and from critical resources,• response times to events,• meeting deadlines (in hard real-time systems),• computational "volume" per mode of operation,• computational "volume" per event,• processor~s capability, capacity and reliability,• storage capability, capacity and reliability,• network capability, capacity and reliability,
play important roles in determining the positioning of programs,
regardless of operating system and languase issues.
The mapping process, described above, leads ultimately tothe allocation of parts of SYSTEM-OBJECTs to multiple (subapplication) programs. To simplify the establishment of thismapping, initially, we have studied the case in which:• system-objects were not fractured smaller than individual
PROCESSes, and• all PROCESSes communicating with a terminator via its
IIO module were allocated to processors in the same crate.
The number of application program fragments to distribute isthen large but finite. We are presently investigating an algorithm
that would produce a "best" arrangement of programs amongprocessors by minimizing a "quality factor". The "quality factor"
depends on the values of all of the properties listed above. These
values will all be available from a control system implementation-domain model presently being completed for the KAON
Factory.
The simple mapping model presented here has difficulties
accounting for certain properties required by some systems - forinstance "fault tolerance". In a fault-tolerant system one would
require copies of a program to execute on different processors a feature that would increase the amount communications overa solution in which all copies were allocated to the same processor. The role ofa processors "reliability" property in the "quality
factor" must be, therefore, to "repel" copies of like software.

XI. REFERENCES[l] D.A. Dohan, G.A. Ludgate, E.A. Osberg, S. Koscielniak and C.
Inwood, "Definition study of the TRIUMF KAON FrictDry control
system project", Proceedings ICALEPCS '89, Nucl. Instr. andMeth. A293 (1990) 6-11.
[2] C. Inwood, O.A. Ludgate, D.A. Dohan, E.A. Osberg and S. Koscielniak, "Domain-driven specification teclmiquessimplify the analysisof requirements for the KAON Factory central control system",
Proceedings ICALEPCS '89, Nucl. Instr. and Meth. A293 (1990)
390-393.
[3] E.A. Osberg, G.A. Ludgate, S. Koscielniak, D.A. Dohan and C.
· Inwood, "Dynamic object modelling as applied tD the KAON
control system«, Proceedings ICALEPCS '89, Nucl. Instr. andMeth. A293 (1990) 394-401.
[4] J-L. Theron. "Design l!lldchecking of a large Ada real-time system''.
Proceedings ICALEPCS '89, Nucl. Instr. and Meth. A293 (1990)
373-376.
[5] G. Morpurgo, "SASD and the CERN Run-time coordinator",
Proceedings ICALEPCS '89, Nucl. Instr. and Meth. A293 (1990)
385-389.
[6] B. Kuiper,"Accelerawrconttol.s at CERN: some converging trends",
Proceedings ICALEPCS '89, Nucl. Instr. and Meth. A293 (1990)
308-31!1.
[7} P. Clout and A Deneels, "Report of the Los Alamos accelerawr
automationapplication toolkit workshop", ProceedingslCALEPCS'89, Nucl. Instr. and Meth. A293 (1990) 321-324.

S14OOP02
510

Object Oriented Programming & Techniques

510

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-S14OOP03

incorporated both the GNU [7) and InterViews (8) classlibraries into a development environment for user interface development. The process of incorporating, or linking
in, new C++ classes is discussed in some detail in a later
section. It is important to note, however, that no modifications to the C++ code is required. In fact, one does noteven need access to the source code in order to integrate a
C++ class library into the DMS environment.
Another reason for integrating the Lisp programming
language into the DMS tools is the opportunity to apply
expert system, logic programming, and other knowledge
based technologies in the development of domain specificdevelopment environments. Not only does the DMS tool
support the interactive construction of software solutions,but embedded rules and constraints systems can guide thesoftware developer in the correct manipulation and combination of software components into a needed solution.

Xllsp lnterrace Object

IFoolnterraceFuncttonO I--<

Methods:<Bar)

BarlnterraceFunc tlon() --<Baro;

Instance Variables:

C0 Polnter

Foo{a, b, c);lnstMica- Variables:

1var I, iVar2, ...

Figure 1: Interface between XLisp import object and C++
object.
The C++ pointer maintained by the interface Object to
its C++ object instance can be manipulated and passed
as an argument in other XLisp method calls. Thus, theaddress, or location, of a C++ object can be passed toother C++ objects. In this way direct interaction between
C++ objects can established once references between theseC++ objects have been passed through their interface objects. The importance of this direct interaction lies it thefact that once established, directly interacting C++ objects
can execute method calls with the speed of compile codein a traditional, statically linked, programming environment. Solutions to problems (application programs) arethen composed utilizing C++ objects which have been created and manipulated through their Interface Object instances.

II. THE C++-XLISP INTERFACE

The connection between the XLisp and C++ programming environments is accomplished by providing an interface between the Lisp and C++ run-time environments. In
general, a method call on a XLisp object is translated intoa call on a C++ object's method. This translation is accomplished by a C++ function, called the Interface Function,
which is generated specifically for the purpose of providing
an interface between the Lisp and C++ environments.
Each C++ class which is imported into the XLisp environment is interfaced to DMS through an XLisp class. An
XLisp class which imports and makes available a C++ classis called an "import class". Each import class duplicatesthe set of methods that the C++ class provides. Whenan instance of an import class is created, the constructor
method for the import class constructs and makes available
an instance of its corresponding C++ class. An instance ofan import class is called an "interface object" and eachinterface object maintains and provides an interface to asingle instance of a C++ object.
An Interface Function is created specifically for eachclass/method combination and is responsible for translating the Lisp arguments provided to the XLisp method callinto C++ arguments which are passed to the C++ method
call. The Interface Function also translates the value returned by the C++ method into a Lisp variable which isreturned as the result of the XLisp method call on theinterface object.
When an instance of a XLisp Interface Object is created through the interaction of the user with the XLisp
programming environment, an XLisp constructor method
calls an "interface function" which creates an instance of
the imported C++ class. The pointer to this new C++ object is returned by the interface function and assigned toa pointer instance variable maintained by the interface object. This C++ pointer is then used as a target for all futureinteraction which occurs between the interface object andthe C++ object it maintains.

Co Object

Methods:
CFooabcl

III. ADDING INTERFACES FOR NEW
C++-CLASSES TO DMS
Integrating a new C++ class into the DMS image refers
to the process of integrating the class data structure andits methods into the DMS process (or image). This integration can be accomplished either statically or dynamically. Static integration is implemented by simply linking
the compiled object code which implements the class methods, data structures, and interface functions into the DMS
image at link time. Dynamic integration is accomplishedusing a public domain library called Did [4,3) which provides the ability to dynamically load and relocate object
code into an executing image at run-time. * The Interface
Functions needed for each method provided by an interface
object are generated automatically using the development
environment provided by the DMS tool.
The DMS development environment described in theabove figure provides the ability to integrate new C++
classes into a DMS supported programming environment.
The user wishing to integrate a new C++ class provides
a description of the class and its methods in a form very
similar to the typical C++ header declaration. This description is parsed for errors and is translated into a XLisp
class declaration and a set of interface functions for eachmethod in the C++ description.
•Dynamic integration is currently only offered in the Sun OS
environment.

S14OOP03
512

Object Oriented Programming & Techniques

512

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

ICALEPCS1991, Tsukuba, Japan

JACoW PublishingC++ Class Description

OMS Deve lcpment

Environment• XL 1sp Class Declaratlons•Interface Functions Declarations

Figure 2: Incorporating C++ classes into the DMS environment.
In the case of the statically integrated DMS tool, theinterface function declarations are compiled using the native C++ code development tools into an object code format. This object code is linked with the DMS object
code, along with the C++ methods to generate the desired
DMS programming environment. Also generated from theC++ class description are a set of XLisp class declaration which implement the import classes described above.
The._«e XLisp class declarations are loaded into a DMS environment when the tool is started.

IV. CONCERNS AND FUTURE DIRECTIONS
As noted, DMS is currently implemented as an extension to the XLisp programming environment. DMS runs
on on a variety of Unix workstations, and requires the X·window system to support its user interface. Also integrated with the tool is a text editor which allows the development and execution of XLisp programs in a mousedriven editing environment. Within the editor the user
is able to write XLisp source code with such capabilities
as parenthesis matching, multiple widows, and text select,cut, and paste operations supported through the mouseinterface. XLisp source code can be interactively executed
directly from within the editor by selecting and evaluating
the code of interest through the mouse interface. This feature is similar to Smalltalk's Workspace object, and allows
work sessions to be saved and restored.
The primary programming environment to have beendeveloped is an X-\Vindow user interface development environment based on the InterViews [8] C++ class libraryand our extensions to that library, called glistk [6]. Using this environment the user is able to interactively create and exercise user interfaces implemented as Inter Views
and glistk objects. In addition, glistk's provide an underlying inter-object communication mechanism that has also
been extended into the XLisp environment. Furthermore,
there are also XLisp PushButtons and other Lisp based
interactive objects. These Lisp based objects allow the development of higher level functionality within the XLisp

programming environment. In particular, general Lisp expressions can be executed when these objects are selected.
There are two main concerns about the current DMS
environment. The first is that XLisp, while providing
an object-oriented interface to Lisp, is not standard. We
would like to move DMS to a CLOS and Common Lisp environment. This would make accessible the rich and robust
environments and tools available with commercial Lisp implementations. We are currently evaluating a few different
options.
The second concern is actually more serious. Developing and maintaining a DMS programming environment isa reasonably complex process. When several dozen C++
classes are to be integrated into an environment, house
keeping and version control become complex and error
prone. Further, developing a new environment sometimes
requires a in-depth understanding of XLisp internals. In
the current version, integrating a new class involves several processing stages which could be combined into a few
simpler steps,
This situation could be improved in a couple of ways.
First, it should be possible to generate import classes andinterface functions automatically from C++ header files.
Another future enhancement would be to eliminate theneed to generate and link Interface Functions for eachmethod provided by an interface object. This might beaccomplished using a byte code interpreter which interprets a set of byte codes describing the types of arguments
expected for a method call and which uses these codes totranslate Lisp to C++ arguments and then performs theC++ method call.
References[1] D. M. Bentz. XLisp: An object-oriented lisp. version
2.0. Available as public domain software., 1988.

[2] F. Hayes-Roth, D. Waterman, and D. Lenat. Building Expert Systems. Addison-Wesley, Reading, Massachusetts, 1983.

[3] W. Wilson Ho. An Approach to Genuine Dynamic
Linking. Available as Technical Report.

[4] W. Wilson Ho. Did: A Dynamic Link/Unlink Editor,
Version 3.2.3. Available as technical report.

[5] G. L. Steele Jr. Cammon Lisp: The Language. Digital
Press, Bedford, Massachusetts, 1984.

[6] M. Kane, C. Saltmarsh, V. Paxson, M. Allen, and
P. Veals. The G LISTK Manual. Available as internal technical memorandum.

[7] D. Lea. The GNU C++ Library. Available from theFree Software Foundation.

[8] M.A. Linton, J. M. Vlissedes, and P.R.Calder. Composing User Interfaces with InterViews. IEEE Computer, 22(2), Feb. 1988.

S14OOP03
Object Oriented Programming & Techniques

513
513

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-S14OOP03

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingvia commands. Commands can be executed focally or remotely (i.e. across a network). Network access to a device
and its commands is provided by an application programmers interface using a remote procedure call.

startup time) and then stored in a database. The first timea client connects to a server it goes to the database to retrieve the server's address, after which it communicatesdirectly with the server.

3.2

3.4

The Device

The device is at the heart of the device server model. It
represents a level of abstraction which previously did notexist. A device can be a physical piece of hardware (e.g. aninterlock bit), an ensemble of hardware (e.g. a screen attached to a stepper motor), a logical device (e.g. a taper),or a combination of all these (e.g. a storage ring). Eachdevice h!!B a unique name. At the ESRF a three field namespace (consisting of DOMAIN/FAMILY /MEMBER)
has been adopted.
The decision of what level of abstraction a device represents depends on the requirements of the clients. At the
ESRF these are the machine physicists. Devices shouldmodel the clients view of the problem as closely as possible. Hardware dependencies should be hidden behind thedevice abstraction. For example if a corrector consists ofthree independant powersupplies the client (assuming she
is a machine physicist) should only see a single device the corrector, and not three independant devices.
All devices are treated a.s having state. Each device
has a list of commands which it understands. Before
any command can be executed the state machine getschecked to see if the command can be executed in thepresent state. The commands and the state machine are
implemented in the device's class.

3.3
Another integral part of the device server modei is theserver concept. The server is a process whose main task is
to offer one or many service(s) for clients who want to takeadvantage thereof. The server spends most of its time in a
wait-loop
for clients to demand its service(s). Thisdivision of labour is known as the client-server concept.
It exists in different flavours and is very common in modern
operating systems.
The adoption of this concept in the device server model
has certain implications. The server in the device server
model is there to serve one or many device(s) i.e. there
is one server per device but there can be many devices
per server. The exact configuration depends on the hardware organisation, CPU charge, and the available memory.
The fact that there can be many devices per server meansthat a single device should not monopolise the server for
more than a pre-defined amount of time. Otherwise theserver is blocked and new or existing clients will not beable to connect to the same or other devices served by thatserver. The server waits for clients by listening at a certain
network address. The mechanism for doing this is implemented by a remote procedure call. At the ESRF the
network addresses are determined dynamically (at server

Objects In C

The use of objects and classes in the device server model
necessitates appropiate OOP tools. The natural choice
would have been to use one of the many OOP languages
which are available on the market today. If possible one
for which a standard exists or will exist (e.g. c++ ). The
choice of a. language is not independant of the development evironment however. The language chosen has to be
fully compatible with the development environment. At
the ESRF the device access and control development environment consists of OS9, HP-UX, SunOS a.nd the SUN
NFS/RPC. Unfortunately there is no commercially available OOP language compatible with this environment.
The only language which supports the above environmentis C. In order to use OOP techniques it was therefore
necessary to develop a methodology in C, called Objects
In C (from here on OIC). The methodology developed is
implemented entirely in C and is closely modelled on thewidget programming model (ref. [3]).
OIC implements each class as a structure in C. Classhierarchies are supported by subdividing a class structure
into partial structures. Each partial structure representing
a super- or sub-class. Each classa minimum of
three files :• ainclude file describing the class and object
structures," a public include file defining the class and object
types as pointers to structures and the class as anexternal pointer to the class structure,oa source code file which contains the code implementing the class.

The private include file is used to define constants and/or
variables which should not be visible to the outside world(the inverse being true for the public include file). All
functions implementing the class are defined to have static
scope in C. This means that they cannot be accessed directly by any other classes or applications - they are only
accessible via the method-finder or as commands. This
enforces code-hiding and reinforces the concept of encapsulation - a way of reducing
between software modules and making them immune to changes in
the class implementation.
OIC implements an explicit method-finder. The
method-finder is used to search for methods in a cl!!BS or hierarchy of classes. The method-finder enables methods to
be inherited. Two special versions of the method-finder
exist for creating and for deleting objects.
Objects are also implemented as structures. Each object
has a pointer to its cl!!Bs structure. This means that class

S14OOP04
Object Oriented Programming & Techniques

515

515

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-S14OOP04

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

related information (data and code) are stored only once
per process for all objects of the same class.

3.5

The Root ClassAll device classes are derived from the same root class, theDevServerClass.
The DevServerClass contains all common device server
code. This includes all code related to the application programmer interface, the database connection, security, administration and so on. All device classes inherit this code
automatically, this means improvements and changes are
inherited too. The decision to have a single root class fromwhich all other clases are derived has been fundamental to
the success of the device server model. Other OOP based
systems have used the same principle (e.g. the NIH set ofclasses, see [4]).

3.6

The Device Class

Organising devices into classes is an attempt to generaliseon common features between devices and to hide device
dependant details. The device class contains a complete
description and implementation of the behaviour of all
members of that class. Hardware specific details are implemented by the class in such a way that they a.re transparent
to device server clients. Typically the first level of deviceclasses (i.e. classes which deal directly with the first levelof hardware) will use the utilities offered by the operating
system (e.g. device drivers) to implement the hardware
specific details.
New device classes can be constructed out of existing
device classes; This way a new hierarchy of classes canbe built up in a short time. Device classes can use existing devices as sub-objects. This means they appear
as terminators in the class structure and not within theclass hierarchy. This approach of reusing existing classes
is classical for OOP and is one of its main advantages.
It encourages code to be written (and maintained) only
once.

3. 7

The Resource Database

Implementing device access in classes forces the programmer to implement a generic solution. To achieve complete
device independance it is necessary however to supplement
device classes with a possibility to configure devices atruntime. This is achieved by the resource database.
Resources are identified by an ASCII string. They are associated with devices via the device name. Resources are
implemented in the device class. A well designed deviceclass will define all device dependancies (e.g. hardware
addresses, constants, minimum and maximum values etc.
etc.) as resources. At runtime the device class will interrogate the database for the list of resources associatedwith each device it must serve. This is done during device

deviceFigure 1: Command execution in the Device Server Modelcreation and/or initialisation time. Resources allow deviceclasses to be completely general and flexible.
At the ESRF the resources are stored offline in Oracle
where they can be accessed using an SQL*Forms application. Online access is provided by a database server whichinterrogates a memory resident database (RTDB).

3.8

Commands

Each device class defines and implements a list of com·mands. The commands are the applications dials andknobs of the device. Commands (unlike methods) can not
be directly inherited from superclasses. They have a fixedcalling syntax - consisting of one input argument and one
output argument. Arguments can be complicated structures. Commands can vary from simple On/Off type actions to complicated sequences which involve a large number of steps. Defining commands is the task of the classimplementor and his client. The list of commands to be
implemented depends on the definition of the device andthe implementation of the class. Because all commands
are executed synchronously care has to be taken that theexecution of a command does not take longer than the
maximum allowed time.
All commands are theoretically executable from a. remote client across the .network. It is possible however todefine a restricted usage of certain (or all) commands. This
ensures security for sensitive devices. Commands are executed using the application programmers interface. Before a command gets ca.lied the root class checks to see

S14OOP04
516

Object Oriented Programming & Techniques516

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

ICALEPCS1991, Tsukuba, Japan

wether the argument para.meters have been correctly specified. The state machine is also called to see wether thedesired command can be executed in the present state.
This is implemented in the commandJiandler methodof the root class (see figure 1).
Global standard commands have been defined which are
implemented in every device class e.g. DevState to readthe device state. It is possible to define subsets of standard commands for devices belonging to the same superclass which are to be implemented in all subclass of thatsuperclass.

3.11

The Application Programmers Interface

A device server client accesses devices using the application
programmer's interface ( ap1). In order to improve performance the device server api is based on the file paradigm.
The file paradigm consists of opening the file, reading
and/or writing to the file and then closing the file. The
device server a.pi paradigm consists of 1. importing the device using

dev_import (name,ds_handle,access,error)
char•name;
devserver •ds_handle;
long
access;long•error;Local Access

Not all clients of device access and control are network
clients. It is sometimes necessary to use the device classlocally. The notion of local access is completely compatible
with the device server model due to the adoption of OOP
techniques. Device classes can be used locally (as opposed
to remotely) in a number of ways -2. putting and/or getting commands to the device using
dev_putget (ds_handle,cmd,argin,intype,argout,outtypo,error)
devserver ds_handle;
short
cmd;
DevArgument •argin;
DevType
intype;DevArgument *argout;
DevTypeouttype;long•error;" as a superclass," as a subclass,e as a local sub-object within a class.
" or as a local object in an application,
This allows applications which have to run close to thehardware because of performance or hardware constraints,
to profit from existing device classes.

3. freeing the device using

3.10

Network AccessNetwork access is implemented in the device server modelin the root class. This is achieved by a remote procedure call. The de facto industry standard from SUN
the NFS /RPC has been chosen because of its wide availability.
Two types of network access are provided ,, device," administrator.

For this reason there are two api 's. The device a.pi is described below. The administrator's a.pi supports a kindof meta-control to device servers. Using the administrator's interface various kinds of useful information can beobtained about the device server e.g. the devices being
served, and the number of clients per device. The administrators interface also supports a number of commands
e.g. shutting down the server, restarting the server andreconfiguring the server.
Parameters passed between clients and server have to beconverted to network format (for NFS/RPC this is XDR
format) and back again. These tasks are known respectively as serialising and deserialising. A central library ofserialising and deserialising routines is maintained as partof the root class. This way device server programmers do
not have to learn how to serialise and deserialise data.

dev_free (ds_handle,error)
devserver ds_handle;
long•error;Using these three calls a client can execute any commandon a device. The client uses a local procedure call to accessthese functions. The local call is then converted into a
network call by the remote procedure call mechanism (ref.
[5]). Each call is a blocking synchro11ous call. Thismeans that the client waits until the call returns before
continuing. If the server doesn't respond or the remotema.chine is down a timeout will ocurr.
Variations of these three calls supplement the basic device server a.pi. For example a vector version of the above
calls exists which takes a list of devices and a list of commands to be executed, thereby reducing the network overhead incurred by the rpc. Work is also continuing on an
asynchronous version of the dev _putget () call which will
dispatch the command and then return immediately. The
response will be queued and returned to the client when it
is ready to receive it.

4

ExampleThe device server model has been successfully used at the
ESRF to solve the problem of device access and device

S14OOP04
Object Oriented Programming & Techniques

517
517

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

3.9

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP04

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

control for the entire injection/extraction part of themachine. A typical example of a device class is the Powersupply class.

4.1

The Powersupply

At the ESRF one of the most common device types is thepowersupply. There are over 300 powersupplies fromover 10 different suppliers. Hardware interfacing is either
via a serial line or a G64 bus. Each supplier uses a different
register description or protocol.
Using the device server model it has been possible tohide these hardware software differences between the different powersupplies. Applications see a generic powersupply which behaves identically for all powersupplies. The
generic powersupply is a device in the device server model.
All powersupplies belong to the same superclass - thePowerSupplyClass.
The PowerSupplyClass defines a partial structure foreach PowerSupply device/object. Every subclass of thePowerSupplyClass uses the fields defined in the Powersupply partial structure. This way all powersupply classes
have the same definitions and are easier to implement, understand and maintain.
The PowerSupplyClass is what is known as a containerclass i.e. it is never instantiated - its job is• to provide a framework within which to implement
subclasses,

Figure 2: Class Structure for Injection/Extraction Powersupplies at the ESRF

• serve as a receptacle for common powersupply related
methods.
Each new powersupply class is implemented as a subclass of the PowerSupplyClass. The convention has been
adopted to name the powersupply classes after the supplier. Figure 2 shows a synoptic of the powersupply classhierarchy for some of the powersupplies involved in theinjection/extraction process.
In order to standardise the behaviour of all powersupplies a set of commands have been defined which are implemented in every powersupply class. These areo

For more complex powersupplies additional commands canbe added to this list e.g. DevStandby.
The approach to define an generic device of type powersupply has proved very powerful for applications. The application programmers can develop their applications completely independantly of the device class. This way bothprograms can be developed simultaneously and be readyat the same time.

DevOff, switches the powersupply off.

• Dev On, switches the powersupply on.
• DevReset, resets the powersupply after a fault condition has ocurred.
• DevState, returns the state of the powersupply as ashort integer.
• DevStatus, returns the state of the powersupply as
an ASCII string.
Cllo DevUpdate, returns the state, set value and readvalue.

5

The OOP Experience

0 OP techniques were chosen for the device server model
partly because the problem (a general device access system) falls in the scope of problems which can be solved by
OOP techniques; partly as an experiment in OOP to see
what it really implies.
From the experience with the device server model thefollowing advantages could be identified ;• the possibility to inherit code from existing classes,

DevSetValue, sets the principal setpoint (current)to the specified value.

• the logical structure it imposes on classes," DevReadValue, returns the last set value and thelatest read value.

• the fact that it reduces the coupling between code toa minimum.

S14OOP04
518

Object Oriented Programming & Techniques518

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

ICALEPCS1991, Tsukuba, Japan

Not all experience with OOP has been positive however. One of the ma.in drawbacks with OOP is the time
it takes beginners to learn. Our experience has shown usthat even though modelling the world in terms of objects
might come naturally to many people programming withclasses does not. It takes longer for programmers having
no experience with OOP techniques to become productive than it takes programmers to become productive in a
project using traditional (procedural-based) techniques.

2. OOP techniques offer a distinct advantage over traditional programming techniques for solving the device
access problem.

Device servers can be regarded as a new generation ofdevice drivers. They provide device independant accesswithin a distributed computing environment. The device
server model could be used as a basis for a standard ·wayof solving device access in a distributed environment. The
main areas that requires standardisation are the network
protocol and the class hierarchies.
The present implementation of the device servers has defined a device access as consisting of a command with one
input argument and one output argument. In order
to arrive at a standard protocol the commands and thedata types to be supported by the standard would need
to be defined. Doing this could lead to a a standard accessmechanism for devices in a distributed environment (muchin the same way that the Xl 1 protocol is a standard ingraphics programming in a distributed environment).
Standardisation work is also required for class hierarchies. A standard superclass should be defined for eachof the basic device types. The standard fields to be usedby each member of a certain superclass will thereby be defined. A minimum set of commands to be implemented byeach member of the same superclass need to be defined a.s
well. This will ensure consistent behaviour of all devices
belonging to the same superclass and maximum reusage of
code.

8

Acknowledgements

The authors would like to express their thanks to thefirst generation of device server programmers (who programmed valiantly on even before the doc existed) D.Ca.rron, P.Makijarvi, T.Mettala, C.Penel, G.Pepellin,
M.Peru, B.Regad, B.Scaringella, M.Schofield, E.Taurel,
R.Wilcke and H.Witsch. As the first generation of device
server programmers they tested the device server model ona wide variety of devices and provided valuable feedback on
the validity of ~he device server model. The device servers
they wrote were used to build the ESRF machine control
system and the first beamline control system.

References[l] J .L. Lada.re, "Overview of the European SynchrotronLight Source" in IEEE Particle Accelerator Conference, Washington, D.C., March 1987, pp. 417-421.
[2] "Off the MAP" in Scientific American, August 1991,
pg. 100.
[3] P.J .Asente and R.R.Swick, X Window System Toolkit,
Digital Press, 1990.

[4] K.E.Gorlen, S.M.Orolow and P.S.Plexico, Data Abstraction and Object Oriented Programming in C++,John Wiley & Sons, 1990.
{5] A.D.Birell and B.J .Nelson, "Implementing Remote
Procedure Calls" in A CM Transactions on Computer
Systems 2(1), February 1987.
Unix is a trademark of AT&T in the USA and other countries.

7

Conclusion

In this paper a model, called the device server model,
has been presented for solving the problem of device access and control faced by all control systems. Object
Oriented Programming techniques were used to achievea powerful yet flexible solution. The model provides a solution to the problem which hides device dependancies.
It defines a software framework which has to be respectedby implementors of device classes - this is very useful fordeveloping groupware. The decision to implement remote access in the root class means that device servers
can be easily integrated in a distributed control system.
A lot of the advantages and features of the device server
model a.re due to the adoption of OOP techniques. The
ma.in conclusion that can be drawn from this pa.per is that

HP-UX is a trademark of Hewlett Packard, Corp.
SunOS is a trademark of SUN Microsystems, Inc.
059 is a. trademark of Microwa.re Systems Corp., USA.
Motif is a trndemark of the Open Software Foundation, Inc.
NFS is a trademark of SUN Microsystems, Inc.
XDR is a trademark of SUN Microsystems, Inc.
The X Window System is a trndema.rk of the M.!.T.
RTDB is a trademark of Automated Technology Associates, Indianapolis, USA
Oracle is a trademark of Oracle Corp.
Ethernet is a trademark of Xerox Corp.
All other trademarks or registered tra.dema.rka a.re of their respective companies. ESRF <lisclaims any responsabillty for specifying
which marks are owned by which companies or organi'ZatioM.

1. the device access and control problem is adapted tobeing solved with OOP techniques,S14OOP04
REFERENCES
Object Oriented Programming & Techniques

519

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

Standardisation

6

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP04

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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The diagram of Figure 1 illustrates the interactions
between the RFB BCS and its terminator objects. Since, by
mandate, only the RFB EMS was allowed access to the booster
via the IBM-PC in VMEbus, the RFB EMS was identified asa terminator object of the RFB BCS. Within the RFB BCS,
the object RFB Booster Control was created to represent theinteraction of the RFB BCS with the RFB EMS terminatorobject. The only other terminator object identified was the
RFB BCS Operator, and the object RFB Operator Control was
created to represent the interaction of the RFB BCS with the
RFB BCS Operator.
The state transition diagram of Figure 2 illustrates therequire remote non-privileged access to the booster equipment
in order to manage other aspects of the booster equipment,such as alarms, warnings and data logging. Thus, the purposeof the RF Booster Equipment Management System (RFB
EMS) was established as:• to enable operators in the Cyclotron Control Room toremotely manage the booster and its equipment• to provide operators in the Cyclotron Control Room with ameaningful display of the operating parameters required forremote management of the booster and its equipment• to provide a data logging facility for the booster, and• to serve as the functiooal interface between the RF Boost.er
Beam Control System and the booster equipment
The RFB EMS was found to interact with four
terminator objects: the RFB BCS, the RFB EMS data log, the
RFB EMS operator and the RF Booster. For each of theseterminator objects, a corresponding RFB EMS object was
created to represent the interaction between the RFB EMS
and the terminator object These objects and the essential
information flows between them are shown on Figure 3.
The RFB EMS requirements analysis has presently
completed one external review. During this review, it
became clear that, whenever excessive beam spill is detectedby the RFB EMS, it must interact with the cyclotron ion
source and shut off the beam to prevent damage to thebooster and ancillary equipment.
The RFB EMS
requirements are presently being revised to reflect this new
requirement.

IV.
DESIGNIn the design phase, one of the major steps in
implementing an object-oriented architecture is the allocationof the requirements specification to teclmology units. Several
implementation choices which affect this allocation havealready been made, namely:• the operator interface for both the RFB BCS and the RFB
EMS will be implemented via a VA.X/VMS comme..-cial
real-time database and screen generator product obtained
from Vista Control Systems.
• the majority of the RFB E!v!S and RFB BCS objects will
be implemented in a V.AXJVMS system, as nearly all of
the terminator objects with which these objects must
Figure 1: Beam Control System Objecu (circle1) md Terminlltor Objects
interact are accessible there.
(boxes)• communication between the VAX/VMS system and the
VMEbus system will be implemented via the socket server
model of the RFB BCS operator behaviour elicited fromethemet protocol suite described in [3]. This suite
personnel interviews.
implements messag~based inter-process communication
The requirements analysis for the RFB BCS has presently
between VAX/VMS processes and processes residing in acompleted two external reviews and is considered ready for
VMEbus processor running the Unison real-time operating
design and implementation.
system from Multiprocessor Toolsmiths,• since all of the code running on the IBM PC in VMEbus
B. The RFIJ Equipment Management Systemruns under MS-DOS, an ethernet equipped VMEbus
An RFB EMS operator would, at times, require privileged
processor card running the Unison real-time operating
access to the booster equipment and, by mandate, such accesssystem will be added to the VMEbus crate to provide
was limited to the IBM-PC in VMEbus. It was recognised,network communication between the VAX/VMS system andhowever, that the RFB equipment management operator would
the IBM PC in the booster, andS14OOP05
Object Oriented Programming & Techniques

521
521

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-S14OOP05

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 Publishing• the XDR (External Data Representation), which has been
designated RFB1014 by the ARPA Network Information
Centre, will be employed to define data formats formessages passed between the heterogeneous processors inthe system.
In Figure 3, the aggregate information flow RFB
properties consists of information which describes all

system to be transparently encapsulated in messages between
the VAX/VMS system and the booster VMEbus system.

doi:10.18429/JACoW-ICALEPCS1991-S14OOP05

V. OBJECT-ORIENTED IMPLEMENTATION
During the TRIUMF Beam Line 2C project, an approach
was developed for the direct translation of object models into
C code. The real-time data base from Vista Control Systems
is central to the translation process·as inter-object data and control
flows, including flows fromL
terminator objects, are implementedI"
via
channels in the database.
E. Monitor RFB properties
When implemented by thisnot RFB Is ramping +Startmethod, each object is composed of
not RFB ls ready for beam
the following code and data:

l

·~ (~

Decide to updale
RFB default voltage• aprtvatedata

structuredescribing the object instance.
T. RFB default control
Included in this data structure is
P. Tum off RFB
voltage update
P. Update RFB default
a record of the object instancecontrol voltage
Istate, a list of the database
Waiting to start RFB ~I
Decide to tum off RFB
channels accessed by the object
P. Tum off RFB
and a state transition matrix
which describes the object's state
Decide to tum oo RFB voltage
Dack:le to tum on RFB
transition diagram in tabular
T. Tum on RFB Initial voltage
P. Tum on RFB default voltage
P. Tum on RFB
form.
• a VMS Asynchronous System
Trap (AST) handler, which
Decide to updale
serves as a transaction centre for
RFB default voltage
objectevents and/or conditions,
DecidetoupdateRFB
voltage
T. RFB default control
andvoltage update
T. RFB control voltage update,. ,.
.... P. Update RFB control voltage
P. Update RFB default• the object methods which
con lrol voltage
I Waiting for Ramp I
implement the object's behaviourIlas
C function calls.
Decide to update RFB phase·Iii.
RFB Is rampingAn
object attaches its AST
T. RFB conlrol phase update
P. Update RFB control phasehandler to each database channel
from which it expects to receive adata or control flow, and the AST
not RFB ls ready for beam
RFB ls ready for beamuser parameter identifies the event
which
is associated with theDecide to updale
channel. (In the case of condition
RFB default voltage
Decide to update RFB voltage
or data flows, this event signifies aT. RFB default control
voltage update
T. RFB control voltage updatechange in the condition or data
P. Update RFB default'
P. Update RFB control voltage
flow.)An STD is directly
control voltage
I
I Watching booster run 1I
translated: a transition condition on
an STD becomes one or more
Decide to update RFB phase
RFB Is ready lor beam j
events associated with database
T. RFB control phase update'
P. Updale RFB control phasechannels; the object instance state ismaintained in private memory; andFigure 2: Beam Control System Operator Behaviour
a transition action on an STD
becomes the object method
properties of the booster. However, this information must be associated with a state-event pair in the state transition matrix.
obtained from two different sources: the IBM PC in VMEbus When an event occurs, the object's AST handler serves as aand the 1RIUMF Cyclotron Control System. The use of the transaction centre by using the event and the object instancemessage-based socket server network communication protocol state to look up the destination state and associated method inallows information flows originating in the booster VMEbus the state transition matri~. The associated method is triggeredby the AST handler and the destination state is recorded as a
Decide to tum off RFB... ... ,,,

l

,.,

i

'"'

.

,,, ,,,'"'S14OOP05
522

Object Oriented Programming & Techniques522

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingnew value of object instance state. Once the function cal! tothe associated method is complete, the AST handler checks fortransition conditions which cause a transition to a new state.

continuous octivities were emulated by calling any enabledactivities during execution of the AST handler.
The use of real-time database clwmels for information
flows between objects enables concurrent and independent codedevelopment and testing. For instance, during the TIUUMF
Beam Line 2C project, all information flows between objects
were defined as database channels prior to thegeneration of any code. The coding andtesting of objects did not depend on theexistence of other objects because each objectreferred to appropriate database channels for
its information flows, rather than to theobjects from which the information flows
originated. This enabled concurrent codedevelopment and testing on an object-byobject basis.

If a transition condition which causes a state transition issatisfied, the AST handler updates the object instance state andcontinues checking for conditions causing state transitions until

VI. CONCLUSIONSThe object-oriented analysis of the RF
booster remote control system has produced arequirements specification which can bedirectly translated into code. However, theuse of an inappropriate CASE tool
(DECdesign) caused serious tool-specificdistortions to enter into the specification forthe booster remote control system.
The use of a message-based network
protocol has enabled theencapsulation of information flows which are
obtained via the network.
This hasconsiderably simplified the design architectureof the RFB EMS by eliminating the need to
distribute objects between processors.
The implementation of RFB EMS andBCS objects by direct translation of therequirements specification is presently being
carried out.
Object implementation isproceeding concurrently and independently,
since channels in the real-time database used
for information flows between objects can be
defined before any objects are coded[lJ C. Inwood, G.A. Ludgate, D.A. Dohan, E.A.

Osberg .md S. Koscielniak, "Domain-Driven
Specification Techniques Simplify the Analyi;ill of

Figure 3: Equipment Mllllagement System Objeru (circles) !md Tmnin:i!tor Objeru (boxes)

Requirements for the KAON Factory Central
Control System," Nuclear lnstrwnuttsandMethods
in Physics Research, Vol. A293(1,2), Amste?dam:
Elsevier Science Publi.shen, 1990, pp. 390-393.
[2J

none are found. When no valid transition conditions arefound, the AST handler exits.
The considerable overheads inherent in VAX/VMS
process creation precluded creation of separate processes forobject methods which were continuously active. Instead,

P.

W<!rd

and

S.

Mellor.

Structured

De:velopmenlfor Real-Time Systems, Yourdon Press, New York, 1985.
[3] N. Wi.lldnson and D. Dohan. "Synchronolll.l Message-Bl!Sed

Communication for Distributed Heterogeneous Systems," submitted
to: llllemo.tional Conference on Accelerator and Large Experimenlal
Physics Control Sy.st.ems, November 11-15, 1991, Tslruuba-shi,
IOOral.d-ken, Japan.

S14OOP05
Object Oriented Programming & Techniques

523

523

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-S14OOP05

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 & Techniques524object: RUN
state: DORMANT
action: START
state : ACTIVE
action: PAUSE
action: STOP
state: PAUSED
action : RESUMEICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP06

associated object when the program associated to it is notrunning. This special state allows testing in the SM code
whether the associated program is running or not
The WHEN instruction triggers the execution of an action
spontaneously when a logical expression based on the statesof objects becomes true. This instruction is used to react
asynchronously to a state change in the system.
The example below uses the four basic SM instructions:object: RUN
state : DORMANT
action : START
do MOUNT TAPE
do START TAPE
do ENABLE TRIGGER
if (TAPE in_state WRITING) and(TRIGGER in_state ENABLED) thenterminate_action/state=ACTIVE
else
terminate_action/state=FAILURE

end.ifFigure 2. Example of a state machine.
The execution of an action is different, depending onwhether the object is associated or not. For an associatedobject, the execution of an action consists of sending acommand to its associated process. When the process has
terminated the execution of this action, it will return to its
new state, which is mimicked by the associated object. For anormal object (not associated), the execution of the action
consists of the execution of a sequence of SM instructions.

B. The instructions
Four basic instructions are contained in the language.
The DO instruction is used to send a command
asynchronously to an object The sender carries on with its
own execution after the command has been sent. The
command is put into a queue if the receiver is not ready to
execute. A queue of pending commands is maintained for eachobject in the system. The next command is delivered to an
object when this object is ready to accept it, i.e. when theobject is in a stable state and is not executing any action.
The sequence of instructions corresponding to an action is
terminated by the instruction 'TERMINATE ACTION/STATE=state name'. This instruction can be placed anywherein the code, thus stopping the execution of the code andputting the object in a stable state specified in the instruction.
The IF instruction tests the state of one or many objects
and combines the results in a logical expression. All thecommands present in the object queue must be executed before
testing the object state. The IF instruction synchronizes theobject executing the IF statement with the objects whose stateis tested in the instruction. The language also specifies a
special state, the 'dead state', which is assumed by anstate : ACTIVE
when TAPE in_state END_OF_TAPE do STOP
action : STOP
do DISABLE TRIGGER
do STOP TAPE
do DISMOUNT TAPE
terminate_action /state=DORMANT
state: FAILURE
action : RESET
do RESET TAPE
do RESET TRIGGER
terminate_action /state=OORMANT

C. The SM domain and the visible objects
The object name has to be unique in one SM program
because the object must be addressable unambiguously.
However, this may be a limitation in big systems composedof the repetition of similar subsystems. It may also be easier
to divide a big system into smaller SM programs. This iswhat the SM domains are for (Fig. 3). The SM domain is alogical domain that consists of one, and only one, SM
program and its associated programs. The SM domain limits
the visibility of an object. The name of the object must be
unique in one domain, but the same object name can be usedin different domains.
An object belongs to one domain only, but it may berendered 'visible' to outside domains. One SM program cantherefore be controlled from another SM program. Figure 3
shows an example of a top-level SM controlling two otherSMs in different domains.
The way to invoke an object of another domain is tospecify explicitly its domain as shown in the example of
Figure 3: the SM program of the domain MAIN contains
references to the objects 'TPC::RUN' and 'HCAL::RUN'.

S14OOP06
Object Oriented Programming & Techniques

525

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-S14OOP06

Domain MAIN

if(CURRENT_TAPE" in_state MOUNTED) thenSM program

E. Command parameters
Some associated programs may need parameterizedcommands. Parameters are specified in the SM code as simple
strings or as logical names translated at run-time. The
parameters are appended to the string of the command before it
is sent to the associated process. An example is given below.
SM program

Domain TPC

do MOUNT {"/LABEL=" VOLUME) CURRENT_TAPE"
SM program

ill. 1HESTA1EMANAGERANDTIIE
EX'IERNAL WORID

Domain HCAL

A. The control program

Figure 3. Example of use of the SM domain.

D. The classes and the access objects
With the declaration statements seen up to now, the user

has to declare each object in the SM program. However, it isquite common to have systems where many objects are
identical, but not their names. The notion of class has been
introduced to cope with this case. A class of objects is similar
to a data type in standard programming languages. The
declaration of a class must define the class name, its states,
and its actions. Once a class has been defined, it is sufficient
to invoke the class name in the declaration of the objects thatbelong to that class. The following example shows thedeclaration of a class 'TAPE', and of two objects T APEi' andTAPE2' of the class TAPE':
class: TAPE /associatedstate : AVAll.ABIE
action : MOUNT
state : MOUNTED
action : DISMOUNT
object : TAPE! is of class TAPE
object : TAPE2 is of class TAPEThe SM program itself can be controlled at run-time by a'control program', which can send a command to the SM witha call to a subroutine. The control program can also examine
the current state of the system. A library of routines isavailable for the communication between the control program
and the SM.
A general purpose control program has been built using
the Motif graphical user-interface toolkit. Each object isshown on the screen as an icon. The user interacts with anobject by clicking on its icon to reveal a popup menu. The
user can send a command to the object, see the object's paststates and actions, and view the queue of actions to be
performed by an object. The display shows one domain at atime. This domain can be selected by the user.
Many aspects of the display can be customized by theuser; objects icons can be hidden, moved and replaced by userdefined ones. The user's personal configuration can be saved
and restored automatically when the display program isrestarted

B. The associated programs

This feature improves the readability and the'maintainability' of the code, and reduces the size of thedeclarative part of the program.
A special type of object has been introduced to handle an
object belonging to a class: the access object, which is like apointer to any object of a given class. The 'access' statement
specifies which object of the class is being accessed. The
basic SM instructions can use the access object to refer to one
object of a class indirectly:
object: CURRENT_TAPE is access to class TAPE
state : NOT_USED
action: SELECT_TAPEI
access TAPE 1

do MOUNT CURRENT_TAPE"

The associated programs running under the control of the
SM must conform to a well-defined interface. They must becommand-driven and send back their state when it has been
modified. A library of routines is available for thecommunication between the associated processes and the SM.
The simplest structure of an associated program is asfollows:
C Initialization callcallSMUNIT
C Associate the program with an object
call SMI_ASSOCIATE (object_name)do while (program active)
C
Receive next command to execute
call SMI_GET_COMMANDW (command)
Decode the command
CC
Return new state after execution
call SMI_TERMINATE_COMMAND (state)end doS14OOP06
526

Object Oriented Programming & Techniques
526

ICALEPCS1991, Tsukuba, JapanFor example consider the following SM instructions.

C. The multiple-state associated objects
Some associated programs may be difficult to describe intenns of a state machine with a unique current state. It is
possible to divide them into sub-objects, each of which havetheir own state. A sub-object can be a device that the program
has to deal with, or a level of alarm, and so on. The result of
this division into sub-objects is that the object itself has
many concurrent states
Extra SM instructions, not described above, are required to
fully define object's state machines. A tool exists to help theuser generate associated programs state machines.

object :RUN

do MOUNT TAPE
if (TAPE in_state MOUNTED) then
The DO instruction is translated into a rendez-vous with
the QUEUE task to add an action to the queue of thedestination object The IF instruction causes the TAPE object
to block, its state to be evaluated by Run, and then to
unblock.

QUEUE(TAPE).PUT(MOUN1)QUEUE(TAPE).PUT(WAIT_IF)
if (OBJECT(TAPE).STATE=MOUNTED) thenN. IMPLEMENTATION
The translation of the SM language into Ada proceeds
directly by the semantics of its main instructions.
Each SM object executes its actions in parallel with theother objects. Each object is translated into an Ada task which
is an independent thread of code. The current state of an object
becomes a variable with a value equal to one of the value ofan enumerated type. Actions are translated into Ada rendezvous, where two tasks are synchronized.
However, the SM action is asynchronous whereas the Ada
rendez-vous is synchronous. Therefore, for each object, asecond Ada task is introduced to handle the queLie of pending
actions, to disable its access and to produce the asynchronism
needed for the SM action. The two Ada tasks corresponding to
an object are shown in Figure 4.

loop
QUEUE.GET---IP- accept PUT
01

acoopt GETandendif,OBJECT(TAPE).CONTINUE
In addition, a dedicated Ada task consists of all the WHEN
instructions contained in the program. This task: is scheduledeach time an object assumes a new state. The task evaluates
all the WHEN conditions and adds the appropriate actions to
the queues.

Y. CONCLUSIONThe SM is a new approach to the problem of run control.
It has proved to be both flexible and reliable, during its use at
CERN in collaborations such as DELPHI, OBELIX, andOmega.
By coding associated programs according to simple
principles, SM provides an object-based approach to DAQ
design that benefits the control and maintenance of thesystem.

coda
OI

accepteccaptend

QUEUE

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S14OOP06

task OBJECT

Command Queue

Figure 4. The Ada code corresponding to an object
As described before, the IF instruction requires somesynchronization between the object executing the IF statement
and the objects whose states are evaluated in the condition.
Two rendez-vous of the task 'Object' block and unblock theexecution of an object at the beginning and the end of the IF
statement.

VI. REFERENCES[1] J. Barlow et a1., "Run Control In Model: The State,in Proc. 6th Conf on Real-Time Complller Applications in
Nuclear, Particle, and Plasma Physics, Williamsburg,
Virginia, 1989 [IEEE Trans. Nuct Sci. NS-36 (1989) p.
1549][2] A. Deffendini, B. Franek, P. Vande Vyvre and A. Vascotto,
The state manager user mmual, CERN-ECP internal note,
Geneva. This document can be obtained, upon request,, from!he authors, c/o CERN.
[3] R. Jones, OSP user's guide, CERN-ECP internal note,
Geneva. ThU; document can be obtained, upon request, fromthe author, c/o CERN.
[4] Ada Joint Program Office, United States Department of
Defence, Reference Manual for the Ada P.rogramming
Language, ANSI/MIL-STD-1815A, Washlllton D.C.:
Government Printing Office, 1983.

S14OOP06
Object Oriented Programming & Techniques

527
527

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-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

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S15CSE01

these methods bear strong resemblance with those developed inother engineering disciplines.

PRODUCTS ON THE MARKET

There exist a large variety of CASE products on today's
market: Computerworld [5] published a list of not less than 33
such products that were selected on the basis of the tools they
provide for analysis, design, code generation, debugging, code I
configuration management, testing and integration, codeanalysis, maintenance, documentation, reverse engineering,project management, etc. Unfortunately, no tools exist yet thatprovide all these facilities in a single environment, and as theydifferent vendors, they are often not
are developed
compatible: e.g. the output of a first vendor's analysis anddesign tool may not be usable by another vendor's code
generator. Therefore some of the larger vendors endeavour todesignframeworks through which tools fromvendors can communicate. Such frameworks are
Support Environments, IPSE.
even IPSE are only effective
the IPSE
producer has established contracts with third party CASE
To date the _,,," ...,__
software market seems to be
subdivided in two
domains: database and real time
database
focus theinfonnation so that it can be
retrieved andof associations or combinations as are"'""m'""• the real timein ..,,,,..,,,.,.,.,,.
ap1:mc;auDns, concentrate on the functional andthe process: what functions have to be!-'"'"''""""' - and when - to respond to the
behaviour.
This difference is reflected in the facilities that arebycurrent CASE tools: those for databaseprovideextensive facilities to model the data, whereas the tools for realtime
are more concerned with
thefunctional and temporal behaviour of the process. One would
expect tools for both database and real time applications infuture to converge towards a single environment.

4.
CASE methods cover two aspects: a technical one that isconcerned with thedesign andof theapplication, and a
one thatvariouscontrol andassessment techniques with rules for aproperof the project team where every member
has a wen defined role, in addition tofor theorganization of
feedback. sessions with the users,
quality assuranceetc.
As an initial
most CASE methods start with defming
the objectives and the boundaries of theenter into awhere a model is nrr~'ll1,f'Pn
needs to be developed and describing its relation to theenvironment. This model is then worked out in more detailduring the analysis. Until this stage there is no considerationof how the requirements will be fulfilled, this is the purpose of
the design. Next comes a build phase followed by
implementation and commissioning. It should be noted that

5. CASE TOOLSCASE tools help the developer in reaching a fullunderstanding of his project. They guide him through thevarious phases of the development process so as to produce aseries of models to entirely depict his program: they are the"blue prints" of the program he will implement.
Software involves in general three basic components: data,processes that operate on data, and the time or events at which
the processes are executed. CASE tools allow to model
respectively the structure and the internal relations of the data,
the functions and the events; they further depict how data relate
to functions, functions to events, etc.
The models are represented by diagrams constructed bymeans of a number of
accepted
notations:e.g. Yourdon I DeMarco for control flow and state trai1s111on
Jackson for data structure, Chen, ERD
diagram) or NlAM
Infonnation
for
entityMyers and Constantine forstructure charts. CASE
thus appear to the reader as
roadmapswhich he canto understand thestructure of the program and the tur1Ctllona111ty
These urn:grnmus..,,,.,.1..,,,, attributes, processes,
events,spccu1ca11on Textual
are also
editors. The more advanced tools
extensive checking such as referencibility ofentities,and consistency of theidentifying e.g. unlabeled or unbalanced
entities andattributes , etc.
Most CASE tools support multi-user
and runin a distributed environment Their user interfaces are based ongraphical and textual editors with Macintosh or MOTIF
which the programmer enter its
spc:cifica1tior1s that are
in a central
The
repository
the various tools into aenvironment (hence
i.e. integrated CASE); data are
available at eachof the project life cycle and can bechecked against thefor completeness andconsistency. Project administration tools are also provided todefine accessto thefor each member of the
project team depending on his privileges, to control theversions of diagrams, etc ..
TOOLS USED IN THE
SECTOR
In order to evaluate the applicability of CASE in theaccelerator sector ata number of pilot projects havebeen selected in various fields relating to accelerators: controls,
data acquisition, cryogenics, modelling, radiation monitoringand survey,

S15CSE01
CASE and Software Engineering

529

529

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

3.

ICALEPCS1991, Tsukuba, Japan

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

The pilot projects for database applications concern new
designs, retrofitting existing systems or modelling for
documentation purposes. ORACLE*CASE was selected
because it provides a full information system engineering
environment based on the ORACLE relational database that isstandard at CERN. However, in order to compare the
ORACLE methodology to model entities with NIAM, a"shadow" exercise has been initiated using RIDL, Relational!Dea Laboratory, of lntellibase NV (Antwerp, Belgium), thatis based on the latter methodology.
The evaluation of CASE for real time applications has
focused on StP, Software through Pictures produced byInteractive Development Environments, IDE (San Francisco,USA) and Real Time Engineering Environment, RTEE, ofWestmount Technologies (Delft, the Netherlands). These
CASE tools complement Teamwork of CADRE Technologies
that is in use in SL division 1.

ORACLE*CASE for documentation purposes, and next, todesign an enhanced version.
The General Supervisory System monitors theenvironmental conditions in the four experimental sites of
LEP through more than 1,000 detectors. The system is basedon an expert system with its knowledge base and security rules
stored in an ORACLE database. It grew as experience
accumulated over the years and has now reached a point were amajor overhaul is needed to rationalise and enhance its
functionality. The need to port the system to a UNIX
environment provides the opportunity to undertake its retrofit.
For StP two parallel evaluations were carried out. The firstone concerned an asynchronous data-collector service that will
be incorporated within the control system of the PS accelerator
complex. That system has been analysed with the aid of data
structure, data flow and state transitions editors. The second
evaluation concerned the use of structure chart editing facilities
for the detailed design of an error logging program.
In contrast to this, the evaluation of the RTEE for realtime application was not based on a real life project. Instead,the idea was to analyse the facilities the tools provide, in somecases by modelling parts of existing real time programs, andby evaluating the method and notation on which they are

BriefDescription of Pilot Projects• Data base Applications
The database for cryogenics should provide a full inventoryof the equipment and information on the state. It should also
provide information concerning control signals and algorilhms
and incorporate archive measurement and test data of thevarious instruments for maintenance purposes.
The Survey group is responsible for the proper alignmentof approximately 10,000 accelerator and transfer line elements
over approximately 60 km. Most of that information is stored
in a central ORACLE database and should be extended toinclude data about the stability of the measurement devices.
The SL database aims at providing a central description of
the SPS and LEP accelerators, reference information on thestate of the machine and at maintaining historical reference data
for a variety of applications in different areas: controls,
vacuum, survey, beam instrumentation, magnets, power
converters, radio frequency, mechanical design, and accelerator
physics.

• Real time applications.
The LEAR control system is currently running in a
VAX/VMS environment with UIS as ·console interface
software. The front end hardware is based on PDP with Pascal
software. By the accelerator start-up in 1992, the front-end partof this control system should be adapted to an X-system
environment and its database migrated into an ORACLE one.
It was intended first to model the control system by the use of

1 .ii.2.1§.: Teamwork, that was recommended in 1989 by CERN's
Teclmical Board for Process Controls and Accelerator Electronics(TEBOCO), became unusable for PS division when it was decided
to standardize all CERN controls on UNIX or Ultrix. PS division
was equipped with VAX stations and their VMS 0/S was replaced
by Ultrix: although operational on VAX-VMS or DEC-Ultrix
platforms, Teamwork: appeared not to run properly on PS' hybrid
VAX-Ultrix configurations.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S15CSE01

based.

Objectives
The prime objectives of the pilot projects are to gain
experience with CASE methodology and tools and to evaluate
their applicability to technical projects. All projects, except
the one using RTEE, aim at producing real applications. Thiswas in particular a pre-requisite for being entitled to an
ORACLE*CASE licence.
From a management's point of view, CASE is evaluated asa way to produce better quality software and to enhancecommunication with the user, cooperation across projects andprogress visibility. It is also aimed at economy of scale bysharing the resources invested in the evaluation exercises.

Constraints
The mixed nature of the projects reflects the constraints.
The pilot projects have limited financial and humanresources: even if the overall team involves around 25 persons,depending on their role some are only spending a fraction of
their time in the project. In addition the teams belong todifferent Divisions: Accelerator Technology, Computers andNetworks, Electronics and Computing for Physics, MechanicalTechnology, Proton Synchrotron, SPS-LEP. They are thus
geographically distributed and their members are also involvedin other activities whose priorities depend on the local
divisional objectives. The teams cover a wide range of
disciplines, each having it own habits and jargon. However,this multidisciplinary, multidivisional and part time nature are
typical for the way projects are often carried out at CERN.

S15CSE01
530

CASE and Software Engineering

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

ICALEPCS1991, Tsukuba, Japan

In addition the projects are different in size: though mostare small and well encapsulated, the database project forcryogenics appears as a large one. It was thus difficult, not to
say impossible, to keep the pilot projects synchronised so as
to reach a more homogeneous level of expertise, possibly
sharing some common designs, agreeing on a common
glossary, etc.
The project involves a mix of platforms: VAX stations
running VMS, DEC and SUN-SLC & IPC running Unix. The
workstations involved in the evaluation of ORACLE*CASE
host the tools and are linked by ethemet to a central VAX
6420 with VMS 5.4 that houses the central database and thedictionary. The workstations communicate with the central
engineering database through SQL*NET (Fig.I.).

In general the methods were followed but needed to beadapted to the way of working, proper to scientificorganizations. This is particularly true for ORACLE*CASE
Method whose rigor was difficult to accept since it broke withthe usual individual style of working. The methods for realtime applications adapt easily to a more familiar bottom up
design without excluding the rigid top down approach.
The Survey and SL database projects are currently in thebuild stage and are generating tables and forms. Those involved
in retrofitting the database for survey claim that by using
CASE they were able to optimize their design so as toimprove the performances of data retrieval by a factor of 5
when compared to the original design.
The cryogenics database however grew to become a muchlarger project than anticipated. This is in part due to the factthat an overall picture was originally not available and only
became apparent as one proceeded through the method. Muchtime was spend on understanding the cryogenics problems in
addition to learning the method and the tools. However, at thistime a model has been designed that is reasonably stable andhas obtained agreement with the users.
LEAR failed to model its control system by using
ORACLE*CASE. Despite hopes to model the system for
documentation purposes, it turned out impossible to describe
the time dependencies and the process sequencing that are
fundamental aspects of real time systems.
Eventually modelling the General Supervisory System
could not be pursued because of lack of manpower. However,it came to a point where similar problems as for LEAR
became apparent because of its strong real time nature.

GSS
Dcc.tat!Oll 3100
VMS 5.4

MMbl!AM
8llO Mb DiakCRYO
Sun !PC Ucib::WMb BAM

8ll0Mb ow.

SLCO

N
B
1------TSURVEY
Dcc.iatlon 3100
VM.9 ~.•

Doc.talion 3100
Ultrix 4.0

VXLDB2Central Computer
Vax 6420 I VMS 5.4

7. COMP ARING METI-IODS AND TOOLSORACLE*CASE

Figure 1
On ORACLE Corporation's request a tighter management
scheme was adopted for the database projects than for the realtime ones.

Evolution of the projects
It was felt that learning the method and the tools by reading
manuals and playing with the tools alone would be too time
consuming. Therefore systematic training on the method andthe tools was introduced for the database pilot project teams
and also for those involved in real time CASE evaluation who
wished so. Professional consultancy was called upon to define
the scope of the projects, for fonnal reviews, feedback andquality assurance in order to rapidly reach a reasonable degreeof expertise within the CERN software engineering team.

ORACLE*CASE Method follows a top down
approach whereby a number of tasks have to be perfonned in a
specific sequence. These tasks are grouped in the various
project phases which must yield well defined deliverables
before one can proceed to the next phase. The method also
includes many cross checking techniques to ensure theaccuracy, consistency and completeness of the design. It also
provides techniques and procedures for team and project
management emphasising the user involvement throughout thelife cycle and control techniques.
The following phases are identified:Scoping to define the limits of the project, its objectives
and constraints. ORACLE puts a lot of emphasis on thisphase as a means to keep the project on its tracks.
Strategy: in this phase a model is produced of whatneeds to be developed. The functionality is represented by ahierarchical breakdown of the functions to be performed and astructural model is built with the entities. This phase also
includes statements about quality standards to be achieved. The
requirements are next translated into written specifications,drawings, data sheets, etc.

S15CSE01
CASE and Software Engineering

531

531

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 DOISUPPORT
811r1 IPC Ucib:

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S15CSE01

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 Publishing

Analysis: the previous model is now worked out byadding attributes to the entities and by describing them indetail. The data flow diagram describes movement of data
between the functions. Matrices allow the cross checking ofcompleteness of the relations between functions and entities,
entities and attributes.
Design: this phase concentrates on how the detailed
requirements, as defined in the strategy, will be fulfilled. An
infonnation system architecture is produced identifying thevarious applications covered by the functions that will accessthe database together with a detailed program specification.
Build stage: the system is now built and reviewed withthe user.
Transition phase: the implementer provides the customer
with the necessary support to ensure a smooth transition fromthe old system to the new one.
Production (Operation): ensures the running of thesystem whilst its performances are being monitored.
It should also be stressed that ORACLE*CASE puts a lotof emphasis on the management aspect of the project and on
the relation between the information system engineer and thecustomers.
The tools provided by ORACLE are CASE*Dictionary,
an internal multi-user database that acts as the central
repository for all information relating to a project through allstages of its life cycle. This dictionary is filled throughU.04.<&U• . . ~ (function hierarchy, entity relationship, data flow, ...),
matrices and interactive forms provided by CASE*Designer.
Furthermore, CASE*Generator generates tables, menus,
interactive forms using the 4 I 5 GL ORACLE tools, andreports. The central part in ORACLE*CASE is the entity
relationship diagram, that is based on an extension of the Chen
method. It provides a large number of facilities and coded
symbols to describe the entities, their type and attributes aswell as their relations.

The major steps through the method are:Survey, evaluating the requests and the feasibility withinbudget and time constraints.
Analysis, defining the environmental model of thesystem (i.e. how does the system relate to its environment)
and the behavioural model showing the processes inside
the system.
Architecture, where processes, tasks and eventually
modules are modelled. This is a not so common feature thatis particularly useful in case of distributed multitasking
systems.
The strategy phase of ORACLE*CASE appears toinclude the survey phase with some overlap in the analysis
when defining the environmental model.
Contrary to ORACLE*CASE whose diagrams are limited
to describing the functional hierarchy, relationships between
entities and dataflows, the tools for real time application
development provide diagrams to model several control aspectsof the system.
The control now diagram provides hierarchical modelsof the system's functionality showing data and control flow
between processes, the processing of data and their control
actions. It is based on a number of rules and symbols torepresent data processes and control processes, types of flows(data flow, update flows, continuous data flow, control flow
and continuous control flows), stores (data and control storessuch asinformation), and external processes with which
the system communicates. The familiar data now diagram
one finds in ORACLE*CASE, appears as a specific view inthe control flow diagram. It is complemented by a list of
events (temporal, control or flow oriented) identifying thestimuli that occur in the external world and to which thesystem has to respond, and diagrams to illustrate how these
events relate to the system.
The data structure diagram gives an abstract and static
representation of the data: it shows how the data are structured
hierarchically, not their relation. It allows specification of
simple sequences, iterations and selections.
The
relationship diagram represents the static
relations between entities using the Chen modelling technique.
The state transition diagram describes the states of asystem and the sequence of activities between the states (in ourcase, following the Yourdon method).
The system architecture diagram is an extension of
the control flow diagram. It allows one to graphically assign
and partition tasks to processors and incorporates symbols forprocessors, tasks, interrupt service routines, message queues,
message boxes, event queues and event flags.
The structure chart depicts the functional breakdown of
the system. A module is defined as a collection of program
statements.
Ultimately the code is generated in three steps: generationof a program design language, PDL, from the structure
chart; generation of program code from PDL; generation ofdata type declarations from data type diagrams.

doi:10.18429/JACoW-ICALEPCS1991-S15CSE01

CASE for Real Time Applications
The rigid top down approach that is followed by some
CASE methods and tools has been the object of endless debate
and has been abandonned by some of its major initiators infavour of a more pragmatic middle out approach (6) or an
object oriented one. The tools that were evaluated within thescope of this exercise, StP and RTEE, follow this middle out
approach and allow the designer to progress both towards
higher levels of abstraction and lower levels of details in thecourse of his analysis and design. Except for this particularfeature, the CASE method for real time applications follows
essentially the same sequence of phases (see previous
paragraph) by which a series of models are produced that aregradually refined and complemented so as to ultimately yield
template code. However, the user involvement and teamorganization during the project life cycle is not defined to thesame extent as by the ORACLE*CASE method.

S15CSE01
532

CASE and Software Engineering532

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

8. EVALUATION CRITERIACASE products are evaluated relative to their architecture,
the environment in which they run, the applications that areprovided with the product, the tools themselves and, last but
not least, a number of economical considerations relating to
the vendor.
The architecture is expected to be "open" allowing the user
to customize e.g. menus, commands, etc., to set defaults andto extend the tool by invoking other tools such as e.g. testers
and simulators.
The environment in which the tools run should be based onstandard operating systems, windowing system; they should
also support heterogenc.ous networks.
The product should allow tracing the requirements
throughout the various phases and provide facilities to produce
standard documents that can be customized, etc.
The tools themselves are evaluated on the ergonomics oftheir editors and the techniques they support
Selecting such a tool implies a strategic choice and one has
to take into account vendors' "health" on the CASE market,
the support he is able to provide, and the evolution of his
product withto those of competitors.

9. PRELIMINARY CONCLUSIONS
Although it is premature at this stage of the project to draw
definite conclusions, sufficient experience has been
accumulated to be convinced of the usefulness of CASE
methods. They are very rigorous and convey confidence in thequality of the product. The clients admitted, after initialskepticism, that the method provides a sound basis fordiscussion. Even if during the analysis some projects grewlarger than anticipated and extended well beyond the part to be
implemented, it shows that an overall picture has beenobtained thanks to the method and that provision for coherent
future extension will be built into the model. In addition themethods givecontrol on the project life cycle.
a number of weaknesses and inconveniences thatthe vendors endeavour to correct, all products proved to be stateof the art They provide an excellent basis for communication:
designers and users discuss over a full set of specifications
both graphical and textual, with agreed definitions andterminology avoiding misunderstanding. CASE appears thus
as a must for large projects, and prepares the ground for
subcontracting. Though at present CASE may seem anoverkill for smaller projects, it may be that as soon as thetechnology is well mastered it allows to produce !his type of
project in "no time".
No major problems were encountered when working in amixed environment. Most tools run on workstations andaccess the central repository installed on a server through the
network.
None of the tools for real time applications that were
evaluated run with ORACLE as internal repository. This is alimitation in CERN's context where ORACLE is a standard,
but no tool could as yet be found on the market that satisfies
this requirement
However, the use of CASE implies a real change of habit:
it requires an analytic approach and a disciplined style ofworking that contrasts with the previous free style. Also itneeds a relatively long learning curve: the longest probably for
ORACLE*CASE that often requires a good insight of themethod and its relation with the tools for efficientunderstanding; therefore training by the vendor is of great help.
Nevertheless, even after training, one should be prepared toinvest significant time in order to become fluent.
It was difficult to come to an agreement on the method
amongst the participants. The old debate between top down andbottom up design became vivid again. The top down approach!hat is followed by ORACLE*CASE was difficult to grasp inparticular by those who have a real time controls background.
They felt more at home with the method and tools for realtime application which tend to follow a more pragmatic middle
out approach.
The entity relationship technique on which
ORACLE*CASE is based led to some concern. NIAM on theother hand defines binary relationships between objects, and isfelt by some as a more natural method for data modelling. It
also provides diagrams that are more informative as they
include explicit notations for e.g. role, subtypes and procedural
constraints. A consequence of course is that NIAM diagrams
are less surveyable than the ORACLE entity relationship ones.
It is however possible to generate NIAM diagrams fromORACLE ones; the inverse operation is not possible becauseof loss of information.
The tools for real time application development highlighted
the well known problem of transfer of information between theanalysis and design phase. While it would seem that object
oriented methods might provide an elegant solution to thisproblem, no tool has yet provided such a solution. The
evolution of tools towards object orientation will thus need to
be closely followed
Because of the difference in version between ORACLE
database and CASE tools (one version behind the database) thetables and forms that were generated were not making full useof the capabilities provided by the latest database version. A
new version is scheduled for end of this year.
Several CASE tools exist on the market, each having their
specific development area. In the absence of a fully integrated
software engineering environment, one probably have to livewith a variety of such tools. Customers would already begreatly helped if all tools could agree on a (set of) common
repository (ies).
As a last and modest preliminary conclusion from the
management point of view: with rather limited resources it
was possible to introduce a reasonably large team into this, for
CERN's accelerators at least, new technology; one canestimate the number of software engineers in the accelerator
sector to date who are growing familiar with CASE, to around
30.

S15CSE01
CASE and Software Engineering

533
533

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-S15CSE01

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

ACKNOWLEDGEMENTS

REFERENCES

The authors are indebted to their colleagues at the European
Southern Observatory, Garching-bei-MUnchen, Drs. G. Raffi
and K. Wirenstrand, for valuable discussions and exchange ofexperience in the course of the evaluation of RTEE. They also
benefitted from the professional advice and consultancy of Drs.
J. Davis and L. Hickman both with ORACLE Corporation,

[IJ

U.K.

[4]

[2]

[3]

[5]

[6J

B.W. Boehm, Software Engineering Economics, 1981,
p. 16.
The Future of computed aided Programming, Corporate
Communications 09/88 on "How will Technology
affect America in the next 10 Years?", AEG 1988.
B.W. Boehm, op. cit., p.118
D.J .L. Martin, Practical Improvements in theManagement of Real-Time Software Projects, 1st
IFAC Workshop on Experience with the Managementof Software Projects, May 14-16, 1986, Heidelberg,
FRG.
Computerworld, April 22, 1991, p. 76.
Yourdon, Modem Sructured Analysis, 1989.

S15CSE01534

CASE and Software Engineering534

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, JapanThe SNL is block structured, as in C. A state may havemultiple when statements, corresponding to multiple
transitions from that state. Other features of the language
include: (1) macro definitions within database names, (2)network connection status of database channels, (3) access tochannel alarm status, and (4) synchronization through event
A state notation compiler generates efficient
flags.
reentrant C code from the SNL.
On the target processor a sequencer program initiates
and controls the execution of a task for each state set. The
sequencer establishes connections to database channels andhandles asynchronous events, such as might occur on amonitored database channel or loss of a network connection.

program detect_HV_level;
float
assignmonitorv;

shortassignlight;
light to "HV_PS_Ol: hv _light 11 ;SS

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S15CSE02v;

v to "HV_PS_Ol:output_volts";

testHV {state !nit {when () {light = O;
pvPut (light) ;} state Off}
state Off {when (v > 2500.)
light = l;pvPut ( 1 ight) ;} state On}
state On {when (v < 2000.) {light = O;
pvPut (light) ;} state Off}

III. INTEGRATING THE SNL INTO THE
CASE TOOLSETThe user first builds a model within the Teamwork
environment. By following existing conventions for realtime analysis and design[9], the Tuamwork will provide
various checks on the design. The specification for a
program begins at a process bubble within a data flow
diagram (DFD). An example is show in Figure 3.

•••

--~

.... .. sl..
.. .. ··.~

Figure 2. A SNL Control Program.
A complete program contains a program statement, adeclaration section, and one or more state sets (designated by"ss" in the SNL). Within a program, multiple state setscorrespond to multiple STDs. Some of the SNL features
include:Statement

program

Provides a name for run time execution.

assignAssigns or associates a variable with a databasechannel.

monitorCauses the channel value to be returned
asynchronously whenever it changes by asignificant amount.

SS

Specifies the start of a state set.

state

Specifies a state by name.

when

Specifies a transition, with the corresponding
events. When is followed by the event andaction statements and the next state.

pvPut

Function to put a value to a database channel.

pvGet

Function to get a value from a databasechannel.

'.

s2
Figure 3. Part of a DFD Showing Control
Connections to C-Specs.
Two "control flows" (dashed lines) from bubble 3 in thisDFD connect to the control specifications (C-Specs), sl ands2. Each C-Spec contains a STD, which corresponds to astate set in the program. Declarations, and other header
information are placed in the process specification (P-Spec)
that is contained within the DFD bubble. The events andactions are placed in the STD on the transitions. Because
actions could be very complex - too many characters to fit
conveniently on the STD - each action must be specified as
the name of a P-Spec.
A translator builds the SNL program from theTeamwork model. This translator accesses the CASE model
database using the Cadre Teamwork/Access interface
routines[lO]. To use the translator the user specifies themodel name, the bubble number (default bubble is 0), andthe output file for the SNL program. The topography of the
DFD and STDs determine the program structure, and thecontents of the STDs and P-Specs determine the details.

S15CSE02536

CASE and Software Engineering536

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

ICALEPCS1991, Tsukuba, Japan

We have used the translator on only a few simple test
cases. The CASE tool methodology is a little awkward touse, especially when the programmer must go back and forth
between the CASE environment and the run timeenvironment during program debugging. On the other hand,programmers have been highly pleased with the SNL. We
are investigating the idea of designing a graphic editor thatwould be more appropriate than the CASE environment.
Although we have made no measurements, we estimatethat the use of the SNL rather than C has saved significant
programming time, and that performance approaches that ofprograms written in C.

[1]

[5]

Wilson, William L., Marcus W. May, and Andrew J.
Kozubal, "Rapid Development of a Measurement andControl System for the Advanced Free-Electron
Laser," submitted to Thirteenth International
Free-Electron Laser Conference, Santa Fe, New
Mexico, August 26-30, 1991.

[6]

Kozubal, A J., L. R. Dalesio, J. 0. Hill, and D. M.
Kerstiens, "Run Time Environment and Applications
Tools for the Ground Test Accelerator Control
System," in Accelerator and Lczrge Experimental Physics
Control Systems, D. P. Gurd and M. Crowley-Milling,
Eds. (ICALEPCS, Vancouver, British Columbia,
Canada, 1989), pp. 288-291.

[7]

Dalesio, L. R., 'The Ground Test Accelerator
Database: A Generic Instrumentation Interface," inAccelerator and Lczrge Experimental Physics Control
Systems, D. P. Gurd and M. Crowley-Milling, Eds.
(ICALEPCS, Vancouver, British Columbia, Canada,1989), pp. 288-291.

[8]Hill, J. 0., "Channel Access: A Software Bus for the
LAACS," in Accelerator and Large Experimental Physics
Control Systems, D. P. Gurd and M. Crowley-Milling,
Eds. (ICALEPCS, Vancouver, British Columbia,
Canada, 1989), pp. 288-291.

[9]

Hatley, Derek J. and Imiaz A Pirbhai,, Strategies forReal Time System Specification, Dorset House
Publishing Co., 1987.

CONCLUSIONThe STD paradigm is useful for implementing real time
control. Automating the translation from STD to a run time
program is expected to introduce fewer coding errors andprovide better design documentation. Acceptance of thismethodology may depend on providing a more user friendly
graphic interface.

VI.

Particle Accelerator Conference, San Francisco,California, May 6-9, 1991.

REFERENCES

Ward, Paul T. and Stephen J. Mellor, Structured
Development for Real Time Systems, 3 vols.,
Prentice-Hall Inc., Yourdon Press, 1985.

[2]

Teamwork/RT User's Guide, Release 4.0, Cadre
Technologies Inc., Providence, RI.

[3)

Kozubal, A
L. R. Dalesio, J. O. Hill, and D. M.
Kerstiens, "A State Notation Language for AutomaticControl," Los Alamos National Laboratory report
LA-UR-89-3564, November, 1989.

[4]

Atkins, W., "Using the EPICS Sequencer Tool to
Automate the OTA Vacuum System, " submitted to[10] Teamwork/Access, Teamwork/RT User's Guide,
Release 4.0, Cadre Technologies Inc., Providence, RI.

S15CSE02
CASE and Software Engineering

537
537

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

rv. EXPERIENCE AND FUTURE PLANS

V.

JACoW Publishingdoi: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

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingeffectively manage the design process. The fact that our
choice has been to use an RDBMS reflects the desire tolearn new software technologies as well as to avoid the paper trail of pa.st accelerator construction experience. The
lattice database effort should be regarded as one of thefirst experiments at the SSC in using new technical organizational schemes.
SYBASE is one of the major SQL (structured query language) RDBM systems available. It runs on a variety of
hardware platforms, and has an excellent network interface. Lattice database applications have been written using C and the Open Client/C software library supplied
by SYBASE. The performance of these applications has
been exceptional. In the future the applications should be
written with embedded SQL so that other users at different sites should be able to use the lattice database systemwith another RDBMS.

needed by TRACE3D, a linac design program in generaluse at the SSC.
In principle it is now straightforward to adapt to new
demands on the data structure by creating new tables
when necessary. For example, in order to describe thelayout of the assembly of magnets to determine the existence of physical interferences, information concerning
the outside dimensions of magnet elements is needed in
the database. This information is maintained in a table
known as magnet..size which contains columns detailing theshape and external dimensions of a given element. The primary key of this table (and most others) is the element's
name. Breaking this information off into another table
rather than adding a new column to the magnet..piece table for example, helps to separate applications which are
independent of each other. For example a beam line survey program which models physical interferences may require information about the outside dimensions of beamline components, but does not need the magnet strength
values appropriate for linear optics calculations.
SQL example
An example ofSQL code which creates the magnet_piecetable:

III. LATTICE DATABASE

Lattice Structure as Database Tables
In creating the lattice data structure, we have adopted
the MAD 8.1 element definitions[4] since MAD provides ade facto standard for accelerator design descriptions. Eachlattice is assigned its own database in the RDBMS with thesame set of generic tables in each database.
A generic lattice database is made of five primary tables: beamJine, slot, magneLpiece, geometry, strength,
and 12 secondary tables: quadrupole, sextupole, octupole, multipole, rfcavity, bend, drift, collimator,
closed_orbit...corrector, monitor, else par a tor and solenoid.
The primary tables define a basic lattice hierarchy of beamlines, components and parameters and the secondary tables provide additional information which completes theMAD 8.1 element definitions.
The beamJine and slot tables define the beam line hierarchy. Drifts, magnets or other elements are entered into
'slots' as sequences of character strings by their names
and slots are strung together in other character strings
to make beam lines. Beam lines can also be concatenatedinto larger beam line structures and so on.
The magneLpiece table contains columns which describe
the basic physical properties of each element such as its
type, length, strength, etc. The geometry and strengthtables store physical parameter names and values such a.slengths and magnetic properties such as field values or field
gradients. Two tables were created for parameters insteadof one because there will certainly be different versions of
the strength table associated with different operating conditions of an accelerator such as injection, collision andpoints in between. The application program can be directed to choose the strength table of choice.
In our experience to date the MAD element definitions
have been appropriate for all accelerator lattices excepting
the linac. In order to provide a faithful database representation of the linac design, we have had to implement anadditional set of tables which define new lattice elements

create table magnet-piece(namechar(20),
type
varchar(20),ti! tvar char( 10)length_defn
varchar(60)strength_defn
varchar(BO)engineering_type varchar(20)comment
varchar(130)

null,
null,
null,
null,
null)

The first column above specifies the table's column names. They are name, type, tilt, length_defn,
strengtLdefn, engineering_type and comment. Name isthe ascii name of the beam line component. Type refers to
one of the MAD element types such as drift, quadrupole,
sextupole, etc. Tilt specifies the orientation of the magnetic element around the beam line. The meaning ofstrength_defn can depend on the type. For example, thequadrupole strength is proportional to the gradient of
the magnetic field, and the sextupole strength is proportional to the second partial derivative of the magnetic fieldstrength. Symbolic algebraic expressions-for these quantities can be entered in this column as long as the parameters used are defined elsewhere in the geometry or strengthtables. Engineering_type is an alternative name which theuser may introduce to flag components for special purposesin the application codes.
The second column above specifies the data types. For
this table these data types are 'char' and 'varchar'. These
character field types differ from each other in that char uses
all of its allocated space and varchar only stores that portion of the allotted space of the field which is actually used.
Finally, the null qualifier on some columns means that nodata is required in that column; both name and type being

S16MS01
Modelling and Simulation

539
539

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-S16MS01

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 Publishing

non-null are required to be entered by the database user.
The other database tables have similar structure, and alltables have a unique index defined on the primary key,usually the first column. These indices help maintain the
integrity of a table by prohibiting multiple entries with thesame primary key.

the user to modify the magnetic strengths and recomputethe optics.
Finally, the interface should include a particle tracking
module. The tracking module would use a fixed initialemittance profile to define positions and momenta of asmall number of particles, and then propagate these particles and display the resulting emittance profile. This isdone after one turn for circular lattices and at the end fortransfer lines. The stated goal of the particle tracking module was to provide the user with a convenient way to modify
steering elements strengths and see the result graphically.
In this way one could study the effects of beam apertures
quickly. The tracking module was not intended to model
the various errors in magnetic field strength or alignment.
It provides an ideal view of the particles' motion.

doi:10.18429/JACoW-ICALEPCS1991-S16MS01

IV. USER INTERFACE to DATABASE
dbsf (database to several formats) is the primary interface to the lattice database. It is written in C and uses theOpen Client/C libraries provided by SYBASE. To run dbsf
one supplies any lattice keyword such as a beam line, component or parameter name. dbsf first performs a query
to determine the location by table of this keyword, andthen searches that table for information about the key. Ifother keys are associated with the primary key, these arealso made the subject of similar database queries until nofurther unknown keys are encountered. At this point an
extended symbol tree has been constructed within dbsf anddepending on one of many options selected at the UNIX
command level, dbsf will format an input file appropriate
to that option. The first options available were for MAD.
Since that time, all the accelerator codes listed in the introduction are supported.
Recently, an option to create a binary dataset using the
SDS data discipline has been installed. SDS is provided
as part of the ISTK tool set. The SDS dataset binds a
description bf the data structure used to create the data
within the dataset itself as a header object. Consequently,
within the context of database applications, SDS data canmaintain the integrity of the database structure outside of
the RDBMS. Application programs that read generic SDS
data can then be used with this data. In particular, SDS
data can be passed from one RDBMS to another through
ISTK supplied interfaces. Such interfaces can provide asimultaneous solution to the problems of making heterogeneous database system communicate effectively and also
allow large data to flow quickly from one point on a network to another. Several programs which are specific tolattice issues will be discussed below.
V. GRAPHICAL INTERFACESoz
Early in the development of the lattice database, thedesign of a graphical interactive view of the complex ofaccelerators was begun. The name of this program is OZ.
OZ was required to display a geometrical view of the entire
accelerator complex and to have the ability to use a 'mouse'to select a part of the accelerator system and see that area
visually expanded in greater detail while displaying therelevant properties of the selected beam line components.
In addition the interface was required to provide a basic
simulation environment for each of the accelerator lattices.
Consequently, it should not only display the design valuesof linear optical properties (betatron functions, dispersion)correlated with selected regions of a lattice, but also allow

Figure 2: Betatron Function Window in OZ
As the general computing environment of the SSC Accelerator Division is based around UNIX workstations running the Xll windowing system, the graphical tools used tobuild OZ were chosen to be compatible with this environment. The original development was begun using the InterViews 2.6 toolkit[5], but was later changed to the graphics
libraries provided with ISTK. These graphics tools, known
as glistks, are based on a subset of Inter Views' Interactor
class and are tailored to build scientific graphical interfaces.
The interactive capability of OZ is manifold. After selecting one of the lattices from the command window, OZ
displays the geometrical view of that lattice in the display window. One can select a portion of that lattice for
expansion by grabbing the region with the mouse. One
menu then allows you to view that lattice from different
two dimensional perspectives, or to query the database tofind a particular beam line name. Another menu allows
the user to view the linear optical properties. A one dimensional version of the lattice is displayed at the top of
this view so that the user can tie the optics to element
locations.
Finally, one can select the tracking menu in order todefine initial parameters for particle tracking such as

S16MS01
540

Modelling and Simulation

540

coordinates and momenta or change the desired emittanceprofile. OZ will then track the particles for a few turns
and display the final profile in a series of windows showing
horizontal and vertical phase space as well as the purely
spatial transverse profile of the beam.
LATVIEW
Another graphical interface to the lattice database iscalled LATVIEW. This program was designed to allow visualization of the lattice hierarchy. A lattice such as themain collider ring of the SSC is composed of more than
20,000 elements including drift spaces, magnets, beam position monitors and position markers. The collection ofbeam lines which combine these elements into a lattice design is sufficiently complicated that a graphical interface
to its structure is absolutely necessary for most users.
LA.TVIEW uses the SDS output from dbsf as its sourceof information for display. This SDS dataset includes as
one of its elements the enumeration of the 'level' at whicha beam line exists in the hierarchy. The notion of levelis defined so that level 0 corresponds to a completely fiat
lattice, i.e., with all trace of the beam line hierarchy eliminated. Levels 1 and 2 show the relationship of the basic
belong, and levels 3 andelements to the slots in which
so on define the tree of nested beam lines whose highest
level corresponds to the complete lattice's name, thethe dataset.
inal
to dbsf needed to

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS01

VI. CONCLUSIONSThe SSC lattice database has been in existence for two
years. It has been an essential part of ongoing operational
simulation investigations as well as being the basis for engineering drawings of each accelerator system and the geographical footprint of the entire complex of accelerators.
As the SSC moves into the construction phase, additional
database structures will be needed to describe the hierarchy of cryogenic, electrical and control systems that overlay
the basic lattice designs. In addition the specification of an
automated storage/retrieval system for the names and locations of the multifarious pieces of equipment that are attached or associated in some way with the lattice complex
is essential. Some of these problems are under investigation, and present efforts are directed at the determinationof requirements for these global data.base systems.
References[l] E. Barr, S.
March 1989.

and C. Saltmarsh,

SYBASE, Inc., 6475 Christie Ave., Emeryville, California, 94608.

[3] C. Saltmarsh, M. Allen and S.
lished internal documentation at

ISTK, unpubJ uly 1991.

[5] Mark A. Linton, InterViews Reference Manual, v.
February
Stanford University,
California.

3: Lattice Hierarchy of LEE from LATVIEWLATVIEW displays information on each element (beamline or individual magnet) by placing the mouse on theelement of interest. This action provides sufficient information to point back within the SDS dataset and pick out
the relevant information pertaining to that element. The
information is displayed at the bottom of the LATVIEW
window. One can also select a part of the lattice withthe mouse, and LATVIEW will show the expanded view.
In addition to its display of the beam line hierarchy,
LATVIEW will also display groups of magnets by type. So,for example, if one is interested in locating all quadrupole
locations along the beam line, LATVIEW provides a convenient way to do this visually without losing the relationships of these magnets to their parent beam lines.

S16MS01
Modelling and Simulation

541

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-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 Simulation542

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingcal. All that should be required is a recompilation for each logical clocks to support virtual synchronization between
coordinating processes across the netwoti:[8][9].
graphical display wo:r:kstation.
A multitasking environment shall be incorporated to provide
synchronous and COilC\lIIent behavior oo a single system.
DESIGN
Tusk synchronization can be performed using any of the typiBased on the requirements listed in the previous section
cal real-time mechanisms (e.g. semaphores, message queues,
we have established the following design specifications.
mailboxes).

Virtual Control Modules

C. Distributed Computing Services

The control system shall accommodate the adaptability,
A peer-to-peer message passing mechanism shall behierarchy, and continuity requirements by incorporating a
implemeoted to satisfy the distributed communications
recursive architecture. This may be expressed using the modirequirements. This mechanism should have a programming
fied Backus-Naur Form (BNF) formalism which is often usedinterface which is independent of the network transport layer
to specify computer language syntax:
implementation. The design should be efficient enough toconsider using it equally for local or remote task-to-task comVirtualC011trolModule = ComrolModule + [VirtualMachineJ+<1l municatioos.
(2)
The control system should also support both messageVirtuaIMachine =Machine I VirtualControlModule
based and remote procedure-based communication mechaThe VirtualControlModule is the control subsystem con- nisms. Message-based mechanisms will probably be best
sisting of a controller (Contro/Module) and one or more con- suited for event-driven processes which would normally betrolled objects (VirtualMachine). The VirtualMachine may looping on an input message queue. Remote procedure-based
consist either of the bare Machine or, recursively, of an addi- communications will be best suited to transparent migration
oflibrary modules from local to remote configuratioas.
tional VutualControIModule subsystem.

The Machine represents the accelerator and its associatedinstrumentation. This system may be represented by a set of nmeasures (S'.ate variables) and its development over time may
be expressed by trajectories of the state variables in state
space. During the development and testing phases, theMachine might be replaced by a simulator which emulates allcommand and response characteristics of the real machine.
The ControlModule is required to counteract any motionof the machine system away fonn the stable operating point.
The combined subsystem (Contro/Module + VirtuaIMachine)
should be asymptotically stable. In the adaptive control system the ControIModuk is a mutable element. Its state paraineten are dynamically adjustable, it might be layered,parallelized, or self-adaptive. It shall also be dynamicallyreplaceable by an alternative ColllroIModule with synchronized exchange of control between the ControlModules.
This model can describe all of the standard control systems in use today. The following expressions represent a few
such systems.
RemoteControlSystem = ControlModule +MachineSupervisedControl = ControlModule+ (ControlModule +Machine)(3 )A control system which accommodates VirtualControlModules will permit the control system to be modularly adjustable and to incorporate growth (and scalability) andevolution.

B. Distributed Task Synchronizaiion

Communications Manager
An object communications manager shall be implemented
to satisfy the dynamic task association requirement. The
object communications manager will coordinate the interaction between applications and all other elements of the control
system. The control system elements will be composed ofsoftware objects which interact to perform their assigned
functions. Some of these objects will .. advertise" their presence to external applicatioru; by registering with the object
manager. External applications will query the object manager
to select and associate with the advertised interfaces. The
object communication manager permits the association to be
dynamic and tramparent. New control system objects can besubstituted without requiring a restart of either the user applications or the control system modules. Moreover, the user
application need not know whether or not the control systemmodules are operating locally or remotely • the interface is thesame for both (the mechanism is similar to the X-windows
byte-stream implementation). The operator interlace applications are specific examples of applications which will use theobject communication manager to interact with the control
system.
All potential Contro!Module and VirtuaIMachine modules
must satisfy uniform interface requirements with respect tothe object communications manager. This permits the modules to be dynamically replaced during operation and without
requiring the reconfiguration of existing modules.

E. Network-Based GUI

A synchronization mechanism shall exist to coordinate
A netwod::-based graphical user interface (GUI) shall beinteraction with the machine elements and peer subsystems. incorporated to satisfy both the universal graphics application
The distributed machines shall incorporate partially ordered programming interface and the distributed control require-

S16MS02
Modelling and Simulation

543
543

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-S16MS02

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

any POSIX compliant interface and is composed of elements
which are available commercially today.
'These utilities will soon be available on all major variantsof the UNIX operating system. Initially, it will be available
from OSF on their POSIX compliant operating system, andlater it will be available from the Unix Software Laboratory
fonn.s.
(USL) on their SVR4 UNIX base. The Open Network Computing {ONC) utility set which is the dominant remote proceIV. FRAMEWORK
dure call facility in use today will probably adapt to
The following framework was established to implement
incorporate DCE compatibility.
the design specifications from the previous section. The
framework is based on existing technology and/or standards.
D. Object Request Broker
This was done not only to take advantage of commercial
The object communication manager facility will be proproducts and conununity efforts but also to guarantee a morevided
by the Object Request Broker (OMG/ORB) which istimely implementation of the composite system. We
attempted to select a minimal framework to avoid an overly being specified by the Object Management Group in collaboration with several large computer companies[l5]. Early verrestrictive development environment.
sions of this facility will be available from Hewlett-Packard
and from Sun Microsystems.
A. Eiffel Object-Oriented Environment
A working example of this facility, ToolTalk, is currently
The Eiffel object-oriented programming language andavailable from Sun Microsystems for use on their workstaapplication environment will be implemented to satisfy thetions[l6]. Our first ORB compliant applications will probably
virtual control module design specification[lO].
be based on this tooll:::it.
Object-oriented environments support modular softwaredevelopment, data abstraction, polymorphism, and dynamic
X-Windows, Motif, and IEEE 1201.1
binding - all of which are required to satisfy the virtual control
The network-based graphical user interface will be promodule specification. Eiffel in particular also supports automatic memory management, multiple inheritance, enhanced vided by the MITX-Wmdow system, the Motif graphical user
reusability, and a special reliability feature {assertions) which interface, and the evolving IEEE 1201.1 universal application
supports a 'software by contract' design methodology. The programming interface libraries.
The only universal, network-based, window environment
language specification is now in the public domain and has astrong international and educational backing which should available today is the X-Wmdow system. The latest release(Xl1R5) is fast, supports scalable fonts, and runs on every
assure its continual evolutioo.
major UNIX workstation. A large amount of public domain
software is available for this windowing environment.
B. POSIX 1003.1 Operating System
Unfortunately, there are several competing, incompatible,
The standard multitasking operating system will be a realgraphical user interfaces available for the X-Wmdow system.
time operating system which is compliant with the IEEE specThe OpenLoolc GUI is being promoted by AT&T and Sun
ifications for a portable operating system interface (POSIX
Microsystems, while the Motif GUI is being promoted by the1003.1). It will also support the real-time extensions (IEEEOpen Software Foundation (OSF) and most of the other work1003.4) which are presently awaiting finalization.
station vendors. However, to our knowledge the Motif winAt the higher machine architecture level we will selectdow manager and application programming interface is alsoeither the LynxOS or else the O:iorus real-time operating systhe only environment which runs universally on all presenttem( 11][12]. Both of these are network-based, POSIX comPosix compliant systems. Moreover, a number of Motif compliant, and support real-time computing features.
pliant GUI tools are available for most of these platforms.
At the lower machine control level we will use the
The IEEE 1201.l committee is developing a specification
VxWorks operating system(13]. This is a network-based,
for a standard GUI programming interface which can be used
embeddable real-time operating system with a wide support
with any of the X-Wmdow GUis in use today. We will adopt
base in the VME environment. VxWorks will provide athis standard when it becomes available, but in the meantime
POSIX compliant interface when the real-time extensions are
we will use the Xm-based tooll:::it from OSF for their Motif
finalized.
GUI. Wherever possible, we will also be using the Eiffelbased graphics toolkit from Interactive Software EngineerC. Distributed Computing Environment
ing[l 7].
The distributed computing environment (DCE) will be
implemented using the OSF/DCE utilities from the OpenV. PROJECT STATUS
Software Foundation (0SF)(l4]. These utilities will provide
We have developed several prototype components to test
basic services for remote procedure calls, network security,someelements of this framework.
and distributed file systems. The OSF/DCE is layered uponments. The graphical display will be presentable on any candidate workstation on the network. The display application
may reside either within the workstation or else on someremote computer. The interface must function in a heterogeneous environment and should function on a variety of plat-

S16MS02544

Modelling and Simulation
544

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS02

A class library for accelerator modeling and simulation

has been coostructed using Eiffel. Another Eiffel class libraryfor the hardware database access is also being developed
which interfaces with the LBL/ALS control system. Using
these class libraries, one can create accelerator models
dynamically with on-line and real-time access.
Several network-based, object-oriented device handlers
have been written
under the VxWorks operating system on a VME target system. The8e handlers are
rewritten in Eiffel. An object management broker for VxWoru isalso in progress.

[l] S.A. Lewis, A.K.Biocca, R.D.Dwinell, J.R.Guggemos,
L.L.Shalz, W.L.Brown, G.S.Boyle, K.Fowler, and D.L.Meany,
Progress on a New Control System for the Bevelac, IEEE Part.
AcceL Conf., Vol 89CH2669-0(1989)164S.
[2] S.Magyru:y, M.Qrln, C.Cork, M.Fahmie, H.Lancllllter, P.Molinary, A.Ritchie, A.Robb, and C. Timossi, Advanced
Source Control System, IEEE Part. Acee!. Conf.,
89CH2669-0(1989)7 4.
[3] M.Lee, S.Clearwater, E.Thiel, and V.Paxson, Modern
Approacl:ies to Accelerator Simulation and On-Line Control,
IEEE Part. AcceL
Vol. 87CH2387-9(1987)611.
[4] S.H.Clem:water, andDevelopment of a Beam
Lloo
System, IEEE
Conf., \101. 87CH2387-[SJ
Coof.,[6] Bart K.ollko, Newm Netwocb andlail
to ;vu;o..uu.•"' AD•"''"lh"'"''"""
NJ, 1992.
[7]
and K.Veo:w:I, Iru!l:mmoot Engint<>-rs• Handbook,._..,.,..n,a. Chilton, Radnor, PA, (1985) 713.
[8] C.Fidge, Logical Time in Distributed Computing Systems,
IEEE Computer, VOJ..24,No.8(1991)28.
[9] Tuts.A Distributed Programming Environment, Version 2.0
user's guide and reference manual, Cornell University (April
1990).
[10] Bertrand Meyer, Object-Oriented Software Construction,
funtice Hall, Englewood Cliffs, NJ, 1988.
[11] LynxOS, Lynx Real-Tune Systems, Inc., Los Gatos, CA, USA.
[12] CHORUS/MIX, Chorus Sylltems, Beaverton, OR, USA.
[13] VxWorka, Wmd River Systems, Inc., Alameda, CA, USA.
f14] Distributed Computing Environment, Open Software Foundation, Cambridge, MA, USA.
[15] Object .Request Broker, Object Management Group, San Francisco, CA, USA.
[16] ToolTulk (Beta) Programmer's Guide, Part No: 800-6093-0S,
Sun Microsystems, Inc., Mountain View, CA, USA.
[17] Ellfel Graphics Library, Interactive Software Engineering,Inc., Gole~ CA, USA.

S16MS02
Modelling and Simulation

545

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-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 Simulation546

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Figure 1: Opening Screen for LEP Model Program

Figure 2: Menu to Change Optical Configuratione Deliver the following files to MAD:
L The definition of elements (magnets, cavities,etc.) in the ma.chine, and the sequence of theiroccurrences. This file is built in the Ora.dedata.base and formatted in the standard MAD
input language. It only changes when the LEP
ma.chine is modified physically.
2. The current optical configuration (magnet excitations). This file is a TFS table selected fromthe reference data set, or built by reading the actual power converters by launching a. speciali.zed
program.
3. The "imperfection file". This file contains known
imperfections of the machine, like measured multipole components in the machine dipoles. It is
updated manually when such imperfections become known.
4. The "trim file" introduces factors to compensate
observed errors of the model. The corrections a.reconstructed by trial and error, and do not necessarily represent actual imperfections of LEP.
• Allow interactive increments of element excitations.
e Allow interactive assignment of element displacements.
e Set up a MAD command file to zead the above files,
and to perform the desi.ted computations.
a Launch MAD on the DN 10000 server.
e Present a table of results on the display.
" Optionally plot the results on ihe display.
In the standard version of the LEP Model Program all
operations mlllit be done in such a way as to avoid MAD
to fail du.ring computation.

Figure 3: Menu of Available Optical Configurations

2.2

Examples of Menu Selections

The opening screen of the LEP Model Program is shownin Figure 1. Selection of the "Change Optics Configura.~tion" icon pops the menu shown in Figure 2. It presents
options for selecting configuration files. Selection of "Fromcunent run specification" then presents the menu of Figure 3, containing all states for the current tun. To computethe optical para.meters in selected positions the user first
selects "Local Optical Parameters" from the main menu
and gets the menu shown in Figute 4 After selection of"Select Elements" the progzam pops the menu shown in
Figure 5 which allows to select the positions where to calculate the para.meters. Selection of "Select Pa.Iameters"then presents the menu of Figure 6 offering the available
optical functions. While it is computing, the LEP Model
Program displays a. screen like in Figure 7. The results
may be plotted as shown in Figure 8.

3

Implementation

3.1

Choice of User Interface Package

Domain/Dialogue was chosen for the following reasons:

S16MS03
Modelling and Simulation

547

547

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-S16MS03

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

Figure 4: Menu for Local Optical Para.meters

Figure 6: Menu to Select Output Parameters

Figure 5: Menu to Select Element Positions in the Machine

Figure 7: The LEP Model Program is Computing ...

e

Dialogue allows to define and modify the user interface
independently of the application program. The userinterface can be built and tried before writing a. lot of
code.

o

Dialogue is quite powerful, and easy to use and maintain.

oDialogue has been used extensively at CERN.

Unfortunately one cannot use the UNIX standard
system call (nor fork + execl) to spawn another process on th DN 10000. It was found that under the current
release of the Apollo UNIX system (SR 10) these calls may
crash the operating system. MAD is therefore launched by
the Aegis command crp (create process). This command
can use the current login name and password of the user,
and can be called by the program in a transpm:ent way.

e

Since most of the workstations are Apollos, there is
no problem in using a non-portable package.

3.3

Dialogue can be used with FORTRAN, Pascal and C programs. FORTRAN requires use of non-standard types like
INTEGBB.•2, and of contorted EQUIV!LE!lCE constructs tosimulate Pascal or C structures. Pa.seal is little used at
CERN. C has been chosen chiefly because it is the main
programming language used in the LEP control system.

3.2

Running MAD on a Remote CPU

The LEP Model Program requires a graphics display, thus
it must run on the user's workstation. For speed reasons
MAD must run on a more powerful computer, like the
DN 10000.

Data Transfer

The UNIX file system makes it easy to access files fromremote nodes. All data transfer uses ASCII files residingin the user's current directory. MAD input files are in
ASCII TFS format where feasible, or in MAD input language. MAD output files are written in MAD language,
as TFS files, or as listings. This solution allows to develop
and test the LEP Model Program independently of MAD
by looking at those ASCII files.

3.4

Plotting

Most results come out of MAD as a TFS table. On request
the LEP Model Program invokes the LEP data.viewer in a

S16MS03548

Modelling and Simulation548

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

ICALEPCS1991, Tsukuba, Japannew window, to plot the newly computed data. The user
is free to use data.viewer tools (graph selection, zoom ... )to study the shape of the curves, and a hard-copy of thescreen can be ma.de on a. Tektronix printer.

Future Plans

The LEP Model Program will mainly have to be expandedin the area. of interaction with the control system. Operation requites more choices for matching machine parameters, and for introducing the new excitations into the machine. For safety the changes will be introduced by hand,and possibly in small increments; thus effectively creatinga "knob" which can be turned to apply a correction to any
percentage varying from zero to full value.
In future the program should also generate complete setsof files which can be used to set up a new configuration.
Possible options are the following:
111

111

111

Match excitations to achieve the desired behaviour ofthe machine, and return the excitation file.
Compute a table of optical parameters for the machine.
Launch a program to split the table of optical parameters and to feed the parts into various components ofthe control system, e. g. the closed orbit correction
program.

optical configurations during machine development. During operation it has been used successfully for calibrationof equipment, to test hypotheses a.bout misalignment andmispowering; this has contributed to the comprehension ofvarious effects in the machine.
The accelerator physicists doing ma.chine development
usually have a better knowledge of the MAD program, andthey wish to have more freedom in using the LEP Model. A
special version of the LEP Model is provided which allows
to use private files and/or to edit the files provided by
the system. However, this version offers little protection
against use of wrong data.
The choice of Domain/Dialogue makes this program
modular and expandable. Since the system is event-driven,changes are very simple. To a.dd a new feature it is often
sufficient to add a few lines to the interface file, to writeand compile a. new C routine, and to relink the program
without touching any existing C code. Even major rearrangements of the menus are feasible by editing the interface file and by relinking without recompilation.

References[1] P. G. Innocenti, "The LEP Control System". International Conference on Accelerator and Large Experimental Physics Control Systems, Vancouver, Canada.,
Octobe:r 30-November 3, 1989.

[2] H. Grote and F. C. Iselin, The MAD Program, Version 8.4, User's Manual. CERN/SL/90-13 (AP), Rev.
2, August 1991.
[3] H. Grote and F. C. Iselin, "Recent Developments in
MAD Version 8". International Conference on Accelerator and Large Experimental Physics Control Systems,
Vancouver, Canada, October 30-November 3, 1989.
[4] D. C. Carey and F. C. Iselin, "A Standard Input Language for Particle Beam and Accelerator Computer
Programs". 1984 Summer Study on the Design and Utilization of the Superconducting Super Collider, Snowmass, Colorado, June 23-July 13, 1984.
[5] Ph. Hofmann, Table File System, Reference Guide.
CERN/LEP LAW Note No. 9 (unpublished).

e Launch a program to set the magnet excitations.
e Launch a program to compute the effect of quadrupoleand sexiupole strengths onto machine tunes and chroma.ticities.

5

Conclusions

The LEP Model Program has been found to be a very
useful tool for ma.chine setup, as well as for testing new

S16MS03
Modelling and Simulation

549
549

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

Figure 8: Example of Closed Orbit Plot (one quadrupole
displaced)

4

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS03

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

ICALEPCS1991, Tsukuba, Japangj, if ~ > Q.i- 1

Assume, that measurement of a quality function and measurement of vector X are produced only in discrete moments oftime

ti = j.6.t

U= 0, 1 ..... n)magnitudes of vector X of controlled variables on each j-th step
are designated as Xj; Ij = I(XJ), Qi = I(Xh +A way of determination of a step value .6.Xj = xJ - xj-1 is
specified by a search algorithm. Summarization of the methods being compared:
Random search, including punishment of randomness. A
next step in the space of controlled variables is determinedaccording to the rule:

IJ.6.Xj, if ~ > ~-1= (a..::::j+l, if Qj .$. ~-1(swhere .:::: = i ...... ~n) is a random vector uniformly distributed on a sphere of unit radius; a is a step scale.
Scale of a step is adapted during search according to the dependence
Q = Ao exp{L x [N2(1 + .6.n2rr2)+ (supN)2(1- .6.n2!T2)]J
where Ao is initial scale of a step; N is number of unsuccessful steps, implemented from a last point; supN is maximum
number of unsuccessful steps, implemented from any point
during all the process of search; .6.n is difference between anumber of a current point of search and number of a point,where supN of unsuccessful steps has been performed; T is
maximum permissible distance between a current point ofsearch and a point, from which sup N of unsuccessful steps has
been performed; L is parameter, determining dynamics of step
adaptation.
Random search with gradient estimation. Searchrithm has the following view:.6.Xj, if ~ > Qj-1
.6.Xj+l = {cd+lsj/ lsj I, else
where a is scale of a operating step; S is stochastic estimateof a gradient, determined by the following algorithm:

sj = l/(2mgj)L\jl=l (Q(Xj + gj:::;'V')- Q(Xj - gj;=:}V)E:'V
where m .:S. n is the number of pairs of trials for gradientestimation; gj is a value of operating step; .:::;j is vector,
uniformly distributed on the sphere of unit radius.
Scales of the operating and trial steps are adapted during
search in accordande with the following dependences:aj, if ~ > ~-I~={~/N+l, if ~ .$. ~-1

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS04(

gjf--JN+l, if ~ .$. ~-1
N is the number of unsuccessful steps for all the previous process of search. Besides:a) If the process of gradient estimation reveals positive
augments of quality function, transition to a trial point, that is

xj + gjsj/ lsj I, if .6.~+1 = xj+1 = xj + .6.Xj ={= max(.6.Q.i+l, .6.Q.i•'V) l
Xj + gj::;W, elseb) After a step along estimation of a gradient a concluding stateis determined by maximum increment of quality function attrial and operating steps, that is
xj + gJ::::'¥, if
xj = {else.6.~·'V >oRandom search with self-learning. Rule of step calculation this algerithm is the following one:

where R = const > 0 is radius of guiding sphere; :::: is vector,
uniformly distributed on spere of unit radius: wJ = CW 11, .....
WnJ) is vector of memory, lwJ I< C, C = const > 0.
wJ = c grad I(Xo);
wj+1

lWi- MQj.6.Xi

where 0 < l < 1 is parameter of forgetting; o.<!. 0 is parameterof self-learning; .6.~ = ~- ~- 1 is augment of functional at jth step.
Sequential simplex planning. Essence of optimization bymeans of this method consists in the following .
Regular simplex, centre of which is at the start point, isconstructed in the space of controlled variables, and quality
function is estimated at all its vertices:
Q(Xj), j = 0,1,2,-·· .. n.
Then a trial step - mirror reflection of a worse vertex,
where quality function is minimum, is performed through acentre of the opposite facewhere xrfl is reflected vertix position vector; xc is a vector of
the face centre position; xwt is position vector of the worse
vertix.
An operating step follows after a trial one to a point,
which is detennined according to the rule:

S16MS04
Modelling and Simulation

551

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 Publishingis tension;

All used criteria of methods comparison are divided into
two classes: local and integral ones. The first class is concerned with a single elementary stage of search-operating step,
the second one- with all the process of optimization since a
start moment till operation of the rule of breakpoint. The following criteria of comparison were used:- losses for search. An average local rate of optimization isdetermined and the following calculation is perfonned:

doi:10.18429/JACoW-ICALEPCS1991-S16MS04

is compression;
xrfl, if Q(x.i) < Q(xrfl) < Q(XWl); j -.t wt(If Q(xwt) < Q(xrfl) < Q(Xj) j *wt then xwt is substituted

for xrfl and compression is produced). Here, the following
designations are taken: xend is position vector of theoperating step end; xwt is position vector of the best vertix;y > 0 is coefficient of tension; 0 < p < 1 is coefficient ofcompression.
Subsitution for a vertix, depending on an operating step
result, is produced according to the rule;
xend. if Q(xend) > Q(xrfl)
xwt = [:xrfl' if Q(xrfl) > Q(xend)- in tension
xend, if Q(xend) > Q(XWl)- in compression
If after compression

then initial simplex is drawn to the best vertix:
Xj = 0, S(Xj + xwt),

j = 0,1, ..... n

Then process is repeated since a moment of determinationof a worse vertix.
Study of the methods was carried out with the use of a test
nonlinear function in two modifications Q1 - separable
quadratic form, complicated by noise
Q1 (X.~) = xTBx +Bo+~.
where B is diagonal coefficient matrix, determined as approximation of results of statistical identification of an object. Bo
is a free term, ~ is noise addition; Q2 - unseparable function,
having a modular surface of "two-dimensional backbone"
Q2(X,~) = L:BiiXi 2 = IOO(X11 - X10 2) = (1- X10) +Bo+~
Correctness of statement of a problem on equality ofconditions of methods comparison at a specified form of amodel consists in identity of initial conditions for all selected
methods and optimality of parameters of each method from aviewpoint of a specified characteristic speed of operation,
number of quality function samples before reaching of a specified zone of extrernum.
All selected methods have been preliminary optimized forparameters. Start points for all tests were a single value
Xo = {XiJ

i = 1,2,...... 11

Studies were carried out in simulation of optimization
process at computer. Results were averaged from ten"ascensions" for the determinate method (simplex) and fromfifty "ascensions" for varieties of a random search.

where
Kj is the number of samples at j-th step;o~ = t.~/Qj-1 is relative change of quality

factor;error probability. It deter!Ilines probabil~ty of an erroneous
operating step P = P [Q(XJ + t.XJ) < Q(XJ)}
inaccuracy. Characteristic of method inaccuracy is integral
one. It determines discrepancy E of the obtained and unknown quality E(E) = E(X" - xext),
where X* is solution, obtained as result of method operation. xext is solution, corresponding to extrernum ofquality function.
number of samples of quality function for reaching of a
specified level. This characteristic depends on initial conditions of X;
reliability. Reliability p(E) of method is probability ofreaching the specified x-vicinity of extremurn for a specified
number of samples of the quality function.
Realiability is numerically estimated in the following
way:P(e) = 1 - Px =fa p(ei)dei

where e.i = !xj-xext I is discrepancy at j-th step, distributedwith density p(E), Px = fxp(ei)dei is probability of unachieved
required accuracy of solution.
p(e)-noise immunity. One of the most important criteriaof the search methods application for solution of the task ofaccelerator optimization is ability to orient oneself with respect
to situation of noise.
Changing level of noise at the accelerator lays down arequirement of stable convergence of the search procedure insome range of noise. Therefore, it is important to study
dependence of methods rate on a value of noise and to estimate
an upper boundary of a noise level, at which correct orientationis still possible. For collection of noise immunity statistics anoise level is changed from 0 up to 25%, and for each concretelevel an average number of steps was determined, necessary forcorning to a zone, limited by the surface,(X: l(X)J = C C = 0, 95 Imax
Main conclusions:at the initial stage of search a random search with self-learning is characterized by the smaller losses. At all the following stages the simplex method is characterized by minimum
losses. A random search with gradient estimation is similar
to it.

S16MS04552

Modelling and Simulation552

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

ICALEPCS1991, Tsukuba, Japan- simplex method has the smallest probablity of errors;- simplex method has demonstrated a higher accuracy ofsearch for extremum in comparison with methods of arandom search, has turned out to be the best one in criteriaof speed of responce, noise immunity and has demonstrated
reliability criterium results, almost identical with therandom search method.

III.

STUDY OF EFFICIENCY AT AN OBJECT

The studies were carried out for criteria of speed of responce, search variance and reliability. Speed of responce wasestimated according to the number of steps, which are to be
performed since start till completion of search.

Intensity

p

nom

I
p

1-st relax.

02-nd relax.

72

14.6

220

Steps'The extremum search mode of the system

Ip

Inten~;;i ty

1

0

75

Fig. 2

150

225

nom
p

Steps:The extremum follow mode of the system.

S16MS04
Modelling and Simulation

553
553

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

I

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS04

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 Publishing

Search variance is meant as growth in the output parameter
instability because of the search steps. Procedure of extremum
search is considered to be reliable, if manual tuning after eachseries of ascensiens is not effective enough.
Estimation of methods efficiency was carried out in thefollowing conditions:- detuning in all controlled variables at initial level of intensity of 20 ····• 40% from maximum one;- detuning of accelerator in two controls (two-dimensional
backbone was reproduced artificially);- nominal conditions of accelerator operation in the presenceof the optimal state drift.
All methods turned out to be serviceable ones. However,efficiency of their use turned out to be not identical. In starts
from peripheral points the best results were demonstrated bysimplex method. An appreciable growth in intensity in theuse of this method ends after 60 ····· 80 steps. However,search variance turned out to be high enough. The best average
result among methods of random search is 100 ..... 150 steps
to an object.

A main result of the carried out studies was proof of applicability of extremal control methods for control of accelerator,and efficiency of them has been demonstrated in practice. This
became apparent, first of all, in decrease in time of reaching of
the operating conditions of the accelerator (this time was 8 .....
20 minutes) and in the improvement of the accelerator operation quality. The latter is characterized by process variance, reduced almost by a factor of two, in comparison with manual
tuning, and by intensity level, increased by 5 ..... 10%. Fig.
1 and Fig. 2 demonstrate the search and follow modes of system.

doi:10.18429/JACoW-ICALEPCS1991-S16MS04

IV.

CONCLUSION

Though the obtained results are of particular character, they
may be used for control of objects of the same class. As forstudy methodology, it may be assumed as a basis of theapproach and organization of solution of the extremal control
problems by other types of electrophysical installations.

S16MS04554

Modelling and Simulation554

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

take into account radial
tegralguration in the space of coordinates andspeeds at the end of structure;-to calculate feasible structure parameters
to satisfy for:nulated conditions.
Main assumptions area) the particle interaction isn't taken into
consideration;b) electromagnetic field amplitudes are piece-wise constant.
Under this hypothesis equations of beam's dynamics allow the analytical solution everywhere exept accelerating gaps. The aim is toplace particles into domain, bounded by curve on nhase plane. Let vector Y is ( W.~) or(1, r') or (x,:::c') or ( ~,H') and S(Y) =C isequation for boundary. Let the function F(Y)is defined by formulas
F (Y) o ~if
S ( Y) < C

dynamics we add in-L

I 2 =) Hci2+cxce2JcH~d~l\ d~s dce 5 dy

(6)o M5,o1,uto functional (4).
This approach gives us opportunity tosolve more complicated problems. For example,
we can optimize the lattices with beam's
space charge taking into account, Let us consider one of such problems. Suppose that particles beam has circle cross-section and almost homogeneous charge density distribution
Then the fo1•ce acting on the particle may be
defined by formula

(7)

Fi
R

oI

=

else

where
is an effective radius of beam crosssection. 'rhen the beam's dynamics can be obtained by adrling the function Frz. to rir:ht hnnd
side of second equation system (5).
Thr~ choice of the functional(2) a.l lows
to define the prelimenary structure of an accelerator and to optimize it to obtain pnrameters needed.
In monographs [1,2] there is a vast survey of methods oI' solving different beam's
optimal problems, The technique, proposed forthese problems, allow to constructdirected methods of choosing optimal parnmeters, The analitical fonnulas for the gradient of control parameters are pr·onosed inthese books. In pa:rticulary formulas f'or gradients

]d'

or.u

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS05

01' ~) l= 1,2,. .. , N

0 v-l
i.
vj11,
for above mentioned examples are developed,
We produced codes for IBM PC compatible
computers for solving these problems. One ofthese codes provides optimal parameters f'or
solenoids, quadrupols and gaps with drift tubes. Authors wanted to make the program allowing in interactive reeime-to simulate charge particles beam's dynamics;-to formulate conditions for the bt"arn confi-

F(Y)=- ($(Y)-C)~

Let the minimizating functional is the integral of function F(Y) by the particle set. \~eshall minimize it by varying elements lengths
and values of electric and magnetic fields
amplitudes. 'rhe functional' s gradient can beobtained with the help of conjugate systemthat is solved analitically. ~he restrictions
on control arc considered during optimization'rhe phase variables ( t, :C ~ ~)"i!)values at the end of every structure element
are computed and saved, These data is used
for construction of beam's dynamics vizualization that is made with the help of graphics
and tables. The user can enter the acceleraand focusing structure, particle's typeand initial beam phase configuration.The program made it possible to watch the 2D & 6D
beam dynamics and to optimize the structure's
parameters. If the user want to optimize thestructure he should set the beam phase configuration at the end of the structure and put
restrictions of the control, User can control
the process of optimizatj.on, The codes can beinstalled on IBM PC/AT 286,
The initial and optimized beams crosssection are depictured on figures 1,2,3,4.
The beam's projections on the plane(W,~)
at the end of initial and optimized structures are depictured on fig,1 & 2, The ellipse
bounds the set desired.

±) 9,

S16MS05556

Modelling and Simulation

556

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S16MS05

cir/dzi,..
j

7 .50E-0002 :~ ............................................... i:.............................................. .
.............................................

.
.
:

·!

I

.!20 • 00 r........................................... :···... ····...............................
.
..
-7.SOE-0002 : ......... .............................
·
1.................................................. .
..................................................
..
..
',,:')7'"

'

MM j

...

'

~

.,

~

'
'

Fip.-. 1

Fi.~.

3-7.50E-0002......................................... ! ...................................... "" : ......... ""' ................................

~

··:

..

·~

:~

·~

4
2

l

projections on the nlane (~,7)
at the end of initial and ontirrized structures ·arectured on fig.) & 4 corresponThe beam'~infly.

The~llinsebounds the set desired ..

References
1, Ovs;yannikov D.A. Mathematical methods ofbeams control. L. : Leningrad University,
1980 (in Russian).
2. Ovsyannikov D.A. Simulation and optimization ofparticle beam dynamics.L.:
Leningrad1990 (in Russian).

S16MS05
Modelling and Simulation

557

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-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 Applications558

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

AC VOLTAGE (nns)

IL CONSTRUCTION
A. Klystron modulator
AC CURRENT (rms)Fig.1 shows the main circuit in a klystron modulator. A
pulsed high voltage and a large current are generated bycomposing of a pulse-fanning network (PFN) and a thyratron,
stepped up by a pulse transformer and supplied to a klystron.
These signals, which are used for diagnosis of the modulator,
are measured at four positions, which are shown arrow mark(fig.1); these are the AC voltage and its current, as well as DC
voltage and its current. Fig.2 shows a typical pattern observed
just before shutdown; this pattern shows the situation of an overcurrent caused by a continuous conductive state in thethyratron. These signals are continuously measured by a datataking equipment, as shown in fig.3. The data-taking equipment
comprise isolation amplifiers, special elements to convert AC
rms to DC (rms/DC), a multiplexer (MPX), a sample and hold(S/H), an 8-bit analog to digital converter (ADC), a memory tostore the measured pattern data, an asynchronous serial
communication interface adapter (ACIA) and a microprocessor(Intel 8085) used to control all of this equipment. These signals
are sampled regularly at intervals of 1 msec and the data of 100
samples are stored in memory. When this equipment receives a
shutdown signal from the klystron modulator, it immediately
stops sampling these signals and sends the pattern data (4positions x 100 samples) to a personal computer installed in thecontrol room with ACIA (9.6 kbit/s) through an optical fiber
cable.

DC VOLTAGE

00

20

40

60

80

100

255.-~~~~~~~~~~~---,DC CURRENT

B. Neural network

80

100

MEASUREMENT TIME (msec)
Fig.2. The typical pattern observed just before shutdown. Largecurrent was flowed by a continuous conductive state in thethyratron and large voltage drop was simultaneously caused. Yaxis is an output value of ADC. Each curve is constructed by
100 sampling data.

The personal computer FMR-70HX3 (Intel 80386, 25MHz,
MS-DOS or OS/2) manufactured by Fujitsu is used. It has thefunction of a neural network simulator. This simulator works bycombining simulation software (NEUROSIM/L) and an
exclusive board (neuro-board) with a digital signal processor(MB86332) for high speed floating-point operations and 4 M
bytes of memory for interconnections between neurons. The
simulator is capable of making up to 1000 neurons at most. andthe process speed is 4 M connections/s at most. The
NEUROSI~ functions as a simulator that can be accessed byuser's programs with C language, and a tool for both learningand recognizing through MS-WINDOWS. The neural networkin this system has a 3-layered structure; the number of theneurons in each layer is 60 in an input-layer, 10 in a midle-layer

S17AIA01
Al Applications

559

559

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

have been collected. This system has been constructed andoperated so as to collect new trouble patterns and the system
diagnoses two klystron modulators for practical use.
This system comprises data-taking equipment built into each
klystron modulator, as well as a personal computer with asimulation function of the neural network. The personal
computer is also associated with the linac control system. Any
diagnostic result is communicated to a linac control computer,and is shown on a display of the operater's console in the control
room.

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

DATA-TAKING EQUIPlvIBNTPERSONAL COMPU1ER

FMR-70HX3VOLTAGE,CURRENTAC

rms/DC

MPX,

S/H
and

ADC

DC
ISOLATIONAMPLIFIER
SHUTDOWN
SIGNAL
i8085

Fig.3. Block diagram of the data-taking equipment.

PATTERNDATA~~11=-111111=-

DIAGNOSISRESULTCOMMUNICATIONCONTROLDIAGNOSISCONTROLUNLEARNEDPATIERNDATANEURAL NE1WORKSIMULATORINIERCONNECTIONDATA
OF NEURAL NE1WORKFig.4. Software architecture in the personal computer.
and 5 in an output-layer, respectively. The abnormal part of thepattern accepted from the data-taking equipment is added to the
input-layer. Each output in the neural network simply
corresponds to each cause of trouble. A back propagation
method was used for learning. The learning time depends on thelearning parameters; the optimum value of the parameters are
obtained by repeating the learning process trials. It then takes a
few hours for this process. Afterwards, the constructed neuralnetwork is stored in the disk of the personal computer and isthen loaded into the memory in the neuro-board when thissystem starts. Although the learning process has been used as
only an exclusive tool, the new version of NEUROSTh1/L has
been so improved as to be able to set various learningparameters and to be operated the learning by the user program
without any manual operation. The system is therefor able toprovide an automatic learning function.
The program used for diagnosis in the personal computer
comprises a simulation unit of the neural network, a diagnosis
control unit and a communication control unit (fig.4). Before

the diagnosis, the interconnection data of the neural network
which has already been learned are loaded from the disk into thememory of the neuro-board. The pattern data for the diagnosis
sent from the data-taking equipment is processed so as to supply
the input-layer in the neural network at the diagnosis control
unit; it is then sent to the simulation unit. The diagnostic results
obtained at the simulation unit are returned to the diagnosis
control unit. If the diagnosed pattern is applicable to the patternalready learned, the diagnostic results are sent to linac control
computer so as to inform the linac operator; if not, the patterndata from the data-taking equipment are stored in the disk forthe next learning process.

C. Diagnostic system in the linac control
Fig.5 shows the diagnostic system in the linac control
system. In the linac control system [3], an original control loopof a Micro VAX-II is connected with magnet power supples,
the klystron modulators and graphic displays on the console

S17AIA01560

Al Applications560

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Micro VAX-II

CON1ROL LOOP (64 kbit/s, HDLC)STEERING
COIL

KLYS1RON
MODULATOQMAGNETCONSOLEDISPLAY

Fig.5. Block diagram of the linac control system, including the diagnostic system for the klystron modulator.

desk. The control loop is a 64 kbit/s synchronous transmission
mode based on the High-level Data Link Control procedure(HDLC). Intelligent controllers based on a VME bus, which
control the devices comprising the linac, are connected to eachnode of the control loop. The diagnostic results from thepersonal computer are sent to the Micro VAX-II through thecontrol loop; they are also informed to the linac operator bygraphic display and recorded on the linac operation log,
together with other useful information from the linac.

III. CONCLUSION
As of now, various tests have been conducted. In the future,
increasing the amount of pattern data will become a serious
problem, such as increasing the learning time and establishing
how to learn efficiently. In order to increase the learning time,the extraction of special features from a pattern and reducing
the total number of neurons in the neural network must be
improved. As for the learning method, this system should
provide an automatic learning function, so that it can workwhen it obtains a new pattern, relearns without any manual

operation and changes an old neural network to a new one. The
addition of an automatic relearning function to this system is inprogress.
As our next step, this diagnostic system will be associatedwith an expert system for the diagnosis of a klystron modulator[4] in order to realize higher accuracy.

IV. REFERENCES[I] Y.Shibasaki, M.Mutoh and I.Abe, "Expert system for !hediagnosis of beam operation trouble," Proceedings of the 16th
Linear Acceleratm:- Meeting in Japan, Tokyo, September
1991,pp.333-335.
[2] M.Mutoh et al., "The diagnostic system of ldystom modulator
using neural network," Proceedings of the 15th Linear
Accelerator Meeting in Japan, Sapporo, September 1990, pp.251253.
[3] M.Mutoh et al., "Improvement of the control system for linac
and pulse beam stretcher at Tohoku university," Proceedings of!:he 7th Symposium on Accelerator Science and Technology,
Osaka. December 1989, pp.240-242.
(4] I.Abe et al., "Expert system for diagnosis of klystron modulator,"
LINAC conference 1990 in Los A1mios USA, September 1990.

S17AIA01
Al Applications

561

561

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-S17AIA01

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 Applications562

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

ICALEPCS1991, Tsukuba, Japangenerationsf6l, from the viewpoint of an ES tool, we candefine three generations as follows:
In the 1st generation, until 1980, simple tools andlanguages were utilized;
In the 2nd generation, 1980 to 1985, hybrid tools werecommonly used.
We are now in the 3rd generation, which is characterizedby easy-to--use tools and task oriented; domain-specified tools
are available now. We have established commercial systems,
specialized languages, and tools for developing such systems.
Today, the development of the so-called knowledge based
systems has started moving out of the research laboratories ofpure informatics into other disciplines of science.

interlocks and analog data displaying at the local pulser panel.
Of course, ES requires more information for a complete
diagnosis. Most of the same data which is available to checks
locally is transfered to the main computer and as well as to theES. The ES would be triggered to start diagnosis uponreceiving a fault message through the network.
The ES has the following configuration: HP9000/370(development station), 375 (LINAC operator's console), HPUX, C, NEXPERT-OBJECT (hybrid-tool), Data-View(graphic tool), equipped with a 16MB RAM:, 300MB(600MB)
hard disk, and 3.5" floppy disks. There is a pre-process
station (FMR-50 personal computer) which has a 600MB
magnetic optical compact disk (CD), and is connected to the
DSLink. There are about 30 personal computers (PC) under
the DSLink network, and each PC has its own purposes orfunctions such as gateway, server, accelerator operator's
console, monitors, development, expert system, and OS/2
stations.
The DSLink operator's console network of the LIN AC isconnected to the conventional LINAC networks through thegateway (FMR- 70 HX3).
In addition to rule-like knowledge, waveform informationis also highly important in carrying out diagnostic tasks.
Pattern recognitiona neural network: is thought to be
helpful in this contex . J A neural network is well suitedfor pattern-recognition problems, but has a disadvantage thatthe learned knowledge is hidden in the weights of the
network's connections. We have thus developed what is calleda hybrid ES by combining a neural network.
The injector ES has a debugging mode for diagnosis
which makes it easy for users to carry out simulation at any
time.
The ES can operate in two modes (AUTO or
1nru'!tJru~• at the operator's discretion. In the AUTO mode,
when thereceives serial shutdown data from a pre/postprocess station through the network, it automatically andperiodically starts the diagnosis procedure. During a periodic
analysis, ES starts a monitor programme to collect raw data
for the error diagnosis process during the data-taking phase.
The interactive debug mode can be invoked if an error in therun or one of the test modes occurs. Symptoms will bederived and possible repair actions will be proposed. In the
debugging mode, the inference action is initiated, or fired,manually by the knowledge engineer or user. Each rule mustbe simulated step by step in this MANUAL mode both before
and after running using empirical knowledge.

GURU

1980

1985

1990

of Tool

V. Software tools
For the most part, the ES tool comprise an inferenceengine, knowledge-aquisition, a knowledge-base, a explanation
syslem and a user interface.
An ES tool should provide at least the following features:• transparency and portability of the knowledge base,- expert-like diagnosis (less questions, learning,)- a graphical user interface for representation and afunction of explanation
are very important in knowledge handling. Several operation
modes are also necessary, such as a Run mode, Test modes
and interactive debug modes.
Some useful knowledge-aquisition tools are available on themarket which are helpful for simple surface knowledge.

VI. Hardware/software configuration
The LINAC injector control system has several
microprocessor units (M"PUs) which are connected to a local
network (LOOP-2).
When a fault occurs in the injector part, the :MPU picks up
the first reason for the trip down and sends a message to aminicomputer, MELCOM 70, in the subcontrol room
through LOOP-3, LOOP-2, and CAMAC. There are 50

VII. Defining the task and application domain
In the accelerator domain, ES would be useful for
operation support. fault diagnosis, and design work:. We haveinvestigated the task of diagnostic ES for the injector of the
LINAC. The following tasks were important for ES:l) On-line data processing.
2) Finding heuristic methods of diagnosis from humanexpert (surface knowledge).
3) Local checks using oscilloscopes, measurement tools,
and visual checks.
4) Logbook, chart, and drawing checks.
5) Modeling, and calculations (deep knowledge).
These are the fields that an expert carries out during diagnosis;
an expert system should thus duplicate them.

S17AIA02
Al Applications

563

563

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

Easy-to-use Tool
Nexpert Object
Expert Ease

1975

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA02

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----......i

MINICOMPlITER

MEL.COM 70{30

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA02

io-------ot#S

MINICOMPlITER

MEL.COM 70{301o--------------LOOP-1

#l

CAMAC

Operator's console

Development

FMR70

IQ]

stations
FMR50 x 4

FMRc::::i
Gateway

Network for operator's console
DSLINK

IQ]
c::::iAUI
HP-UX HP9000{370

FMR70

[QI

FMR70

IQ]
c::::iWorkstation1--·

pre/post

Station

FMR50

FMR50

[g]

[QJ

r:::::3

c::::i

NeuralExpert System

Inf. Shell

ServerOS/2 Station

Expert System
Fig. 2ServerHard Disk

Printer

Expert Systemand the PF Linac Control console network

VIII. Diagnostic ES and the Problems

inductive.
6) The handling of uncertainty in knowledge as well as in

The most difficult problems to be resolved have been theacquisition and representation of knowledge, as well as theselection of an inference strategy. When we develop an AI
system, we must be clear about the following items regarding
the planned applications:1) The diagnostic resolution must be detennined.
2) Necessary information must be available on-line;
otherwise,the operator must supply a large amount ofdata to the expert system, which is quite unrealistic inpractical situations.
3) The introduction of deep knowledge, such as model
based diagnosis, is desirable.
Without deep knowledge, the number of required rules
can be quite large.
Domain-specific knowledge can be represented in a
logical programing system, in a frame-based system,in rule-based systems, or in hybrid systems.
4) The strategy for controlling the inference procedure is
critically irnportanL
This strategy should be made consistent with thecontent of rules in the knowledge base5) Inference mechanisms: We must determine which
direction of reasoning is appropriate, a forward-directedstrategy from an initial to a goal state, or a backward.
Inference method may be deductive,abductive, or

the observed data is also necessary.
7) Appropriate actions should be implemented.
If a new unknown problem occurs, the system should

propose to contact a field experL
The system must assist the expert in updating therelated part of a knowledge.
8) Is a learning system or Case-Based Reasoning (CBR)
important ?

IX. Knowledge Acquisition
Generally, knowledge acquisition can not be based onany model in this kind of diagnosis. Knowledge engineers orexperts must build knowledge-base extracting rules andprocedures using an empirical approach through interviewing
experienced field experts regarding both operation andrepairing.
Here, we have a bottleneck concerning knowledge taking.
For making the LINAC injector diagnostic knowledgebase, about one month during the first stage has been spent ininterviewing and knowledge engineering for a shallow target.
As the second stage, we are refining the knowledge base inorder to obtain more knowledge. One hundred expressions
concerning production rules, some frames, and object are
being handled in the ES.

S17AIA02
564

Al Applications564

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

X. Conclusions

References

The diagnostic capability is still limited; moreover, wehave started with a shallow target. It was sufficiently fasterthan human (operators) diagnosis regarding execution.
A new K/B(Knowledge Base) is now being added and tested for
expected phenomena in order to obtain more reliability.
It has become feasible now in the Accelerators field. We
are sure that expert system technology will provide new
possibilities for software systems, especially in futureaccelerators. Expert systems should be used more in ourfield, as in others.
As a final statement, the following will be the areas inwhich we must carry out research:
How to deal with a large domain,(many tasks).
How to model applications, such as task anddomain analysis.
We need portability ofK/B.
Leaming systems and Case Based Reasoning.

Acknowledge,ments
The author would like to thank Dr.S.Ohsawa, M.Yokota
and A.Shirakawa for their help in the present phase ofknowledge acquisition, as well as Professor A.Asami, Directorof the Injector-LINAC division in KEK, and Prof.
K.Sugiyama of Tohoku University for their support to this[l] I.Abe, H.Hanaki, S.Anami and K.Nakahara"Klystron Modulator Trouble Shooting"
LINAC conference (1989)[2] A.Shirakawa, I.Abe, and K.Nakahara"OS!l AND DSLink FOR THE PF LINAC CONTROL"
16th LINAC conference (1991)[3] I.Abe, M.Fujieda, "DISPLAY SYSTEM FORCONTROL CONSOLE OF KEK
Proceeding of the 6th symposium on Accelerator Scienceand Technology (1987)[4] K. Nakahara, I. Abe, R.P. Bissonnette, et,al
Nucl. Instr. and Meth.A251(1986) 327-336[5] K.Nakahara, I. Abe, A.Enomoto, Y.Otake, and T.Urano
Nucl. Instr. and Meth.A247(1986) 153-158[6) AI H.akusho
ICOT-JIPDEC AI center[7] Isamu ABE, Masashi Fujieda
Proceeding of the 6th symposium on Accelerator Scienceand Technology(1987)[8] M.Mutoh, T.Oonuma, Y.Shibasak:i, Isamu ABE andK.Nakahara"Development of a Diagnostic system for Klystron
Modulators using a Neural Network", This conference

project

S17AIA02
Al Applications

565
565

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-S17AIA02

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 Applications566

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

The first step uses low-level real-time software and the second step uses high-level play-back software. The databaseof the control system provides an interface between highand low-level software.

input and output data using X-Windows. To link a newmodule in the GLAD system to a given database requires
two adaptor codes: DB-Get and DB-Put. The DB-Get
adaptor code is used to translate files from the databaseformat to the input format of the modeling code. The
DB-Put adaptor is used to "download" the results into the
database of the control system. In this way, the GLAD
system can link up with any existing control system. In
addition, GLAD can also be used for developing rules andprocedures to find errors automatically, and to provide anaccelerator system emulator for operator training.

A GENERIC LATTICE DEBUGGER (GLAD)

Today, numerous accelerator simulation and analysis codes exist that can be used to find the as-built
model of a given beam line. To name a few, there is
COMFORT, [2], DI.MAD [3], MAD [4], PETROS [5], RESOLVE (6], TRACY (7] and TRANSPORT (8]. In general,
the GLAD process will find the as-built model using thefollowing procedure:
L Measure orbits, tunes, profiles, etc.
2. Save the measurements in the database.
3. Translate data files to the input format of a particularcode,
4. Analyze the measured data to find errors in the beamline or in the model.
5. Validate errors with beam tests.
6. Update the model.
In addition, if errors exist in the quadrupole strengths,
the beam line can be "tuned" using the as-built model.
The tuning process typically involves:
L A calculation of the "lattice function" errors (such as
mis-match in the beta-functions, eta-functions, etc.),
and2. An adjustment of the lattice functions to remove theerror.
If quadrupole magnets are misaligned, they can becorrected using orbit correctors near the misaligned elements. This correction process typically involves the following steps:
L Measure the orbit.
2. Identify and correct BPM offset errors.
3. Calculate the strength of the correctors using an orbit
simulation code such as RESOLVE.
The GLAD process will be either an "off-line" process
or an "on -line" process. When file translation (step 3 of
the GLAD process described above) are done manually,
it is considered an off-line process. When they are done
automatically, it is considered an on-line process. The advantage of an on-line process is to reduce the tum-aroundtime so that experimental validation can follow error prediction as quickly as possible.
The GLAD system can be used either manually now
or automatically in the future. For manual applicationsof the GLAD system, the graphic interface allows a user
to implement these procedures interactively. With "adaptor" codes to link the user interface to the database of thecontrol system, the Model-Based commissioning and operation procedures can be implemented on-line directly. An
example of manual application is to use RESOLVE to validate the model and COMFORT to tune the lattice. In
the future, rule-based expert systems can be added to the
GLAD system to perform these tasks automatically.
A Generic Interface [9] (GENI-X) is being developed
to run modeling or simulation codes and to display the

Modeling and Inverse Modeling
There are two ways to use GLAD in the commissioning and operation of a beam line: Modeling and Inverse
Modeling. In Modeling, GLAD computes the effect of thevalue of beam line parameters on the beam. In Inverse.Modeling, GLAD does exactly the opposite; it solves forthe value of the beam line element parameters to best
match the measured data. For example, during commissioning, Inverse Modeling is used to find the as-built modelfrom the measured beam orbits (BPM data) and it is used
to correct errors in the beam orbits during operation. Inverse modeling is also useful to restore beam parameters
after a shut-down, hardware failure, or it is used to control the beam parameters in the presence of slow hardware
drifts.
Analysis and Interpretation
For each data analysis application, the high-level software can be used to analyze beam data and to display the
result graphically. Based on interpretation of the result,
low-level software is used to implement the predicted adjustments. To validate the result, the beam parameters
are remeasured. By comparing the measured data withthe predicted result, the user decides what to do next. If
the measured result does not match the prediction, theGLAD process (interactive look-analyze-interpret-adjust)continues until the as-built model is found and verified.
Manual and Automatic
Today a user must decide which beam parameter tomeasure, what procedure to use in the analysis, how tointerpret the results, what to adjust, and when and whereto iterate the GLAD process. In the future, AI methods
can be used to perform these steps automatically to savevaluable beam time. For example, automated error finding and beam control procedures can reduce the time ittakes to recover the beam after a shut down or a hardware
failure.
I am proposing the development of an AI tool
kit called ASAP (Automatic System Analysis Program).
Some of the AI tools to be included are Fuzzy Logic, Expert Systems, Neural Nets, and Genetic Algorithms. After the GLAD system is fully implemented, the user cancommission or operate the accelerator system manually or
automatically with the AI tools.

S17AIA03
Al Applications

567
567

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-S17AIA03

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 Publishing

CURRENT GLAD APPLICATIONS
One typical demonstration of the GLAD process has
been to find quadrupole magnet misalignment and BPM
offset errors in the SLC damping rings and in SPEAR byanalyzing orbit data with RESOLVE. For t"hese cases, RESOLVE was linked to the SLC and the SPEAR control
systems with adaptor codes. In this section, the use of RESOLVE to find magnet alignment and BPM offset errors
in the SLC electron damping ring (NDR) is described. In
particular, procedures and rules developed to analyze thebeam orbits and to verify the predicted results are presented in this section.

4. Once step 3 is true, adjust the first corrector to steer
the beam orbit back onto the axis up to the second
misaligned quadrupole. Look to see that the beam isdeflected off-axis at the second misaligned quadrupole.
5. Once step 4 is true, adjust the second corrector to steer
the beam orbit back onto the axis up to the third misaligned quadrupole. Look to see that the beam is deflected off-axis at the third misaligned quadrupole.
6. Once step 5 is true, adjust the third corrector to steer
the beam back onto the axis. Look to see that the orbit
in the second turn matches the orbit in the first turn.
7. Once step 6 is true, store beam and measure the closed
orbit.

doi:10.18429/JACoW-ICALEPCS1991-S17AIA03

Trial-and-Error and Rule-Based ProceduresOver the past fifteen years, special modeling and sim- Prediction and Validation
ulation codes have been developed at SLAC to make orbit
The above procedure was given to the operators withcorrections. All of these procedures work well. In particu- a list of the three misaligned quadrupoles, the three chosenlar, it is possible to use on-line Model-Based orbit correc- correctors, and the BPM offset errors. Following this protion procedures to reduce the residual closed orbit error in cedure the operators were able to inject the beam on axis
the NDR to less than a millimeter.
by obtaining the second turn orbit approximately equal to
Unlike the orbit correction procedure, the beam injec- the first turn orbit within a few minutes. All of the steps
tion procedure in the NDR is not model-based. An oper- went almost exactly as predicted. The operators thought
ator typically follows a trial-and-error procedure:
our test was a success since it would take much more time
1. Kick the beam onto the axis of the ring by pulsing a and effort and many more correctors to accomplish the
kicker magnet,
same result by trial-and-error.
2. Steer the beam manually along the ring axis using orbit
Personal and Artificial Intelligencecorrectors in the ring to establish a good first turn orbit,
The success of this experiment not only validated our
3. Adjust correctors upstream of the kicker magnet tomatch the second turn orbit to the first turn orbit to predictions, it also confirmed the rules we developed forfinding and verifying quadrupole alignment and BPM offobtain orbit closure.
seterrors. As a result of our findings, two rules which will
In practice, both the closed orbit correction and beam
beused
to automate the GLAD process are as follows:
injection procedures work. But there are two problems:
1. A BPM is good if the predicted beam orbit agrees with
first, the closed orbit resulting from optimizing the injecthe measured value for all tracks. A BPM is bad iftion process is not the same as the closed orbit obtained
the predicted beam orbit disagrees with the measured
from minimizing the RMS orbit error, and second, it isvalue for all tracks and the BPMs on both sides are
not possible to inject the beam onto the corrected beam
good. If the difference between the measured value andorbit without beam loss. In either case, more than a dozen
the predicted value is the same for all tracks, then thecorrectors are needed to steer the beam to the "good" indifference is the BPM offset error.
jection orbit or to the "good" closed orbit (the NDR cir2. If the beam is on axis (readings at the good BPMs are
cumference is 35m).
zero), the measured values at the bad BPMs are theTo systematically investigate the beam injection/storoffset errors.
age problem, a colleague (Jeff Corbett) and I measured
several sets of first turn orbits with all of the horizontal corIn the case of the NDR, we found that the predicted
rectors off. The orbit files were translated into RESOLVE offset errors at the bad BPMs agreed with the measured
format using adaptor codes. Using "Multi-Track" Anal- values. From this result, it is now possible to understandysis procedures (6], we soon found five BP Ms with large what the operators had to do without the knowledge ofoffset errors and three misaligned quadrupole magnets in these offset errors. Since the operators normally used at
the NDR. In addition, we also identified three correctors least one corrector to steer the beam through the center
that could be used to minimize the orbit errors caused by of each bad BPM, at least five correctors had previously
the misaligned magnets. Based on these model predictions, been used (incorrectly) to steer the beam. In addition, thethe following procedure was established to inject onto the ·.operators used at least three correctors to compensate thehorizontal machine axis:
three misaligned quadrupoles and two more to close the
1. Turn all horizontal correctors in the ring off.
orbit. The total number of correctors therefore would add
2. Ignore the BPM readings with predicted offset errors.
up to at least ten. With the knowledge of the alignment
3. Adjust the beam orbit and beam energy at the end of errors, the operator will be able to inject beam on axis by
the transfer line to steer the beam onto the axis of the using only three correctors.
NDR, i.e. zero rms readings on the BPMs up to the
In addition, we noticed during the Model-Based beam
first misaligned magnet. Look to see that the beam is injection/storage test that beam loss occurred at each turndeflected off-axis at the first misaligned quadrupole.
in the extraction septum region. Since a localized loss

S17AIA03
568

Al Applications568

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

ICALEPCS1991, Tsukuba, Japancauses a beam centroid shift, it can be modelled as anabrupt "jump" in the beam orbit. Thus, in the presenceof beam loss, the orbit of the injected beam can never be
exactly equal to the closed orbit of a stored beam. These
results suggest the following two "rule(s) of thumb" forinjection/storage beam into a storage ring:

REFERENCES

JACoW Publishing

1. When the number of correctors are large, look for bad
BP Ms.
2. When the closed orbit can not be made equal to theinjected orbit, look for beam loss during injection.

PRESENT AND FUTURE
Over the past few years, RESOLVE has been used toanalyze beam trajectory data to find various types of errors
in beam line elements and beam monitors at PEP, SLC,
and SPEAR. In particular, procedures have been developed and tested to find dipole, quadrupole, sextupole, andrf cavity field strength errors, as well as displacement androtational errors. Similarly, procedures have been developed to find BPM sensitivity and offset errors, andcal aperture restrictions. The development of these procedures is based on the knowledge of accelerator physics andability to translate them into "if A then B" rules for data
analysis.
Today, it is possible to compile these rules into an expert system to automate data analysis. [10] It is also possible to automate any rule-based procedure (such as theinjection procedure described in the previous section) using an expert system.
In the future, other AI tools such as Fuzzy
Neuand Genetic Algorithms can also be
for acralcelerator control. For example, Fuzzy Logic can be used
for interpreting the result of the analysis since the rules
may be more qualitative than quantitative (Fuzzy Rules).
Neural Nets can be used to recognize errors or to handle
exceptions. Adaptive feedback/correction systems can be
developed using Neural Net models [11]. Finally, Genetic
Algorithms can be used to train Neural Networks or tosearch for optimal solutions.
The development of GLAD, a Generic Lattice Debugger System, will allow us to analyze beam data with any
modeling or simulation code available. In addition, GLAD
will be the natural step toward developing rules and procedures for accelerator commissioning and operation, toward implementing AI methods, and toward developing
automated rule-based procedures.
In conclusion, experience in accelerator control ha.g
validated a popular saying:[lJ M. Lee, Y. Zambre, W. Corbett, "Accelerator Simulation Using Computers," SLAC-PUB-5701, August 1991.
[2] M.D. Woodley, "Control of Machine Functions orTransport Systems," in IEEE Trans. NS-30:no. 4,
Aug 1983 SLAC-PUB-3086.
[3] R. Servranckx et a.I., "Users Guide to the Program
DIMAD," SLAC-PUB-0285, May 1986.
[4] H. Grote, F. Christoph, "The MAD Program (Methodical Accelerator Design) Version 8.4: User's
Reference Manual," Iselin (CERN), CERN-SL-9013-AP-Rev. 2, Aug 1991, 120 pp. Revised version.
[5] J. Kewisch, K.G. Steffan, "PETROS," DESY PET76-09, DESY /Hamburg, 1976.
[6) Cf. M.J. Lee for information on RESOLVE.
[7} H. Nishimura, "TRACY: A Tool for Accelerator
Design and Analysis," LBL-25236-MO, presented
at European Particle Accelerator Conf., Rome,
Italy, June 7-11, 1988.
[8] David C. Carey and Karl L. Brown, "New Featuresin Transport," SLAC-PUB-0091-Add., February
1983.
S. Kleban, M.J. Lee and Y.B. Zambre, "GENI: A
Graphical Environment for Model Based Control,"
SLAC-PUB-5126, Oct 1989. Presented at Accelerator Control: Int. Conf. on Accelerator andExperimental Physics Control Systems, Vancouver, Canada, Oct. 30-Nov. 3, 1989. In Nucl. Instrum. Math. A293:475-479, 1990; also in Vancouver Accel. 1989:475-479 (Journal).
[10] l'vLJ.
S. Kleban, SLAC-PUB-4539, Feb. 1988.
Presented at 1st European Particle Accelerator
Conf., Rome, Italy, June 7-11, 1988.
[11] D. Nguyen et al., "Accelerator and Feedback control
Simulation Using Neural Networks," SLAC-PUB5503, May 1991. Contributed to IEEE Particle
Accelerator conf., San Francisco, CA,
6-9,
1991.

An ounce of (waste) prevention is worth more than apound of {unnecessary) cure,which also tells us that,
An ounce of knowledge of the cause of error is worth
more than a pound of correction on the effect.

S17AIA03
Al Applications

569

569

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-S17AIA03

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

f""

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA04

Plant data

(1) Time when events have occurred(2) Analog trend data of plant dynamics(3) Display information(4) Operator's behavior(5) Verbal protocol(6) Segment of veibal protocol
Analysis results of thinking process(8) Recognition information of plant state(9) Knowledge stored in long-tenn memory(10) Information stored in short-menory!

lCentral control board

/

/

/

,'

,.---~P.11.:""'<:_.·....,·····m
Recor ing oata

l 1n1arvrew,,_ data I r\verbal
dfalogue, ,protocol)'···..,,,:~•,'•,,'",., j Documjnt data l //

"·",
'\

···,,.,,

'\

:

/

//

,i'

'-.-. i /:___ On ·l!ne information flo'·,·.,·,.,,@"",! ,/· ·•·• Off·llna Information flov',.,

Data· .........
base

A.5 Analysis Method of Thinking Process Data/

Operator

thinking model

Figure 1. Experimental arrangement anddata acquisition.
The following data were collected.
1) Record about an oper.:llOr's verbal prorocol and dialogue2) Video camera recordings about an operator's behavior andchange.s in indica!Ors on central control board of simulator
3) Analog trend data of plant dynamics(2) Interview after experiment
Veibal protocol and dialogue data are complemented byinterviewing an operator directly.
(3) Transforming record into document data
Record such as verbal protocol, interview data, etc. istransformed into document data (raw data).
(4) Making analysis data
An operator's thinking process is analyzed on the basisof raw data, and then analysis data were made.
(5) :Making operator thinking model
The model which expresses universally an operator's
thinking process is made by generalizing synthetically theabove analysis data.

A4 Fonnat of Document Data
The following three document sheets are used during thedevelopment of an operator thinking model.
(1) Interview sheet• Time when the object events of interview have occurred• Content of interview(2) Verbal protocol sheet• Time when the object voice has been produced• Content of voice(3) Thinking process analysis sheet
Both raw data which contains the above (1),(2) andanalysis data which is made on the basis of raw data are de·scribed according to the sheet shown in Table 1.

(1) The collected data are transformed into document data andare ai:r.mged according to the format descnbed in Table 1.
(2) The verbal protocol data are decided into segments (theminimum units which have meaning).
(3) The macro-structure of thinking process is identified
through classifying segments into basic thinking elements.
(4) The following knowledge and infonnation used in basic
thinking elements are c.larlfied.
1) Knowledge stored in long·tenn memory
This knowledge is possessed by an operator before simulator
experiment2) Information stored in short-tenn memory
This information is memorized by an operator after the start ofsimulator experiment3) Recognition information of plant
The information flow in operator is shown in Figure 2. ThinkPlant

Central control board

Collectlonlrecognltlonof plant state

Plant operatlon

Recognized lnformatfont<t-_t-s_ho_rt_·ta_rm_rne_m_ory---iof plant state•Hypothesis of present
plant state•History of operator's...-----i acUori

etc.

Thinking process•Deduction•Abduction(hypothesis-bas ad/analogical rsaso-.

nlng) ate.

Long·lann memory•Heuristics of operation•Mental model•Knowledge for deslgn
etc.

Table 1 Format of thinking process analysis sheet
Classifioatlon
Name

Figure 2. Information flow in operator.
(6) (7} (8) (9)S17AIA04
Al Applications

571

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, Japaning and judging by the use of the above knowledge and information, an opera.tor operates his plant and collects plant infor·
mation.
(5) Analysis results of thinking process are arranged according
to the sheet shown in Table 1.

decision making procedure is as follows.
A! first, an opera.tor actively collects and recognizes theplant information. Thereafter, he constructs a hypothesis concerning the current plant state then checks the consistency between the newly identified plant state and the hypothesis. If herecognizes that the consistency is high, he makes more detailed
hypothesis. Otherwise, he makes new hypothesis. In the later
portion of the procedure, he makes decision to lake action depending on degrees of emergency and his confidence concerning the hypothesis. P~ble actions he may take are collectionof additional information, operation to make sure the hypothe·sis, operation based on the hypothesis, emergency operation,and so on.
It is desirable to decide plant operations based on thesuitable hypothesis. But an opera.tor decides emergency opera-

B. Fmdings Obtained by Experiment
The findings were made clear in regard to the operator's
procedures for decision making and action.
(1) When an operator encounters a complicated anomalousstate, he acts based on his knowledge.
(2) An operator diagnoses the current plant conditions andmakes his decision mainly based on hypothesis-based reasoning.
(3) When an operator cannot make suitable hypothesis only
blWld on his shallow knowledge concerning the current plantconditions, he tries to use deep knowledge. The hypothesis iscomposed of the primary cause/degree/propagation of anomaly.
(4) An opera.tor understands the relationship between goals andmeans to attain them in the plant on the basis of the mental
model that is hierarchically composed of the operation goals
and means.
(5) An opera.tor monitors the plant conditions periodically. In
the case when he faced the staleS of emergency, he carries out
operation action against them preferentially.
C. Developed Operator Thinking Model
Based on the above findings, the thinking model wasdeveloped as shown in Figure 3. In the model, thinking andDisturbance-

PLANT

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA04

ldenllflcatlon of anomalous operallon goals
and evaluallon of clegraa of anomaly, Decision of strateoY for eml1fllancy operalion

Decision of anomalous operation
goals to be mitigatedDeolslon of timing

Deolslon of operaflon component

to be us«!

Plant operation

Decislon of opara!lon quanllty
to l:iamaved
Opsratlon tor mltlga!Jng
anomalomi plan! state

Figure 4. Decision model of emergency operation. ,tions acconling to the model shown in Figtife 4 in case the degree of emergency of a plant increases so rapidly that he cannot
construct the suitable hypothesis. The outline of this model is asfollows.
Based on plant display infonnation and the mental
model which is hierarchically composed of operation goals andmeans, an operator identifies anomalous operation goals, thedegree of whose attainment are lower than threshold levels,then evaluates the degree of anomaly. In next, he selects one of
the following operations and decides how to cope with anomaly
newly occurred.
(1) Operation for mitigating anomalous plant state
Based on the above mental model, he decides anomalous operation goals to be mitigated. then he decides operation
components to be used and operation quantity to be moved.
(2) Operation for trip
He decides the timing of trip if needed.

N

Deolslon of
ddltlonal
nformatlon
o be ool!aotad

0110111100 of
operation formaking aurehypotlieala

Deolslon ofoperation
baud onhypotheala

Daolslon or
11merg1moy

operation

ID. EMERGENCY OPERATION SYS1EMBASED ON OPERATOR THINKING MODEL

Figure 3. Develop~d operator thinking model.

S17AIA04
572

Al Applications572

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Kind of nodea. General state evaluation nodeb. Local state evaluation nodec. Mitigatory operation node

Operation
goal level
plant level

Controlsystem level

Ooeratlon ~uipment
Of 1B main di.Imp
heat exchangecComponent
level

Control - - - rod 1·---CJ :nodeControlrod 6:component

Figure 5. Partial example of operation goal network.
At first, the important knowledge base used in the emergency operation system is presented. In next, the functional
constitution of this system is explained. Finally, the outline of
the trial system is desmbcd.
A Operation Goal Network

Operation goal network which corresponds to the mental model described in the preceding chapter is constructedbased on operation manual and the function and structure dataof a plant It has a hierarchical structure, for nodes in upper
levels show more general operation goals, on the other hand,nodes in lower levels show more concrete operation goals ormeans which attain more general goals. A partial example of aoperation goal network whose object plant is "JOYO" andwhose final goal is "reactor power control" is shown in Figure
5. This network. is the important knowledge base of the emergency operation system. According to type ofeach node
has some of the following infonnation necessary to decide
emergency operation.
(1) Information concerning own node, upper and lower adja-

Figure 6. It has a hierarchical structure which are composed of aplant monitoring system at the highest level and other subsystems at lower levels. The outline of the subsystems are as fol-lows.
(1) Plant monitoring system
This system which is periodically activated monitors thestate of a plant and decides whether emergency operations areto be carried out at once.
1) The degree of attainment of general state evaluation ncde iscalculated acoonling to the following steps.
--

cent node(2) Infonnation to evaluate the degree of anomaly and emergency in plant(3) Information to calculate operation quantity(4) Information to discriminate subsystem(5) Information concerning operation component to be used.
B. Functional Constitution of Emergency Operation System
The functional constitution of this system is shown in

Figure 6. Functional constitution of emergency operation system.

S17AIA04
Al Applications

573
573

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-S17AIA04

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, Japana. The plant evaluation index which evaluates the state of anode is calculated.
This index is expressed by a function whose variables
are plant data. For example, the state of node which shows"heat-sink. control" is evaluated by the quantity of heat removal
by a main dwnp heat exchanger. The quantity is calculated bymultiplying a sodium flow rate by the difference between inlet
and outlet enthalpy of a main dump heat exchanger.
b. The relative value x of plant evaluation index is defined asfollows.
(1)
x=(xl-x2)/x2
xl: current value of plant evaluation index
x2: nonnal value of plant evaluation index
c. The function value f(x) is calculated using the state evaluation function shown in Figure 7.

fective operations to mitigate anomalous plant state according
to the following steps. Thereafter, it checks whether candidate
operations satisfy given conditions and decides the operation to

Stale evaluation value f(x)Anomalyro

1 -···································.I

positive direction

1

I·············-·····-··..······-··· -1
AnomaJyw
nogallvo dlreotion

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S17AIA04

X1: Lower limit value of trtp
X2: Lower Umlt value of blind sactor
Xs: Upper Omli value of blind sector
x~ : Upper llmlt value of tr1p

Figure 7. State. evaluation function.
d. The degree of attainment DA iS calcwaied by the following
equation.
(2)
DA= 1.0-jf(x)j2) Only if anomalous nodes are found. the degree of emexgency
is evaluated. otherwise, nothing is carried out until next calculation time.
3) Using rules which express the relationship between the degree of emexgency and its influence factors, such as, the degreeof attainment, its differential value, degree of importance andsensitivity to disturbance, the degree of emergency is estimatedby fuzzy reasoning.
4) Based on evaluation results, it decides whether emergency
operations are to be carried out at once.
(2) Decision system of strategy for emexgency operation
This system decides the subsystem to be activated next
from the following subsystems.
1) Decision system of operation for mitigating anomalous plantstate2) Decision system of operation for trip
Further, it decides how to cope with anomaly newly

occurred.
(3) Decision system of operation for mitigating anomalous
plant state
Based on plant data and operation goal network, thissystem decides operations for mitigating anomalous plant statein order to prevent a trip and maintain the safety of a plant1) Decision of operation component to be used
Using operation goal network, this system searches ef-

be carried out

a It starts searching from general state evaluation nodes indicating anomaly.
b. "AND" connection of operation goal network shows the relationship between an upper node and lower adjacent nodes all ofthat are required to be normal in order to attain the goal of an
upper node. Because normal nodes are not neces.sary to be mitigated, mitigatory operation nodes are exist only under anomalous nodes. Therefore, it evaluates local state evaluation nodes
and identifies anomalous subsystems which belong to thesenodes. Finally, all flags which correspond to anomalous subsystems are changed from "off' to "on".
c. "OR" connection shows the relationship between an upper
node and lower adjacent nodes all of that are alternative means
to have the ability to attain the goal of an upper node. Mitigatory operation nodes are exist under all lower nodes which areavailable. All flags which correspond to available nodes arechanged from "off' to "on". Thereafter, the preferential order of
their nodes is decided using rules which are generated by operation manual and know-how.
cl.Steps b. and c. are carried out for all nodes whose flags are"on", until mitigatory operation nodes are found.
2)Decision of operation quantity to be moved
For the combination of mitigatory operations which are most
preferential, it decides operation quantity which can prevent a
trip and maintain the safety of a plant by mitigating anomalous
plant state. If suitable operation quantity cannot be found, dif.
ferent combination is tried repeatedly.
a. Identification of the combination of mitigatory operations
which are most preferential
b. Decision of operation quantity
In order to mitigate anomalous plant states, the stepwise input
functions Uj(t) of mitigatory operation node j(j=l-j max) must
be decided so as to satisfy the following constraint equations
for i=1-i max.
0;,1t. Utt). s ·,it)~ ximu
J(3)
t:Elapsed time from starting point
i:Number of local state evaluation node which is anomalous
j:Number of mitigatory operation node which is used for mitigating anomalous node
Sj.k(t):Operation influence function to node K by operation ofminigatory operation node j(This function expresses the analog
trend of the change of local state evaluation node K influenced
by a stepwise operation of node j, when the plant is nonnal andin 100% power.)Xi(t):Prediction function of plant variable which corresponds
which anomalous node (This function is obtained by intapolating the past value of Xi and used for prediction of the future
value.)
Ximin:Lower limit value which Xi must not violate in order tomaintain the trip margin or plant safety
Ximax:Upper limit value which Xi must not violate
oi,k:Sign which shows 1 if and only if i equals k, otherwise,shows oc. Decision of detailed operation way
If operation quantity which satisfies Eq. (3) cannot befound,the above calculation is continued for different combination. Otherwise, detailed operation way is decided based on
operation manual, available operatioq components and their.
preferential order, etc..
ximin~ X/.t) +

I

. I .

]"-,nu:I

k-1-imax

S17AIA04
574

Al Applications574

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing3) Coofinnation of results of operation
It confirms whether decided operations are carried out cor-IV. CONCLUSION
The operator thinking model was developed using therectly.

(4)Decision system of operation for trip
Based on plant monitoring data, etc., it decides the timing oftrip in case the degree of emergency of a pl.ant increases so
rapidly that it cannot decide suitable emergency operations.
C.Trial System
The trial system which has the above functions has been constructed The outline of this system is as follows.
(l)Computerl)Types of comput.er:SUN-4 workstation
2)Language:C-l.anguage(2)lmowledge base
The outline of the operation goal network which is the important knowledge base used in this system is as follows.
!)Number of node:25
2)Number of state evaluation function: 103)Number of fuzzy function tc evaluate the degree of emergency:50
4)Nwnber of operation influence function:50(3}Data base!}Number of data composing pl.ant data base:50
2}Numbei of data stored in anomalous data table: IO3)Number of data stored in component data table:50
Based on results of operation of this system, it has been clarified that it can decide emergency operations in real time.

operatOr training simulator, then and the emergency operation

system was constructed ~ on this modeL Based on resultsof operation of this system, it has been confirmed that themethod descnOed in this paper is very effective in order to construct an expert system which can replace the reactor operator'srole with Al system. Application of this model to developing
an autonomous plant is intended by refining the model and programming other part of it.

V.REFERENCES[l] Y.Himeno, T.Nakamura, S.Tenmwna and T.Furubayashi,»Improvement of man-machine interaction by artificial intelligence for advanced reactors," Proc. of SMiRT 11th. Post.Conference Seminar on Probabilistic Safety Assessment Methodology, Kyoto, Japan, 1991.
[2] T.Mild and K.Tamayama. "CooceptUal research of autonomous nuclear power plants," Power Plant Dynamics, Control &Testing Symposium, Knoxville, Tennessee, USA, 1989.
[3] K.Watanabe, T.Miki, A.Endou and Y.Himeno, "Development plan of operation system for autonomous nuclear plant."
International Conference on Fast Reactors and Related Fuel
Cycles, fR'91, Kyoto, Japan, 1991.
[4] T.Miki and K.Tamayama. "Development of a nuclear plant
operator's thought model by the use of a training simulator,"
Proc. of Topical Meeting oo Advances in Human Factors Research on lvfan/Computer Interactions : Nuclear and Beyond,Nashville, Tennessee, USA, 1990.

S17AIA04
Al Applications

575
575

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-S17AIA04

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 Applications576

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

ICALEPCS1991, Tsukuba, Japan

These are called RA and RD and are given by these
expressions:and average values of the vertical dispersion. A brief summaryof results is contained in Table 1.
The study concluded that the collider can be satisfactorily
decoupled in the presence of all known coupling tenns if thetunes are separated by an integer difference of at least 1. It isnecessary to use approximately 100 independently poweredskew quads located in cell centers which have a strength of(GL) of 35 Tesla. Alternatively, 56 skew quads at the locationof the missing dipoles will decouple the lattice, but a peakstrength of 67 Tesla appears to be required.
The optimum location, number, and placement of skew
quad correctors are matters of continuing study. The ultimate
choice of corrector scheme will involve a consideration of the
dynamic aperture in addition to the local badness and verticaldispersion criteria. However, these last two parameters provide
a quick means of making preliminary comparisons of different
corrector layouts.

B +C
lv;-trA(4)

It can be shown that the matrixes RA and RD are notindependent of each other and that only four of the eight tenns
in the two matrixes are in fact independent. It is possible toform two parameters, eA and eD, which are physicallyobservable and can be minimized to minimize the coupling.
The expression for eA is given below with a completely
analogous expression for eD:

ex= [RA11 + (a[3~ RA12)] 2 +(R~A12) 2(5)FThe value of eA **2 is equal to the ratio of the out-ofplane tune amplitude to the in-plane tune amplitude and is aphysically measurable quantity. Section 4 describes measurements of this quantity made in the HERA proton ring. The
decoupling process consists of fanning a weighted sum of theeA terms at the position of every instrumented BPM,
calculating the set of skew quad corrector strengths necessary
to minimize the sum, and applying these strengths at the skew
quad locations. It should be noted that this method has
sufficient information to set each skew quad independently, and
it is not necessary to connect the skews in two or fourfamilies.
B. Decoupling Studies at the SSC
The specific problem of decoupling the SSC lattice has
been studied using the accelerator simulation code described in
Reference 3 (Schachinger and Talman). The specific issue has
been to investigate the possible planments, patterns, quantity,and strengths of skew quads necessary to decouple the collider.
The quantities used to parameterize the decoupling process
are the de,coupling badness function defined above and !.he peak

C. Experimental Measurements at HERA Proton Ring

The local decoupling technique described in the previous
sections requires as input the local decoupling badness
function, which is defined to be the ratio of betatron tune
amplitudes measured at many places around the accelerator.
The ability to measure the decoupling badness in a real
operational environment is critical for the local decoupling
method to work. An experimental measurement of thisquantity was therefore carried out on the HERA proton ring.
The experiment consisted of capturing tum-by-tum BPM datafrom each of the 137 monitors in each plane (274 monitors
total) at injection. The data were analyzed using Fouriertransform techniques, and the horiwntal and vertical betatrontunes were detennined. The amplitude of the vertical betatrontune line in the horizontal BPM data was extracted, as was theamplitude of the horizontal tune line (which was, ofcourse, dominant). The transformed BPM data for thehorizontal and vertical planes are shown in Figures 1 and 2,
respectively. The ratio of the small-to-large tune amplitudes at
each BPM is given in Figures 3 and 4.

Table I
Number Badness

Vertical Dispersion

Comments
small al (0.04 units) GREYS latticeµx = 123.285µy = 124.265

32
32

4.69
0.059

0.4 m nns
1.1 m nns

µr =123.285

32

NA

NA

no solution unstable optics

92
100
200
47

0.00290.00310.001

0.8 m nns 2.2 m peak
0.4 m nns 1.6 m peak
0.2 m nns 0.8 m peak

0.03

0.3 m nns 0.8 m peakµv = 125.265

injection energy 1.8 TEV
al=0.3, lOF lattice 20 TEV

one pair of skew quads every 8 cells
minimum eta placement
one pair of skew quads every 4 cells
one quad in missing dipole 500 detectors

S18BPA01
Beam Physics Applications

577

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

RD=

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA01

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

0.7

5

0.6

4
0.5

<JI
<JI

t

Cl)

c

u. 3
Ci

..0

Cl)

C>

~

"O

0.4

:§ 0.3

~ 2
ii
E
ct

a.

:::i

0

I
)
"'

·~

0

Ox10 4., ,,,,,/

1x10 42x10 4

\,

0

0.2
0.1

~

l"f,'fV\.l<.v,"..,,,..Jt.,<'3x1o4

4x10 4

20

5x1o4

40

60

100

80

120

140

120

140

BPM number

Frequency in Hertz

Figure 3. Horizontal Coupling Badness.

Figure 1. Horizontal Data.
0.12
0.10

5
<JI

:g 0.08
c

4

"O
!ti

·! 0.06
.=

tu. 3

ii
:::i

8 0.04

Ci
Cl)

"O

.~ 2
ii

0.02

E

ct

0

20

40

60

80 .

100

BPM number

Figure 4. Venica(CoupJiniBiidiless:ox10 4Frequency in Hertz

II. CONCLUSIONS

Figure 2. Vertical Data.

The horizontal coupling badness has a maximum value atthe location of the skew quad pair in the IR sections. However,the RMS value is less than the corresponding function in thevertical plane, indicating that the global decoupling will put alarge local perturbation into the optical functions while
reducing the overall coupling. The magnitude of the coupling
functions are proportional to the tilt of the local eigenplanes.
The measurement of the local coupling functions on an
operating accelerator shows that the quantities necessary for
local decoupling can be experimentally measured. It remains to
be demonstrated that these values can be used to locally set
skew quadrupole strengths.

This paper has shown results indicating that it will bepossible to locally decouple the SSC lattice using a local
decoupling algorithm. The mathematical basis of thealgorithm was described briefly, and references were given for acomplete description. Experimental measurement of the local
coupling function required by the algorithm has been
demonstrated on the HERA proton ring.

ill. REFERENCES[l] Richard Tahnan, Coupling Effects in the SSC Regular

Arcs, SSC-N-93, December 1985.
[2] Richard Tahnan, ''Transverse Motion of Single Particles

in Accelerators," AIP Conference Proceedings, No. 184,
1987, p. 190.
[3] L. Schachinger and R. Tahnan, ''TEAPOT: A ThinElement Accelerator Program for Optics and Tracking,"
Particle Accelerators, 1987, Vol. 22, pp 35-56.

S18BPA01
578

Beam Physics Applications
578

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

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-S18BPA02

Main Control

Eguipement building

In Machine

B.QQ!!l
AnalogsignalResonant
Pick-up'sr

AnalogSignal
Processing...

~

VME Digital
Signal
Processing

Ethernet~

Operator
Display'Workstation·~

MachineTiming~Additional
Work-stations

Fig. 1. System Overview

AC

AA

Center freq.
MHz49.220271.9379

Gain
dB
60

Bandwidth
MHz
1.5
4.3

60

software is flagged to copy the data to a circular buffer,
reset the converter, and flag the data treatment software.
The data treatment software has two options. If the data
was acquired at injection, it copies 512 samples of raw
data to a named data module, and performs a single FFf
on the first 1024 data samples. This gives a measurementof the injection process. Data modules here imply thesoftware structures as permitted under the OS9 operating
system.
If the measurement was not at injection, it performs
16 sliding FFT's on the 8192 samples and then averages
the resulting spectra. All these results are then saved inother data modules ready for any requests via the control
system.
In addition the data treatment software adds to thedata module any other information that might be neededby a display program, for example, gains, timing information, labels for graph axes.

Rev. freq.
harmonic
31
39

The system will cater for six analogue signals, i.e.
the sum, horizontal, and vertical signals from both the AC
and AA rings. There will be six parallel channels up to the
VME chassis. The additional workstations could be in thecontrol room, in a laboratory or even in an office, theonly requirement would be the availability of access to thecontrol system Ethernet.
ANALOGUE PROCESSING
The signals for each measurement all have similar
analogue processing. The signals are first down converted
using upper sideband mixers. They are then amplified andfiltered by elliptic antialiasing filters, and further
amplified to match the full scale range of the ADC's.
Figure 2 illustrates this schematic layout.

COMMUNICATION AND OPERATOR INTERFACE
The communication between the VME crate(server) and the DEC-3100 workstations (clients) is established using the standard TCP/IP socket library andEthernet interface. A user defined port number is used toaccess the self-written driver installed on the VME crate
to serve the clients. To provide the separation between
data acquisition on the server and the final display on the

DIGITAL PROCESSING
The acquisition is started by a timing pulse from theaccelerator (AC or AA) triggering the analogue to digitalconverter. This acquires 8192 samples at four microsecond intervals. When the data is acquired the data reading
SingleSideband
Mixer

~

y

AmplifierGoin
40 or 50dBr

FilterGoin 70 dB
LF 250 Hz
HF 68.2 Khz

L

y

ADC
Res. 12 Bit
10+10 toVolt range

to VMEY
bus

l

r

_J
Pick -up
Sig nal,~MachineTiming
Trigger

Local
Oscillator

Fig. 2. Layout for analogue signal processing

S18BPA02
580

Beam Physics Applications580

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingclient, a prototype database approach has been implemented on the server. A database file contains the namesof all the data modules available to the client. This filealso permits a multi-name mapping between a user preferred name and the real name of a data module.
Once the server accepts the connection request for aclient through the user port, it sends all the relevant information including labels, axes information, etc. relevant
to a particular data module to the client. The user selection of a named module is done through the menu-driven
selection box on the workstation. This name is translated
onto the real data module name and the request added tothe active (hot) link table on the server. The data module
header contains the date and time information. This is useful and necessary because the server task is continuallyscanning the date-time stamp in the headers of all the data
modules in the hot link list and transferring the latest data
blocks to the corresponding clients. The server task also
checks if a client request has terminated and the validity of
the client-server link. If the link is severed, it removes all
the data modules of the interrupted client from the hotlink list.
The data from each data module is displayedgr~LDhllC<Lllv in a window as shown in Fig. 3. For multiple
mc1du.tes, a multiple set of windows are
togetherin a main window to permit a sequential observation of achain ofasto theof aof thecollector
accumulator
beam

complex. Depending on the data, each window is individually auto-scaled and re-sized. Using the standard tools of
the MOTIF tool kit, zooming, integration of values
between set markers or the evaluation of co-ordinates at
any one point on the graph is easily permitted.
SOME RESULTS
Figures 4 and 5 show the sum signal acquired in theAC ring at the time of injection. Figure 4 clearly shows
the appearance of Schottky noise as the beam arrives into
the ring while Fig. 5 illustrates the power spectrum of thesame data. The spectrum is equivalent to the beam longitudinal profile. Figures 6(a) and 6(b) illustrate the beam
spectrum obtained in the AC ring at two different time
points. Figure 6 (a) shows the beam profile straight after
the rf bunch rotation while Fig. 6(b) illustrates the longitudinal beam
4.5 s after injection in the AC ring, i.e.
at the end of all cooling processes in the AC.

Although the system is not completely operational,itshows sufficient
as a good approach forthe data acquisition andthe future. The aim ofdisplay software has beenafter
to thecontext of the data structures that have tothe development of the two parts of the software took

Fig. 3. Typical data module graphical window on a workstation

S18BPA02
Beam Physics Applications

581

581

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-S18BPA02

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-S18BPA02

Fig. 4. Beam arrival in the AC Ring

Fig. 5. Power spectrum of the AC injected beamplace completely separately. The aim of having the data
available on request from the client has been achieved.
The operator can work at his own place, changing thedisplays as required. The system is pleasant to use, withmeasurements taking few seconds instead of several
seconds in the old system.
At present the data processing is using a prototype
program which takes approximately one second to acquire
the data, make 16 fast Fourier transforms, and produce
the mean of the spectra. The definitive program, whencommissioned, will take about 100 ms. Current results
show that the resolution needs to be doubled to give agood measurement with at least 10 data points on the fully
cooled beam. Similarly, for the injected or uncooled beam

an improvement in signal to noise ratio by a factor of two,would give a spectrum which would be much easier tointerpret.
REFERENCES
[l]

[2]

Borer J., Bramham P., Hereward et al., "Non-destructive
diagnostics of coasting beams with Schottky noise", Proc. of
the /Xth Int. Conf on High Energy Accelerators, Palo Alto,
USA, May 1974, and CERN/ISR-DI/RFn4-23, 1974.
van der Meer S., "Diagnostics with Schottky noise", Proc. of
Joint US-CERN School on Beam Observation, Diagnosis a11d
Correction, Capri, Italy, Oct. 1988, and CERN PS/88-60(AR), 1960.

Fig. 6. (a) Beam in AC Ring before cooling and (b) after cooling for 4.5 seconds

S18BPA02
582

Beam Physics Applications
582

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

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
can be defined from the time of the External Starts and thesum of the various count times elapsed in the relevant
counters. This can be expressed as the following matrix
expression:[Required Times] =[External Starts] + [M lay-out] * [Count Times](3)

where M lay-out is a matrix reflecting how pulses proceed
through the various counters. Its elements are null if thecorresponding counter is not involved, 1 if the counter isinvolved and its time has to be added, and -1 in the opposite
case. Count Times are simply obtained from the counters
control values and their clock periods Tck:
[Count Times] = [Control Values] * [Tck](4)

If one defines as many Required Times as counters in the
lay-out, M lay-out is not singular and the control value can be
deduced from the preceding expressions:[Count Times][M lay-out=r * {[Required Times]-External starts]}
1[Control Values] = [Count Times] I [Tck]

(5)
(6)

Clock periods Tck can be evaluated from the hardware
settings (for internal clocks) or from machine parameters (forexternal RF or Field-derived clocks). Therefore all control
values can always be worked out from the required times, inall machine conditions.
This has been applied to the PS hadron injection timing.
The system layout has been translated into a matrix M lay-out
to define the required times. The resulting interactive display
is shown in Fig. I.

ICALEPCS1991, Tsukuba, JapanIII EMITTANCE AND MATCHING

MEASUREMENTS
A method for the measurement of transverse emittance in
the PS and matching of the beam between the Protron
Synchrotron Booster (PSB) and the PS rings was implemented
in the present control system 2• A new version of thisApplication has been designed to fit the method to theframework of the new CERN-PS control system through theconcept of man-machine interface and using workstations 3 •This method is based on the measurement of beam profiles
at three different secondary emission monitors with known
transfer matrices between them. The three monitors arelocated downstream of the PS injection region, each of themmeasuring a horizontal and a vertical profile.
With withe half beam widths or heights measured at the ith monitor position and Pi 0 the P-functions of the machine(i.e. of the acceptance ellipse), the beam emittance and thegeometrical emittance increase due to mismatch of theincoming beam 4 may be written as

w.2

E = Qi~lion--AA

1 -....,.

~

CcDtiticrm
sti:nd.ard. t In· oction
C-1»0 fM}
I IOJ At c hlN
Idol: {T/•1~::::.

._.'J#aY/clbbor of CMrqe1ITi.- fZOlil AlfG:Tlll'ICO

I

Oen, Cc:rnditiCM

D IOJ «t inject.
215
007.t

o.c

..... lb!
P (C.T/cJ l>Ol' dK,rqa

I lulpa Start'
10

F~,_., n· tica

T (COT)
a..-& Trlll:'lritina

l.HS

'·"""

<.WJ

:m.:
1

I M....nf_fil•
frca PX.m:

frm :t.jectian

fnm Stat :e-n.r
Ira St.vt tu.per....

laquntK Tllroru.""'

ru.ooo-2S.CO<-25.000..
.."'..
....... ....... ....
-<.m-<.<SS

239S.Je2
239S.3U-7.007-H.007239S.Je2
239S.3'H-1.000-U.000"'-1.111-1.107 ..

um

1.rm

0,JS,

0,35,
1.SSS
-2.000 n

1.SS7-!.OCH~·•··=l.,:JSI (Col")Prusnt TiM

1 Injoction Tiao

Yalue•
007.000..-

him Iajiteticn

141$klll Slew Trmdo frca lajoc:ticn

1'>.cq f&at Trmsfo tr. I.njoctiim

A21-'iO

(7)

and
(8)

with

k (~
"SJ;

k =-

,_,

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA03-1)2 + j ~ 2 )(9)where j is the imaginary unit,~ and SJ; are the normalized
matching parameters which describe the beam emittanceellipse and k is the complex mismatch vector of the beam 2 •The mismatch vector k provides a measure for thecomparison of the emittance ellipse of the incoming beamwith the acceptance ellipse of the PS in the injection region .
The modulus of k has to be much less than unity for good
matching. For instance, lkl is equal to 1f\/2, when theemittance blow up reaches 100%.
From the three half beam sizes wi measured with monitors
at different positions and with the knowledge of the transfer
matrices between these monitors, the normalized matchingparameters at one monitor position, say 12.1 and .Gp may be

expressed as functions of the wi, p10 and the phase advancedifference ~~j between monitors i and j 5 •When the beam is perfectly matched, the normalized
matching parameters take the values 12.1 = 0, .Q1 = 1. Hencethe beam emittance may be estimated from a unique halfbeam size measured with a monitor, say w 1, using Eq. (7) inwhich.Q1 is set to unity.

Fig. 1: Interactive display of the timing modelling programme. Present
times are computed from the hardware acquisition through Eqs. (3-4).
Requested times are filled in by the user and provide control values throughEqs. (5-6).

A convenient definition of the half beam sizes when the
beam profile density is not exactly known consists in taking
for wi twice the r.m.s. value of the profile distribution.

S18BPA03
584

Beam Physics Applications

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

ICALEPCS1991, Tsukuba, Japan

In the presence of dispersion , the pure betatron half beamwidth wf3 i must be used instead of the overall half beam widthFig. 3: Display of the mismatch vector in polar fonn. The area within thecircle fits to emittance blow-up below 100%. The 2-r.m.s. emitlrulce, theemittance blow-up due to mismatch, and the normalized beam matchingparameters Qll' Q. 1) at the !st monitor location, with their corresponding Twiss•emo - pis AA
PlS

Mon Holl

4 14 :55:04

ex. ~.so:tIS!:R • M

76 :rar BT'P . '!'RA:~~.... ,. ..
;,~PI..A.'IE • VDl

D:ait ..

:l_,;,;~.1
5

Zoo::.. •l. 6

FR. MS!l52!JOM •

29 . 32....~. :1~1
~
~

. ,.

'~

5

0

10 15

= ..

20 25 30
: 2.00PR. !15054:lk~m~~ I
50

Sta.tu~ :7. 95

Sitp.a •10 15 20 25 30
S'ITP : 2. 00

----

~

IRW\

4.64

Mel>?\ • 31. 78

PR . !!5049

0

-

no

-1

.

Signa •7. 09

ZCCIS. •1. 6

l1ee..~• 30. 92

Si gD.l1 •7. 22

10 15 20 25 30
S'lZP : 2. 00 Zoaia ..
proc o='-' in p~u~c

1. 6

Fig. 2: Display of transverse beam profile di stributions at three d.i fferent
monitors. 111e bars cha.Its show beam profiles measured with 32 wire gridmonitors. 'The continuous lines show the smoothed profiles after elimination oferroneous datn (the smoothing coefficients ore chosen by the user). Beamemiuance, menn and r.m.s. val ues of the smoothed profil e distributions arc
given.
Adapt. Form

P<""> (E) :(t{<3)(G):

El:ait at

2a:

13. 63 .,- 0. 12-0 . 01

0.93

Illparameters (al' f:\). are shown. Estimations of the beam emittance obtained
from half beam sizes measured with the three monitors, regardless to beam
matching, are shown for comparison.

IV INJECTION TuNING
A method for the correction of oscillations at 1 GeV
injection into the PS was introduced in a early version of thecontrol system 6 . As in the ca...~ of the emittance and matchingmeasurement process. an up-to-date version of the hadron
injection process has been assembled in order to be integrated
in the new CERN-PS control system.
The amplitude and the phase of the pure betatron injection
oscillation when the closed orbit is unknown are derived byadjusting a sine curve to the normalized beam trajectory
difference between two consecutive turns measured shorHy
after injection. Moreover when the machine tune is also not
known, the optimum tune value which minimizes thesummed-square error between the fitted sine curve and thenormalized measured trajectory difference is determined by
iteration. This yields a satisfactory knowledge of the betatronoscillation at injection. Hence the correcting strengths to be
applied to a given pair of injection steering elements in orderto cancel this oscillation are evaluated accordingly.
For the beam trajectory measurements, 40 pick-up
monitors are installed around the PS ring, each measuring ahorizontal and a vertical beam position with respect to thepick-up center. Trajectory position at monitor i in machine
tum number n can be written asxi n0.16 \

40 2 (¢:1)/P<""h5. 01 'I! .""'1.mrad

4a>co»/p,.,,,

4. 29 1!. =.mrad

4a>o••>/P,,,..>,

4.1 ~ 7t ,.,,.,, arad

~daptatio n

Vector(10)

in which zi is the closed orbit value at the i-th monitor
location, µi, ~i are the phase advance and the ~- function at
this monitor position relative to a reference location R in themachine, Q is the tune (not an integer value}, and A,$ are theamplitude and phase of the betatron oscillation respectively.
The normalized trajectory difference between two
successive turns is then independent of the closed orbit andmay be written as_ {f; Xi n - Xi n+ 1

4.64 'l!. ""'1. ill!:ad

Blow up:=zi +A~ cos(µi +qi+ 2(n-l)n:Q).

·\J ~ 2 sin rcQ =C sm µi + D cos ~(11)

where C and D depend on A, qi, Q and the turn number n.
Least square approximation of measured beam trajectory
difference provides estimators C and J2 of variables C and D
by minimizing the summed-square error

a'=

tf.2

f, [~ x~ ;:".:Q+'·£sioµ,J2<;osµ,]2 (12)

i=l

S18BPA03
Beam Physics Applications

585

585

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

which includes both the betatron and momentum
dispersion contributions. No such correction has been
implemented until now.
All acquired profiles are analyzed prior to the beam size
evaluation since faulty grids, fluctuations in grid output
signals and random disturbances on the beam may perturb themeasurements. The treatment of the profiles are performed
only on the user request, and consists of the following:
elimination of faulty grid measurements,
treatment of the tails (for base line detection).
profile smoothing using spline functions.
wi

File

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA03

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

where xmin• xmi n+l are the measured beam trajectory in
two consecutive turns, N is the number of monitors providing
reliable signal data.
In case of faulty monitors, the rejection of erroneous
acquisitions is based on usual statistical criteria to decide
whether the chance of occurrence of some particularmeasured beam position is less than some fixed number.
Hence approximate values A and ~ o'f the betatronoscillation amplitude and phase can be derived from theestimators .C and .Il. The position and angle variations Llx 0 ,Llx' 0 of the beam at injection point with reference to theclosed orbit can then be obtained from Eq. (10). Finally thecurrent variations values M 1, 612 to be applied at the twocorrectors (septum and steering dipole) to cancel the injection
oscillation are derived from these position and angle by alinear transformation written as a 2 by 2 matrix equation. The
components of the transformation matrix can be either
determined experimentally or from a programme for latticedesign.
The summed-square error cr2 near the real machine tune Q
is well approximated by a parabola. Therefore a search
procedure may be carried out to estimate the unknown tune
value Q. The Fibonacci search has been considered as an
optimum Q-seeking method. This procedure starts from theinitial search interval, and successively reduces thesubsequent search intervals by means of a sequence of
numbers, which are determined from the Fibonacci numbers.
The number of search steps is fixed by advance. The
Fibonacci search is the most effective one-dimensional searchstrategy available. An accuracy of 0.01 is then achieved with
8 search steps within an initial tune search interval of 0.5.
However, in some cases fluctuations in the monitor
acquisitions may be distributed in such a unpredictable waythat the tune calculated in this way is irrelevant. Assumingthat the trajectory measurements are done in the 1st and 2ndturns, the tune error is inversely proportional to the signal tonoise ratio. For instance, rough estimate shows that when theamplitude of the oscillation at injection is lower than 5 mm,
the tune accuracy cannot be kept within 0.04.
Consequently the tune search is mostly reliable at the firststages of the correction process, when the injection
oscillations still have large amplitudes. Once an adequate
estimation of the tune has been found during the first few
corrections, the latter Q-value can be frozen and further
corrections may be carried on to refine the injection tuning.
Simulation from the trajectory data has shown the validity of
the above algorithm.
At any stages of the tuning process, no automatic
corrections will be performed, the computed corrections are
merely proposed to the user, who decides whether they haveto be carried out. Fig. 4 shows the proposed Workstation
window for the horizontal and vertical interactive correctionsof betatron oscillations at 1 GeV injection into the PS.

,

__

,

Fig. 4: Display of !he interactive window used for !he injection runing.
For every two single tum trajectory measurement, !he computed tune, !he fit
quality and !he characteristics of the derived betatron sinewave are anticipated.
The appropriate currents to be applied to each pair of correctors will be
displayed for possible user action.

V CONCLUSION
The injection timing control and the emittance andmatching measurements are presently implemented within the
new CERN-PS control system and are used in current
operation to the user satisfaction. The third application,
optimization of the betatron oscillations at injection into thePS, although well under way, is not entirely set up. The
search of the optimum tune and the calculation of the twocorrections which will cancel the oscillations are finalized,
but the final stage, on-line connection to the beam trajectorymeasurements, is in the process of being implemented.

VI REFERENCES[1] J.P. Riunaud, "Modelling of a Timing Process", Internal Report
CERN PS/PA Note 91-21, November 1991.
[2] M. Martini, "Calcul de la desadaptation dans la ligne d'injection
a 800 MeV du PS", Internal Report CERN/PS 84-12 (OP),
August 1984.
[3] M. Boutheon, F. Di Maio, A. Pace, "General Man-MachineInterface used in Accelerator Controls: Some Applications in
CERN-PS Control Systems Rejuvenation", these Proceedings(ICALEPS, Tsukuba, Japan Nov. 1991).
[4] K. Schindl, "Increase of 95% Emittance due to Missteering andMismatch", Internal Report CERN MPS/BR Note(75-25,
November 1975.
[5] P. Brummer, "The Method of Measurement of the Emittanceand the Betatron Phase Space Parameters in the Beam Transfer
System of the ISR", Internal Report CERN-ISR-OP(72-6,
January 1972.
[6] M. Martini, J.P. Potier and T. Risselada, "Automatic Injection
Tuning Using Two Successive Single Tum Trajectory
Measurements", in European Particle Accelerator Conference
EPAC 90", Nice, France, June 1990.

S18BPA03
586

Beam Physics Applications
586

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

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

that the error must be with an element that is located upstreamof the monitor, most probably between the last reached and the C. The Errors Looked For
first missed monitor.
As the beam position measurement during first turn
It is therefore natural to divide the beam line in groups of steering is never very accurate, CARSO looks only for large
elements between two adjacent monitors. CARSO steers the element errors, such as:
beam from one group to the next and stops when the last • large beam energy errors or dipole field errors, respectively;
monitor is reached.
• quadrupole polarity errors;
One such group is named a 'monitor group'. The whole - BPM button electrodes cabling errors;
structure of CARSO is built to first check one group and then - "hot" or dead button electrodes or whole monitors,
to fine adjust the beam so that the BPM readings of the two
respectively;
monitors forming the group boundaries are close to zero. - lumped steerer cabling errors (wrong polarity or exchanged
CARSO assumes that all upstream groups are without errors,
planes);because they have already been checked. Also the upstream • incorrect steerer current/strength relations.
monitor of the group is assumed to be O.K., since it has been
By comparing the predictions from the model with thechecked when it was the downstream monitor of the previous measurements, CARSO is also able to detect larger deviationsgroup.
from the nominal element strengths and BPM imperfections,
The assumption that all the elements upstream from the but it is not able to localize them uniquely, unless there ismonitor group are errorless is essential. It allows CARSO to only one element between two monitors. This is left to theuse all upstream steerers and monitors to localize a possible human operator who has much more ability for global
error within the monitor group. To be precise, CARSO reasoning than any software.
assumes only that the upstream dipole and quadrupole
strengths are correct. It is not affected by transverse D. The Actions Taken
positioning errors, because it performs difference
If CARSO encounters problems, it either corrects themeasurements. Even if the steerer that is used for the differenceat the source or tries to overcome the effects of theerrorsmeasurement is not correct, CARSO will spot it in most of
t11e cases, because it checks the monitor group by measuring errors. CARSO can perform the following actions:the beam position in the two monitors. The actual steerer • recalculate the beam position from BPM button signals, if
buttons are miscabled;
strengths do not enter into the calculations.
reassign
steerer polarity and plane, if the steerer's power
If some elements between the steerer and the upstream
supply connections are wrong;monitor of the monitor group are incorrect, and they have been
overlooked during checks of upstream groups, CARSO might - change the sign of a quadrupole strength in the model, if thequadrupole has a wrong polarity - CARSO is then able toassume a steerer error or an error in the monitor group.
continueand still complete the first turn, although the
CARSO does not have the complexity to spot such effects.
operator
would
usually stop the processing in such a case;
Therefore CARSO provides sufficiently rich output messages,
which allow the operator to decide, whether there was really an - measure the transfer matrix of a whole group of consecutive
elements and place this matrix into the model for
error in the monitor group that was under investigation.
of CARSO, if the error can not be localized tocontinuationCARSO changes its model of the ring to comply to its
one
singleelement;
measurements only if the operator confirms the suggested- look at downstream monitors, if the monitor shows nochange.
beam;
Even if the operator's decision is wrong, CARSO will·•
performa systematic two dimensional blind scan using one
soon recover from erroneous assumptions, because once theorseveralsteerers simultaneously, if the beam is lost or
faulty elements are upstream of the steerer which is used to
does
not
reach
the next monitor;
check a monitor group, they do imt influence the• adjust the beam position to zero at two consecutive
measurements any more.
monitors with one or two steerers, in both planes, if the
The only limitation on the performance of CARSO comes
beam position reading is outside the tolerance given by thefrom the measuring precision of the beam position monitors.
BPM resolution;CARSO uses the measured beam position at upstreamscan
the current of the dipole around the nominal value, if
monitors to extrapolate it (by means of the model) to thethemonitors
which are downstream show no beam evendownstream monitor of the monitor group and to compare it
after a blind scan;with the measured beam position. If the measuring errors are
too large, they screen all other errors that come from a - switch off a quadrupole and measure its current/strength
relation.
mismatch of the real lattice with the model. The limiting
The last two actions are seldom performed because itmeasuring precision depends on the lattice chosen and on theusually takes a lot of time to change the power supply
monitor spacing.
currents of dipoles and quadrupoles by large amounts.

S18BPA04
588

Beam Physics Applications

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

ICALEPCS1991, Tsukuba, Japan

If CARSO encounters steerer and monitor errors that it can
not correct, it simply discards the steerer or monitor,
respectively, and does not use them any more during its run.

The notes mean:[1] If there is no beam in the monitor, downstream monitors
are also inspected. If one of them gives a positive sigilal,then the monitor group is extended up to this monitor
and all the monitors in between are marked to be dead.
[2] The blind scan is first done with the most effective
steerer, then with the next effective steerer and so on,
until it succeeds to get a signal from any downstream
monitor. If it does not succeed with single steerers, it
uses several in parallel.
[3] CARSO takes into account that quadrupoles that are
powered in series with upstream quadrupoles can not beswitched off.
[4] Only one dipole in the group is scanned, since usually
the dipoles are powered in series. Also the energy error iseither spoued already in the first dipole, or never.
[5] The monitor is checked by sweeping the beam across all
its four quadrants. Up to three steerers are used, to ruleout possible steerer errors. Therefore also wrong steerers
are detected in this routine.
[6] A sine trajectory means that the beam position at themonitor is zero and its slope is maximal. A cosine
trajectory has zero slope and a large displacement fromthe beam axis. First, a cosine trajectory in x and a sine
trajectory in z are established, then a sine trajectory in x
and a cosine trajectory in z. If either one of these can not
be set due to limited steerer strengths, only a simple
difference measurement is performed.
[7] The beam position in the second upstream monitors
must be measured to determine the slope of the beam in
the first upstream monitor. Here the model of the ring
between the two monitors must be used. CARSO
assumes that it is correct, because it has been checked in
the previous monitor group. From the determined
position and slope at the upstream monitor, the expectedbeam position at the checked monitor is obtained bymatrix multiplication.
[8] If the previous group was already wrong, then the checkis meaningless, because the slope of the beam at the
upstream monitor of the monitor group can not be
determined correctly (see [7]). However, if the current
monitor group is correct, then at least the transfer matrixof the whole previous group can be measured and stored,
so that the error does not influence calculations oftransfer matrices of elements that are further upstream. If
there is a steerer within this previous group, it is marked
to be locked, set to zero and not used anymore.
[9] The current in the quadrupole is increased stepwise andfor each step the quadrupole strength k is measured inboth planes and compared to the expected one.
[10] The steerers that could not move the beam significantly
or looked as if their cables are misconnected, are checked
numerically by comparing their measured M12 transfer
matrix element with the one calculated from the model.
[11] The beam is adjusted such that the measured position at
the upstream and at the downstream monitor of the

For each monitor, CARSO performs the following
algorithm:...-----------.

beruninmonitor? [l]1-y_es_ _..,

noswitch off

perform blind scan [2]success

failedyes

any more quads? [3]faileddipole scan [4]

no

stop

success - - - - - - - - - - - - 'check monitor for cabling errors [5]h..------------..-------------.
irrecoverable errors found?
go to next
monitoryesnoet a sine and a cosine [6] trajectory at
previous monitor and measure beam
position at monitor
is difference between measurements
consistent with model predictions,ased on upstream measurements? [7)noyeswould difference be consistent withmodel if a quad had a polarity error ?
nodid already the previous monitor
group have such problems?
noprevious
group [8]are there any quads in this group?
yes
is the measurement of tht transfer
atrix of the whole group sucv•,ssful?
yes
update model, if allowed by operator

heck quads that were switched off [9]check steerers that behaved strange
while checking the monitor (10)fine adjust beam (11]

S18BPA04
Beam Physics Applications

589

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

E. The Flowchart of CARSO

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S18BPA04

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

monitor group is minimal, i.e. below the measuring
imprecision of the monitors. This is achieved in bothplanes separately with one or two steerers. CARSO
provides two options - either the use of measured Mi2transfer matrix elements for the steerers or the use of theones from the model.

III. THE CURRENT IMPLEMENTATION AND ITS
LIMITATIONSCARSO is written in ANSI extended standard FOR1RAN
77 and has been successfully compiled and run under
V AXNMS and HP-UNIX operating systems. It has beentested and studied with a linear simulation of the storage ring
ELETTRA [5], which simulates transverse magnetic element
and BPM positioning errors, dipole quadrupole and steerer
strength errors, quadrupole and steerer polarity errors, and BPM
button electrodes cabling errors.
The model which is used by CARSO is a linear thick lensemodel using transport matrices, without skew elements.
Fringing fields and nonlinear fields are not taken into account,neither is the finite beam size nor the BPM nonlinear
response. However, the BPM nonlinear response which is dueto the field distortion of the vacuum chamber wall, can inprinciple be corrected for by the BPM software.
Besides the procedures to check and steer one monitor
group, as described in the previous chapter, CARSO also
includes an initialization and an epilogue. The initialization
performs the following:- initalizes the CARSO variables and defines output screens;- reads the data describing the model of the ring from a file;- calculates the transfer matrices of each element;- defines a list of effective steerers for each monitor;- measures the launch (injection) coordinates (x,x',z,z').
The launch coordinates can be measured only if there are atleast two monitors between the injection point and the firstbending magnet and if the quadrupoles in between are switched
off. This is feasible forELETTRA [6], but may not be so forother rings, in which case the launch conditions must be
supplied by the operator.
The epilogue just displays some statistics about the beam
position in each monitor, the r.m.s. of the measured orbit andthe maximum steerer strengths.
CARSO was built with the electron storage ring
ELETTRA in mind. Although CARSO is a general program,which can take any lattice from an input file, some details arenevertheless specific for a ring like ELETIRA.
It is obvious that - since CARSO runs automatically nondestructive beam position monitors must be used.
Fluorescent screens could be adopted only if they were moved
into the beam pipe automatically and providing the beam
position could be read out by software.
The check of the BPM button electrodes cabling errors
works only for BPMs with four button electrodes, where thebuttons are placed around the centres of the respective
quadrants. If the buttons are placed on the x and z axes, thesubroutine which checks the BPMs must be changed orskipped.
The next site specific algorithm is due to lumped steerer
magnets. The current implementation of CARSO supports
only combined horizontal/vertical steerer magnets. CARSO
generally treats the two planes separately but for two cases:
the blind scan and the monitor check are done with both planesof one steerer. Hence the most effective steerer is defined to beeffective in both planes. For rings with single plane steerer
magnets, the data structure also will have to be changed.
A minor change in the initialization of CARSO will haveto be made if pure dipole magnets or sector magnets are in thelattice. ELETI'RA has only hard edge dipoles with a nonzero
index. However in this case only the subroutine defining thetransfer matrix of a dipole must be slightly changed as well as
the input statements to distinguish between different types ofbending magnets.
IV. CONCLUSIONSCARSO replaces successfully the machine operator forroutine tasks during first tum steering, once the hardware isstable and reproducibly controlled by the control system.
However, it requires a reasonable beam position monitor
spacing and measuring precision and full computer control
over the equipment
It is planned to use CARSO during the commissioning of
ELETTRA and also after longer periodical shut downs. Being
tailored to the specific ELETIRA components, CARSO canalso be used for first tum steering of other storage rings withlittle changes to the software.

V. ACKNOWLEDGEMENTS
I am happy to thank Albin Wrulich for the initiation of theoriginal idea and for many other discussions concerning this
topic. Comments and suggestions on the algorithms were
given also by Carlo Bocchetta and Ryutaro Nagaoka. Antonio
Choi thoroughly debugged CARSO and helped me to findmany errors. Many thanks to them all.

VI. REFERENCES[l] J. Milutinovic and A.G. Ruggiero, "First Turn Around
Strategy for RHIC'', Proc. PAC 1991, San Francisco, 1991.
[2] A whole list of closed orbit correction procedures may befound in D. Brandt, W. Herr, J. Miles and R. Schmidt, "A New
Closed Orbit Correction Procedure For the CERN SPS andLEP", Proc. ICALEPS 89, Vancouver, 1989, or in J. Sheppard
et al., "Beam Steering in the SLC Linac", Proc. PAC 85,
Vancouver, p.2180, 1985.
[3] D.L. Lager et al., "MAESTRO A Model and Expert System
Tuning Resource for Operators", Proc. ICALEPS 89,
Vancouver, 1989.
[4] M. Lee, S. Kleban, "SLC Bean Line Error Analysis Using A
Model Based Expert System", Proc. EPAC 88, Rome, 1988.
[5] ELETIRA - ConceplUal Design Report, Sincrotrone Trieste,
Italy, April 1989.
[6] M. Bassetti, C.J. Bocchetta, A. Wrulich, "Magnet Lattice for
the Sincrotrone Trieste", ST!lvI-87-11, August 1987.

S18BPA04
590

Beam Physics Applications
590

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

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

Ill. EXPECTED ADVANTAGES OF USING CONTROLPROTOCOLS

IV. CONCEPTUAL DESIGN OF CONTROLOne can summarize the positive aspects of control
protocols as follows :- seen from the top (operation), they provide a uniform
visibility to the application programs for a class ofdevices.
- seen from the bottom, the device specialist can totally
dedicate his skill to solving his specific problems in the
more suitable way.
- as a consequence of the previous point, control protocols
promote a better use of competences. Where the controls
activities are mixed with the activities of the specificequipment, each party has to learn implementation detailsof the other party, that are not of his domain ofcompetences. Obviously, this inconvenience is largely
reduced with control protocols.
- a clean separation of responsibilities is introduced between
controls and equipment specialists. The two independent
realizations that communicate with each other only byexchanging well defined messages, permit to fix theposition of this ideal "red line" in a natural way at the levelof the messages themselves. This is particularly importantduring fault finding on a system, where the problem ofdetermining which specialist is concerned arises.
- as a consequence, the maintenance of the systems is
simplified and facilitated. We recall that the cost in manpower for the maintenance is estimated at about two thirdsof the total cost, calculated on the total lifetime of the

As already mentioned in the Introduction, the design phaseof the control Protocols has been divided in a sequence ofinterdependent activities: the output (conclusions) of eachactivity is used as input (assumptions) for the next one(Figure 1). In order, these activities have been :device.
( -fOW[R CONV!RfEllS

FAMIL y1-BfAH

INSfRUHlNfS

OF-VACUVM .SYSTEMS

oev1ces:~R~ _s~s_'!"!S..~---

SfAflCOYNAH!C>tOOEL

MOOEL

OfHER
HODEL

8EHAV/Ol/RAI..
HOO ELS

PROTOCOLS

A. Definition of a Class (Family) of Devices
All those devices with similar characteristics and (or)similar goals, belong to the same class. The first three bigclasses of devices that we have considered are :- The Power Convers-The Beam Instrumentation devices- The Vacuum systems

B. The behavioural models
A model is an abstract representation of the behaviour ofan object In our case the object is a device symbolizing aclass of similar devices as previously defined. The control
protocols we propose are intended for an operational use of thedevices and the specialists have limited their investigations
inside this boundary. The result is a serie of models covering
all the operational aspects of the concerned families of devices.

C. Identification of the Functionalities
In the behavioural models of a class of devices, all those
activities that have a common goal in the operational sense
can be grouped together to form a Functionality. As an
example, five functionalities have been identified in the power
converters model :- Status_controller- Settings_ actuator- Measurements_actuator- Trigger_sequencer- Function_generator

D. Parameters of the Functionalities==

P.ARAHEURS,-'1.ARl.ABLes,_AITIUBUTES

DATA
Sf!IUCTUllEStJESCRIPT/ON(ASN.11''----~\7

Each single activity inside a given Functionality isaccessible by the external world through an appropriate
parameter. In general a parameter is composed of variables andattributes. Variables contain the setting values at a given
instant. Attributes contain constants representing, in general,the limits of validity for the variables (max. and min. values,
lists of discrete values, etc.).
For each Functionality, a complete list of parameters,
variables and attributes, has been defined.

//HPUM!HfATIOHS

Figure 1. Design phases of control protocol

E. Data structures representation
With the identification and the definition of the parameters
and their associated variables and attributes, one can consider

S19SP01
592

Standardization and Protocols

592

that the fust, important phase in the activity of the WOPRO
is terminated. This design phase has produced a significant
amount of inter-related data : an adequate tool of representing
structured data should then be used. We have decided to use the
Abstract Syntax Notation One (ASN.l) that is an ISO
International Standard (ISO-IEC 8824) fulfilling our needs.
ASN.l uses a metalanguage that permits a simple data
representation, totally independent of any specific computer
environment : from that, the data structure can be easilytranslated into a specific source code.

V. GENERAL IMPLE:MENTATION SCHEMESAs already mentioned, the details of implementation arebeing studied with the control Groups, using their standards
and tools. Tbe
described here is only a sort of block
diagram, representing the basic entities necessary to
implement the control protocol (Figure 2). The
implementation is composed of two main parts, one specificto each device and one general for a class of devices. They
exchange information through the standard defined messages~md need data bases torelevant data. In more details :TRANSLATION

lEVEl

ClASS
FRAM/:ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S19SP01

A. Definition of Class Frame
The Frame contains a list and a structure definition of all
visible functionalities, parameters, variables and attributes fora class of devices. In general the Frame does not containvalues; the only exceptions are attributes: each attributedefinition is accompanied by a complete, numbered list of all
possible values in the process accessed by the control system.
The frame should be housed in a central computer data base.

B. Definition of Configuration
The configuration contains the list and the values of all
functionalities, parameters, variables and attributes for asingle, specific device. The form and the structure of these
entities are the same as for the class Frame. The configuration
should be housed in the device itself and should be extractedusing standard services during initialization orc~Jure.

C. Definition of Messages
The mess.ages contain the necessary information exchanged
between control system and devices. They represent also the
red line for separation of responsibilities. Their contents andtheir logical structure are independent of the controls
architecture. Their physical structure depends on the conlrol'.ifeatures.
The message is composed of a certain number of fields
corresponding, at the very most, to the number ofFunctionalities identified in the corresponding devices class
Model. Each field contains a list of the parameters, variables
and attributes characteristic for this Functionality, with theirassociated data

D. Definition of Translation Level
This is a software module that translates the user requests
into messages in protocol format. The Translation Level isthat part of the control protocol that provides the access
Introduction).It gives a uniform
services to the equipment
visibility of all equipment (within a class) to application
programs. The implementation of this module strongly
depends on the control system features.
Sl'l!CIFICSOFTWARE

CONFI•
GI/RATION

Figure 2. A general implementation scheme

VI. PROTOTYPES UNDER DEVEWPME.r-.'T
Three series of prototypes, using CAMAC technology,
have already been developed in the PS Complex and are
currently in operation. They concern the control of a dozen
current beam transfonners and their principles have alreadybeen reported [2]. These implementations have permitted
unambiguous verification of some of the control protocols
claimed advantages : in particular the large independence of thecontrols and specific developments and the software total cost
reduction after the fust implementation.
A new series of applications is now under development in
the new CERN common control system [7). This series

S19SP01
Standardization and Protocols

593

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-S19SP01

ETHERNET

c)

b)

a)

Figure 3. Actual implementation schemes
includes clusters of power converters and different types ofbeam instrumentation devices : the control protocol isimplemented in the front end part of the new control system,
called the DSC (Device Stub Controller) a VME crate using a
68030 as main processor and the LYNX RT-UNIX operating
system.
Figure 3 presents three possible schemes adapted todifferent needs of the users, and that we briefly recall :- Figure 3a represents the case of an equipment having all its
l/0 modules housed in the DSC : this configuration ismore specially, but not exclusively, intended for beam
instrumentation devices requiring intricate and complex
data treatments. The specific and the control software sharethe same processor and exchange standard messages.
In those cases where the equipment is composed of acluster of similar devices attached to a field bus (power
converters), the control protocol could be implemented asin Fig. 3b. The ECA's (Equipment Control Assembly)
represent different types of specific crates standards as G64,
VME, etc.
Figure 3c represents a variant of 3b, where the different
devices are not totally independent and require, still in thespecific software, a common control action.

VII. REFERENCES
[1)

[2]

[3]

[4]

[5]
[6)
[7]

R. Bailey, G. Baribaud et al. "Operational Protocol forcontrolling Accelerator Equipment" Int. Conf. on
Accelerator Controls, Vancouver, October 89.
G. Benincasa, L. Casalegno et al. "Implementation of acontrol protix:Ql in the instrumentation field", Int. Conf. on
Accelerator Controls, Vancouver, October 89.
WOPRO members, reported by G. Benincasa, "Generalities
on the operational control protocol", CERN-PS/CO Note 9101.
WOPRO members, reported by P. Burla, "Description
formelle des parametres et variables des convertisseurs depuissance pour la definition d'un protocole de controle",
CERN SL-PC Note 91-86.
WOPRO members, reported by P. Strubin. "Operational
protocol for vacuum systems", CERN AT-VA Note 91-06.
G. Baribaud, "Operational protocol for timing events",
CERN SL-BI Note 90-05.
The PS and SL Control Groups, "PS/SL controls
consolidation project", CERN PS-CO Note 91-09 and SL-CO
Note 91-12.

S19SP01
594

Standardization and Protocols

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

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 Publishing

Subrata Dasgupta of the Variable Energy Cyclotron Centre
in Calcutta, India, talked about a method of portraying all four
dimensions (x, x', y, and y') of the transverse beam phasespace on a single two-dimensional screen [5]. His method
used two-dimensional projections of suitably shaped threedimensional solids. It did not provide as complete information
as the usual ellipse representations, but did give a very
intuitive feeling for what the beam was doing. He
implemented these representations on an IBM PC.

George Shering of CERN gave an informal summary of
his view of the history of operator interfaces in accelerator
controls. He said that beginning with the early LAMPP
controls interface using Tektronics storage scopes, andcontinuing with the SPS controls at CERN, the accelerator
community led the man-machine interface field. He noted thatsince the introduction of the Macintosh desktop metaphor in1984 -- and now with Windows 3.0 for PCs -- the entire fieldhas been subsumed by WIMPs (windows, icons, menus, andpointers). As a result, we are now the users of man-machineinterfaces, not the designers.

doi:10.18429/JACoW-ICALEPCS1991-S20PD01

W. DISCUSSION

IV. CONCLUSIONSIn response to questions on control system security withproliferating consoles, Cahill said Fermilab handled suchproblems by limiting the capabilities of some consoles, byallowing the crew chiefs to observe all consoles, and bylogging changes as they are made to the control system.
Rusty Humphrey said that such security problems had neverbeen raised as an operational issue at SLAC. Several otherpeople indicated that control action logging was an effective
way to detennine cause and effect
Questions regarding the use of Motif in interface
construction were directed to Di Maio. He said they studied
possible user interface management systems (UIMs) anddecided that using the Motif interface was best He noted that
Motif was part of the environment already, and other products
could be expensive and have an unpredictable market lifetime.
Uli Raich commented that when using their knob widget themouse served only to connect, the up and down arrow keys
served to adjust
In discussions related to how to present and interact withinformation via man-machine interfaces, Michael CrowleyMilling mentioned that consoles designed 5 to 6 years ago did
not include keyboards, relying only on knobs, trackballs andtouch panels. Since then, perhaps because of the widely
accepted use of PCs and Macintoshs, keyboards have become
an expected part of a console.

Regarding user construction of interfaces, Crowley-Milling
pointed out that the NODAL interpreter at the CERN SPS
resulted in the proliferation of displays. (In one example, aship appeared on one SPS screen, sailed from screen to screen
across the control room, and finally sank on the last screen.)
Kevin Cahill said that with user expectations going up and the
MMI environment becoming more complex, users themselves
may not feel comfortable with building their own screens.
Rusty Humphrey of SLAC noted that operators can go"berserk" in creating an extremely large number of approaches
to screens. He said this trend is usually countered by senior
operators who lose patience and get rid of some of the variety.
The result can be a "relaxation oscillation" effect. Anotherconferee commented that he had success building prototypes incooperation with operators, relying on programmers to put
together the final production versions.

Two years after the Vancouver conference, similar topics
are still of concern in the international controls community.
More experience has been gained in the use of new interface
techniques such as X-Windows and Motif, but much remains
to be done. It should be very interesting to review MM!
progress again in two years in Berlin.
The dichotomy between what is presented in a manmachine interface and how it is presented continues to beevident. The importance of building on higher level (e.g.,
accelerator) metaphors was mentioned during the discussion.
While we recognize the importance of techniques forconstructing man-machine interfaces, we hope that futuresessions will place emphasis on the content of the interface as
well.

V. REFERENCES[l] B. Laurel, ed., The Art of Human-Computer Interface Design.
Apple Computer, Inc., Addison-Wesley, 1990.
[2] K. Cahill and J. Smedinghoff, "Exploiting the X-Window
Environment to Expand the Number, Reach, and Usefulness of
Fermilab Accelerator Control Consoles," these proceedings.
(3] P. Antonsanti, M. Arruat, J.M. Bouche, L. Cons, Y. Deloose
and F. Di Maio, "Workstations as Consoles in the CERN/PS
Complex: Setting-up the Environment," these proceedings.
[4] M. Mignacco, F. Potepan, G. Surace, "The ELETIRA ManMachine Interface," these proceedings.
[5] S. Dasgupta, D. Sarkar and C. Mallik, "Iconic Representationof Particle Beam Using Personal Computers," theseproceedings.

S20PD01
596

Panel Discussions596

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 Discussions598

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

ICALEPCS1991, Tsukuba, Japan- Shin-ichi Kurokawa (KEK) was working in the field ofcontrols from 1981 to 1987. Now chairman of a division
within the Accelerator Department, he is responsible for thecontrol system whilst also coordinating the future B factory
project. The controls group has IO to l S persons and islooking into rejuvenating the system with an eye on the
new controls for the B factory. As Japanese companies arevery eager to participate in physics project, such as the B
factory, the laboratories have developed a skill of
collaborating with industry.
- Rudolf Pose (JINRJLCTA) is Director of the Laboratory for
Computing and Automation of the Joint Institute for
Nuclear Research in Dubna, near Moscow. This laboratory
is responsible for all computing activities, including e.g.
network communication with the physics community
worldwide, and controls. It has a staff of approximately 650
people. Earlier this year (1991) a new heavy ion accelerator
project was decided and a small group of 12 people iscurrently looking into the controls of this new machine.
The group will endeavour to use as much as possible
existing commercial products, hardware and software.

ISSUES AGREED FOR DISCUSSION

Due to the limited time that is allocated to this panel, it is
impossible to discuss all management issues that werementioned in the introduction. It was therefore suggested to
select a reduced number of items which were felt to be rather
crucial in todays context. The participants agreed that thediscussions should focus the following issues:
Project:a key issue in today's project management is the dilemma of"Make vs. Buy": should we make it all in house or should
we buy from industry, and if so, what should we buy ? The
decision should be the result of a trade off analysis.
- Logistics:
laboratories are increasingly concerned with their control
systems rapidly becoming out of date because of the pace atwhich technology evolves. Increased processing power,
intelligent hardware, etc., provide opportunities to explore
novel, ever more sophisticated operational facilities which
are difficult to achieve with the existing system. This leads
to the second dilemma: "Should one upgrade the old systemor embark on an entirely new project" with its corollary of
having to maintenain the old system whilst implementing
the new one.

IV.

SYNTHESIS OF DISCUSSION

In the course of the debate, it appeared that the issue "makevs. buy" was raising a lot of interest: considering the time
allocated to this panel, it was thus agreed to extend thediscussion on this issue and to skip the one on "logistics".
- Make vs. Buy
Similar as for other technologies (e.g. magnets, vacuum,. ... ), it is felt that laboratories should develop a policyof market investigation for control systems also. Such amarket investigation should be based on specifications
resulting from a proper requirement analysis and design
study. This approach would allow the laboratories tobenefit from a competitive market by bidding for optimum
solutions. However, one re.cognizes that, although it is not
so difficult to write specifications and to buy off the shelf
individual components, writing a definitive and complete setof requirements and proper specifications for entire systems
so that they could be subcontracted, is a clifficult task. It isparticularly difficult to achieve in the experimental physics
community because of their lack of experience, ever moving
personnel, continuously changing ideas, etc. Accelerators
are never finished products: as soon as the accelerator iscommissioned, it becomes an R&D environment for which
the controls groups have to provide the proper support.
This may of course be a great challenge in itself, but is notparticularly propitiuous to defining control systems in
sufficient detail so that they can be bought outside. Also
the time scale on which the specifications have to be carriedout is in general very short and very transitory with regard
to the delivery schedule. Finally, the accelerator control
systems do not need to meet the same kind of severe
conditions as one would expect e.g. from controls of powerreactors, even if the regulatory agencies start to look at
accelerators in the same way as at reactors. All these
aspects are unfortunately not building up much motivation
to take up the chore of producing requirements andspecifications.

- Te.chnology:
technology is evolving steadily: methods and techniques are

The requirements should be written for a given applicationand not against a specific implementation: i.e. one should
endeavour to subcontracting the implementation of systems
or components to in-house designs, rather than buying off
the shelf products which do not quite meet the requirements.
A typical example of components that are difficult to findon the market are those which require specific and flexible
timing treatment. On the other hand, components that arereadily available on the market in general follow clifferent
standards which make it difficult for those products to work
together. Significant work then has to go into integratingthese components into the overall control system. Thus

S20PD03
Panel Discussions

599
599

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

coming up continuously whilst tools, e.g. computer aided
software engineering (CASE) tools, are invading the market.
They are intended to produce better quality systems and toassist the engineers throughout the lifecycle of their project:i.e. from the early analysis to maintenance. A study has
thus to be made to select the most appropriate ones for thetype of systems one is concerned with. In addition,
standards are emerging and control engineers have to face thedifficult choice as to which standards should be adopted.

responsible for software engineering in the accelerator
sector, he conducts a number of small pilot projects using
CASE technology for evaluation purposes. The number of
persons involved is approximately 25; they belong todifferent administrative entities and spend only a fraction of
their time on these evaluations: this imposes someconstraint on the project. In addition, the accelerator sector
has little experience with new way of working which breaks
quite significantly with the current habits.

III.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S20PD03

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

control system engineers have to evolve from designers tointegrators.
In case complete tum key systems are bought, one if left
with the problem of maintenance and upgrade: who willendorse these activities ? One should learn from theJapanese laboratories whose approach is indeed to havecomplete basic systems supplied by industry: i.e. thecomputers, the network, and the basic software,complemented by special maintenance contracts.
Application programs, however, are provided in house: thisis precisely an activity where tools would be of great help,
not only for their implementation but also for the
management of their implementation.
Industry on the other hand, may only be interested in
bidding if the volume of the deal is sufficiently large. Thisputs the larger laboratories in a more favourable condition
than the smaller ones. However, to date this is not a
general policy yet even in the large laboratories like e.g.
CERN, when compared with another large European
Organization such as the European Space Agency (ESA)
where such approach is part of their policy. This again
highlights the major difference between the European andJapanese accelerator laboratories: the latter have developed along experience of intimate collaboration with industry.
Similarly, though for different reasons, laboratories inSoviet Union are bound to buy on the soviet market.
Indeed, most of their budget is financed in rubles (70% of
their butget) which make it difficult for those laboratories tobuy from foreign countries. They thus must encourage thesoviet industry in applying international standards (e.g.
multibus II).

- Tools (CASE) and standards
Software engineering methods are emerging to assist thesoftware engineer in analysing, designing and implementing
large software packages. Most surprisingly, very little wassaid at this conference on the use of computer aided software
engineering (CASE) tools. Indeed, despite their promises
for better quality software and dramatic savings inmaintenance, this technology is not yet widely spread inexperimental physics laboratories as they tend to be inindustry. Without, however, overrating the effectiveness ofsoftware houses or other industries concerned with softwaredevelopment in their use of CASE tools, all tend to use
methods and tools as a rule. When someone joins thatindustry, he is instructed on the working practices anddisciplines of the house. In the laboratories, however,working habits are almost opposite to everyone doing
things his own way. However, one should consider that
CASE methods and tools have been primarily introduced forbusiness applications and that, as a consequence, there are
not many methods and tools available for real time control
applications. Among the many methodologies (structured
analysis· structured design, SASD, object orientation, etc.)
one needs to evaluate which are best suited for accelerator
and large experimental physics control systems. This is amost difficult task as the CASE market is still unstable.
New methods keep coming up at a pace that it is difficult tofollow: one has not adjusted to a method that yet anotherone is being advocated as a panacea. These tools which

complement these methods are produced by companies thatare in general as new as their products; they are in generalalso small and have it difficult to provide adequate support.
Tools are said to be too expensive for the laboratory's
budget. That argument runs into competition with theamount of manpower one has to invest in doing systems theold way. Here again it is a matter of evaluating the trade
offs between the cost of buying the tools, the effort toinvest in learning to use them, and the savings that can beobtained throughout the lifecycle of the control system, byusing these tools. It should also be noted that in generalvery favourable academic discounts can be obtained forlaboratories, so that even smaller laboratories could
probably financially afford such tools. It is however
recognized that they require a significant learning effort thatis often excessively high for small groups heavily involvedin every days activities. Regarding these cost considerations
it is significant to notice that software houses, that are
sensitive to cost and productivity, have a rather
unambiguous attittude towards the use of tools: in case themoney to be invested in tools competes with the cost ofpeople, software houses tend to prefer laying off people andto buy the tools.
The significant message one should extract from preceding
paragraphs is that one should at least have a method. The
example of the application software for the controls of the
CERN PS accelerator complex, gives an indication of thevalue of following a method. For that project, in the late70-ies, structured analysis and structured design was applied
extensively. At that time there were no automated tools
CASE available, and the SASD was carried out with paper
and pencil. However it allowed to breakdown the entire
software package in "small" modules which were eachcompletely specified so that they could be handed out toindividual programmers.
Shareable software is another issue that has a strong
economical impact. The appearance of object oriented(0.0.) design puts the idea of sharing software in a newlight. As an example, BNL designed the controls software
for the AGS booster with the use of object orientation. The
software was broken down in a number of classes (in the
0.0. sense) that were implemented separately. Classes
could probably be used elsewhere, provided they are designed
to be hardware independent.
A major step forward in the direction of sharing of software
for accelerator controls could be achieved if one could agree
on a standard model. This raises the problem of agreeing on
standards. Control systems are costly and can not bechanged frequently. They have a rather long life span andthe standards which are adopted have to be in effect forseveral years. In 1972, it was decided to go for a distributed
control system for the CERN SPS accelerator; only 20
years later, in 1992, a project is started of replacing thatsystem. In 1972 however a distributed architecture was not
so common and the choice that was made at that timemight have raised a mortgage on its life cycle.

S20PD03
600

Panel Discussions

600

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

ICALEPCS1991, Tsukuba, Japan

Still progress in the direction of standardization is steady.
At the International Conference on Accelerator and Large
Experimental Physics Control Systems in Vancouver(1989) there has been a lively debate around VMS versus
UNIX. Since then UNIX has won its spurs and a number ofcontrol systems are now based on UNIX. Also whenanalyzing the systems which were presented here, one
realizes that slowly these systems tends to converge to a
standard model and to the use of some common standards.
CONCLUSION

It is no surprise that the debates in this panel on"Management of Control System" had a strong economicalflavour: the economical climate which currently prevails inmost laboratories is a major concern for those involved intechnologies that are not directly tied to the laboratories
primary objectives, such as e.g. controls.

Laboratories should build up a habit of investigating in
how far their control systems could be assembled fromcomprehensive packages provided by industry. This would
allow them to benefit from a competitive market and to use
proven products. In case entire systems are subcontracted toindustry one should learn from the Japanese who also
subcontract the maintenance. However, laboratories firstshould learn to write comprehensive specifications: a task thatis particularly difficult in their ever changing experimental
environment. Along these lines, the appearance of computer
aided tools is an issue that is worth considering. Despite their"shakiness" and their high cost, that is often outweighed byvery favourable academic discounts awarded to non commercial
experimental physics laboratories, they are most valuable inproducing specifications very early in the project. If it only
were for that latter reason, laboratories should endeavour atentering the CASE era early and to grow together with thattechnology, .... or, at least, to adopt a method.
Sharing software is a dream that might become true in notso long a future. Among the new methodologies, object
orientation seem to be a most promising one in view ofpossible sharing of software. However this issue needs a
propitiuous environment of well established standards, andalthough standards are gradually settling, they mostly apply forthe higher level control layers. The device level still has along way to go and puts the designers in front of the difficult
problem to guess which are those that are likely to be stayvalid throughout the life cycle of the control system; .... westill are far from a standard model for experimental physics
controls.
Finally, as technology is evolving, one recognises a shift
in the activities of the control engineers. Using Sk'Uldards andbuying "off the shelf" products, infrom different
vendors, requires the control engineers to evolve fromto integrators who understand the art of ma.i;-.ing allthese pieces work together in an coherent overall frame.

S20PD03
Panel Discussions

601

601

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

The standards that exist today (Unix, X-Windows, Motif,etc.) are primarily of use for the high level control layers
where the operator interacts with the system. At the lower
end, i.e. near the devices, one sees a several real time Unix
operating systems emerging. They all try hard to maketheir way to IY'...coming a standard. However it is still not
clear how both "levels" can be tied together: e.g. what
process data highway communication protocol could westandardize upon ?

V.

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S20PD03

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S21CS01

mechanisms, start becoming increasingly significant pressure groups. Some of the recent newtechnologies are therefore only ta1dng on so rapidly since there exists a real need and because they
were presented with some simultaneous adoption of standards, which warrant some degree ofcontinuity and portability. Conversely, OS/2 (for example) has not made it since apparently there wasno direct need in the field where DOS was being used (no greater comfort, just new learning) andbecause there were no clear signs that there will be a standard. Tnere, where OS/2 could have made a
difference, UNIX was already ta1dng up the field and so one may say that OS/2 was too late,irrespective of its qualities which some people are praising.
But let us return to controls. In the accelerator world most controls people are still licking theirwounds from the recent Wild West situation in which they were married to all kinds products whose
manufacturers then either changed their mind or disappeared. We now try to start all over again andare attempting to extort money from our managements under all kind of pretexts and inventing allkind of euphemisms for the one simple message "scrap it all and build it anew". By the way, I see
with pleasure that the slogan "rejuvenation" has also caught on at KEK! I assure you, dear colleagues,that it is not by mere frivolity of just wanting to have the next gadget: we are far beyond that state ofmind. It is by the conviction that a new era has started in which we get really new value (meaninguser comfort) and really more guarantees (meaning economy). And this is the background of many of
the upgrades, revamps, rejuvenations and what have you, of which a number of interesting papers arereporting at this conference. And you may have understood, ladies and gentlemen, that with thesephrases I consider having done that part of my duty which is summarising the upgrades of thisconference. But this is just an introduction, as you may see.
Next come the large accelerator projects in statu nascendi like SSC, RHIC, HERA, lTNK and - let us
hope - LHC. Where shall they go? What will their choices be? It is interesting to speculate on the socalled trends on the basis of such more or less concrete projects. Some of them, like RHIC and LHC,
are somewhat constrained by their prehistory and previous investments (economics!). They then haveto choose between some continuity and homogeneity and more radical innovation. They mostprobably will try to steer a middle course but they will not really be able to resist the new things,
because of the long project times. Then there are SSC and UNK, who both start practically without
previous investments that need being safeguarded. Both are starting in a green pasture, in a certain
sense, and for a certain time. SSC is confronted with a plethora of possibilities and, at least atpresent. apparently matching resources. UNK depends to a large extent on the USSR industrial
mad:et, which is presently still narrow, but recently they organised some hard currency influ.x
through a collaboration \vith CERN. Both projects will suffer - for different reasons - from the very
long project times. Sticking to one technology will prove an illusion: in the time-span of around 10
years, technology may typically change once or even twice. What, then, should guide the controls
people in making their chokes, which ones are meaningful and which are not, how can they avoid
disaster, where shall they place their ambition, make their mark'! Again the only two usable guidelines will prove to be human nature and economy of resources.
Traditionally there exists what one used to call architectlli-e, a complex of problems on which, in the
recent past, numerous experts have hotly debated and written innumerable papers at conferences andotherwise. Recently - and, dear colleagues, here c-0mes my first controversial statement - architecture,in the conventional sense, is an issue that seems to be on its way out of the accelerator world. And weshould not be too sorry for that since, to be quite honest, architecture (with all respect for myarchitectural friends here) is not a main issue in itself but rather it used to be a constraint which kept
us from what it was really all meant for, that is controlling accelerators. It is my personal experience,
which has been con.finned by looking at other labs, that the investments in architecture - which I
admit were necessary in those times - have eaten up the larger fraction of the totally available
controls resources and the real accelerator controls wo:rk:, that which some of my friends dL«dainfully
call "only applications", came always too little and too late. It was as if we were constantly building a
piano which then kept us from really making music.
But fortunately it seems that we are on our way out of this vicious circle because of the enjoyable
fact that induStry, helped by the researchers in many places, are getting closer and closer to offering
complete turnkey computer networks in which a very diverse collection of computers, equipment andgadgets may t.e simply plugged in and which then can communicate with each other in a user

S21CS01
Conference Summary

603

603

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-S21CS01

friendly way. The technological intestines of the computers and networks are becoming more andmore invisible to the end user and even to the applications programmer. The higher end of the control
system starts more and more to become a black box with a number of user related and user
understandable functionalities. Although the investments in development of these products aregigantic and will remain so for some time to come, it will be the task of industries (and conceptually - universities) and it will seize to need our (the accelerator people's) development. It
will soon suffice to make a judicious choice of what building blocks to buy and then to do theintegration. Moreover, the recent and continuing efforts of standardising at all levels on protocols
and other interfacing conventions, makes that the plugged-in equipment and gadgets may beexchanged for newer versions, using entirely different internal technologies, which may then increase
their performance but without fundamentally changing their functionality. We may actually havereached something like a "standard model" today, but the point is that the model may even evolve
without wiping out our invesunents.
You may have noticed that at this point I think that I have dealt with architectural topology and with
netwoiking.
Of course some of you may remind me that I have not mentioned the new ideas of Rob Parker andothers at SSC (and, in a sense, of Steve Magyary at LBL), that is - naively speaking - mapping thewhole process address space in one huge memory of a huge and fast central computer and constantly
updating those data with a fast data pump straight from the front-end, through fast multiplexed
optical fiber links. Conceptually very simple, the only problem being technology. But let us not foolourselves, this is nothing new, this is bow it all began twenty years ago, this is where one starts
thinking in the first place and I vividly remember my first primitive thoughts when I was parachuted
into controls around 1975. At that time, that scheme was spoiled by the growing size of acceleratorsand the slowness of what bad to be reliable transmission (CAMAC and all that). That bad as aconsequence, the necessity of making an explicit choice of what data really had to be fetched to thecontrol room, since getting more than a very modest choice was simply not possible then. Today,with the new, overwhelming possibilities of data transfer, the simple "over-kill" scheme, mentioned
above, may again draw within reach, even for the largest size accelerators. Then, once all the data are- physically fresh - in a central memory (preferably even the last so many of them, in a rolling buffer,well labeled with their cycle number and time-stamp), then all you need is a central machine withenough parallelism and you can do almost anything you want. And conversely, one may act back on
the process globally with response times which will be vastly more "real time" than previously. But
again, no illusions, the fastest global feedbacks shall always be dedicated and bypassing the central
machine. In my mind there is no doubt that this scheme will now become technically feasible. The
question is only whether it will be economical and - above all - whether in the large accelerator (andother) developments projects, which spread over many years and involve many separate teams, thedistributed netwOiks are not more acceptable sociologically since they allow a more natural
decoupling between those teams, which in turn allows each team to proceed according to their own
style and woddng :rhythm (remember: "my car, my wife, my computer).
No doubt you will now start saying: Berend, since you are busy pooh-poohing all our cherished main
issues on which generations of accelerator controls engineers have made their careers, what then do
you consider a real issue? Well, one good example is certainly the man-machine interface. Not somuch the woikstations as such, which again may be bought from the shelf and plugged into the blackbox, but the way in which we are using them. It is certainly nice to have the windowing techniques
on our screen and possibly on remote screens, it is nice to have many windows and to shuffle them toand fro, to the foreground or otherwise, just like papers on our desks. But the analogy goes further:many of us are used to live with a mess on our desk and having panicky moments when looking forsomething in the geological strata (although there are favourable exceptions, I admit). The same is ofcourse possible on the woikstation screens, only those screens have a much smaller surface area,
which adds to the chaos. Nor is it attractive to constantly shift windows up and down and sideways,
to the foreground or to icons, when you are in a hot operational or machine experimental phase. In
the end, it is my firm belief, what we need and what cannot be replaced by windowing alone, issimply more square meters of screen and more pixels, so that a judicious choice of displays may beshown simultaneously without the need for interaction just to find the appropriate sheet. Rememberthat it is still infinitely simpler to flip your eyes from one screen to another than to take the mouse
S21CS01

604

604

Conference Summary

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S21CS01

and call another window. So here comes my second statement: we need vastly more pixels, notdeveloping ourselves but making the correct signs to industry, who '"'ill surely react sooner or later,
since that need is not specific to accelerator controls but to human nature.
But more pixels immediately confront us with the already marginal speed of these splendid new
devices. The beautiful and powerful graphics packages have vastly increased the quantity of data andcode which is being manipulated and thus even our present higher end workstations could easily
accept a factor of 10 improvement in throughput, \\-i.thout us becoming unduly spoiled But when one
aims, as I recommend, to a factor of between 10 and 100 more pixels, then it is fairly safe to say that
we are still looking for a factor of around 100 in throughput before the woikstations ...-vill really give
us all the comfort we can use. The recommended throughput is of course not proportional to pixels,
partlyalgorithmic tricks, but also partly since more parallel screens displayed make for lessmanipulation which latter would eat most of the resources. The process data displayedin
co1mpanso11, have more mc.dest :requirements by that tiine, even wt~n we permanently display achoice of r,;;frest>_ing oscillogr:ams coming up through the networks. Fine, you will say again, but all
thesedevelopments canlogically be done in industry. Where can we, the accelerator
controls engineers make our mark? Tile answer is: in the design and layout of the display andinteraction surfaces, essentially a
related to applications development, to which I shall return ina moment. It can be a fascinating
requiring knowledge of the system, of the accelerator
problem, of psycbology and above all
sense for proportions, i.e. common sense.
Now weto be on the subject of workstations, it occurs to me that some individuals at CERN
wage an intensive action, both technically and politically, with the doctrine that PCs and DOS be thepanacea for all controls matters. Let me say right away that I do not mean Alberto Pace, who isl."Jways rather balanced in his statements. ft-nd in fairness it must be said that, after 1'.iagya:ry's
pultJllc:aa.on at Vancouver, a recent
project at CERN, i.e. the contr<Jls for the experiment, ofwhich a paper is presented at this conference this morning, bas handsomely and verf convi.ncingly
confu-med
if one wants, th<-::m one can, in a number of contexts, conveniently use the
combination of PC - DOS - Novell - Some commercial applications - PC-I/0-cru:ds. Earlier in mis
session Magyary filled us in about the present status of his system. I bope you have managed toattend: "Cela meritaitait le detour", as the Guide Michelin would say. But since the polemic pet"Sists
and seems to keep ooth controls people and management at CERN off balance, it may be worth whiledwellil::lg a few moments on the subject. The question is whether this "PC versus Woikstations" is areal
or even, whether using PC & DOS all-over-the-place is a breakthrough in Western
thinklng... Let us see ...
The arguments fielded in favour of
PCs all over the place, for the next generation of control
systems, a..re more or less the(l) there is a plethora ofquality commercial
software ~ith good docmnentation...offered by many
according to one
staJnd<lTd... and, in some cases, v.i.th
mutual integration; (2) PCs are cheap, since they are mass
pnXlt:!OOCt ••. and there are many vendors for the same standard (conveniently forgetting the EisaJ\.1icrochannel dichotomy!)... (3) there are excellent networking products likebut also othervu•c;,;:>, .•• \~,, there is a large collection of tJl sorts of plug-in cards for Input/Output and other purposes,
different vendors.
using PCs for all controls allows office work andae•ve1op1111ents on accelerator controls to be done from the offices on one and the same station. All
this constitutes the kit of building blocs which - remember what I said before - makes the issue ofarchitecture redundant for accelerator controls people. One just makes the choice ofwbat to buy, thenit all together, installs the commercial applications a...nd - bingo - starts controlling.
Now that looks all fine! There are, however, also other argument to be made:(1) The plethora of commercial software products mentioned are all running under MS-DOS, a single
user operating system. For the more sophisticated networking in larger accelerator projects, however,multl
operating systems are a must... and in that case why not lJNIX, or the like? ....Moreover,
the advantage of this wide choice of applications should not be overstated, because only a minutesubsetspreadsheet and one or two others} is of any practical potential use in accelerator
controls ... and, even so, recently the business world (who were traditionally DOS oriented) havestarted discovering Uh1IX (which previously was a hobby of universities and science freaks), so thel.JNIX ma.Iket is now in accelerated expansion and I.he same software houses as referred to above are

S21CS01
Conference Summary

605

605

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-S21CS01

now porting their products (like Lotus 1-2-3, Wingz, Mathematica, etc .. ) to UNIX. Although thedifference in number (all counted) is still great at the moment, the difference in available number forthe accelerator controls-relevant candidates is modest and shrinking.
(2) It is true that PCs are cheap..• .if one takes the cheap ones. In this comparison, the PCs should becompared with the combination of workstations at the top and, say, VME based front.end processois.
Taking the workstation level first. we may immediately observe that, when we compare equal things,
meaning equal processing power and equal monitor screeas, or, in other words, high end PCs withmedium workstations, then the differences in price are not great and one should also state that today
the monitor tends to be the larger part of the cost of the total package, hence by definition equal pricefor equal performance. Moreover the tendency is converging, as Alberto showed this morning:

TRENDS for PCs and WORKSTATIONSPERFORMANCE
improving for both

PRICE
droppinn fOJ both

~=~

·!·

:::

:::

;;~

:::

wsslllwssll:

~~~

•!·

~;~

~~

overlap

zone

;;~

~;i

:::

·.·
movement

relative ·lrelativemovement

.·.

PCs

PCs

At the front.end level, it is true that one PC crate is cheaper than one VME crate, but, by the time onebas industrial quality and made the calculation per slot (a PC bas 5 and a VME crate has 21), thedifference is dwindling... and the individual Input/Output boards typically (now still unequal in price)
will be converging further for similar functionality, simply by the component count and square meter
price•.•there are no miracles at this level.
(3) No problems for networking between workstations and VMB crates, the TCP/IP possibilities, with
software and all, are commercially available and in future one my migrate to ISO standards and otherdevelopments, when these will become a practical reality, and all that is likely to stay entirelytransparent to the user.
(4) The choice of functionalities for VMB cards is already by now comparable to that for PCs (andgrowing fast), since from the start the industries became interested in it for their automation projects
and the PC has only invaded that field coming from administration.
Frnally, (5) it is now perfectly possible to call an X-window under MS-Windows on a PC screen in an
office and to work on it.
So, in order to cut a long story short: the signs are that the two worlds, the PCs, on the one hand, andthe combination of Workstations with VMB, on the other hand, are converging and that the "PCversus Workstation" issue is a non-issue ... .it bas been overtaken by the evolution of the market. Thereis of course nothing against the PC in the appropriate context (with DOS or with UNIX), but there
exist no plausible arguments to use only PCs.
Now, after this frivolous interlude, let me gently move to where I think the real issues will be in thenear future. It is my feeling that it will be in two broad areas: (1) one is the so-called front.end, theembedded eqnipment controllers (far front.end) and their connection to the upper layers (FECs) andS21CS01
606

Conference Summary
606

ICALEPCS1991, Tsukuba, Japan

JACoW Publishingdoi:10.18429/JACoW-ICALEPCS1991-S21CS01

the face these present to the applications and to the operator. (2) The second area is the applications
software, in a broader sense.

Let us start looking at the front-end first Ia our sort of organisations, it is more and more thetendency that the embedded intelligence is not the responsibility of the controls group and - ifanything - this tendency becomes stronger. There is also some logic in that situation since there is astronger binding between that intelligence and the device (say a power supply or beam transformer)
than there is, or should be, between the control system and that local intelligence. Moreover,interfering there by the controls group would also be inefficient by the mere numbers in question (atleast in the larger installations), and by the tendency of that local intelligence to grow into more orless autonomous subsystems which - in addition to their operations-oriented functionality - have an
intricate internal life which is jealously guarded, and may just about be managed, by a good numberof dedicated groups, each with their own electronics wizards. Thus we must henceforth resign
ourselves to the idea and the fact that internal life escapes our (the controls people's) detailed
undemtanding and control.
But we are well advised to take appropriate measures to safeguard the upper part of the control
system from importing the intricacies and diversities of the far front-end, because these imports
would constantly require adaptations and patches over patches, which in the end will make thesystem non-understandable hence unreliable. Even when not explicitly imported, these intricacies
tend, over the years, to diffuse upwards, mostly under the pressure of an urgently needed
functionality which would otherwise be much more complicated to implement. How then can we
safeguard ourselves against these imports? Well, the old methods of agreed boundary conditions(today called "protocols") between the two domains are still as valid and as effective as ever,provided that both parties honestly use the agreed boundary conditions only and do not "hack" into
the other domain. When sticking to such a discipline, both parties may arrange their internal lives
more or less as they want, at least if this defensive aspect were the only one.
With somewhat more ambition, one may speculate about interchangeability of devices of the same
category, without the need of changing the software above the boundary. That requires, in addition,
the standardisation of the functionality of devices inside the categories.

And the ultimate speculation may be of connecting every process device through a standardised plugat any point into the control system which latter then interrogates the device and, if it is recognised(meaning that it exists in the control system's data base), configures itself accordingly and initiates
the de'l-ice. This needs standardisation at the electrical and connector level as well (and a few otherthings, of course).
Now the first level, the level of defense, has been reached long ago in hardware and there, where
only hardware was concerned, the result was always quite good But since devices today are a
combination of hardware and software, the possibility, hence temptation, of cheating is much bigger
and therefore the danger of the upward diffusion, mentioned above, is a real one. It can only becontained by human discipline, unless one squeezes the physical connectivity down to an unpracticallevel.
When pursuing the second ambition, the one of hardware interchangeability and at least partial
applications portability, one must join the present endeavours around the so-called controls protocol,
which was the object of the workshop this morning. This work uses the fact that an accelerator
consists of only a small number of categories of process devices and that, within each category, there
is a strong similitude of those functionalities which are relevant for operations (as opposed to pureengineering and service functionalities, which depend on implementation, i.e. technology and thetaste of the device engineer). With some goodwill on behalf of the device engineers, these
operations-relevant functionalities may be made to confonn to one model. This means that the
behavioural model of the device can be standardised and consequently also the software interface
towards the applications programs and the appearance to the operators on the consoles. This in tum
allows conserving the applications software when devices are interchanged for versions implemented
in different technology. It would also allow moving devices between accelerators and also porting

S21CS01
Conference Summary

607

607

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-S21CS01

parts of applications from one accelerator to the other, but that is a bit more complicated and I shallcome to that a bit later.
This protocols work has long suffered from conceptual and semantic misunderstandings between theparties and of laboratory-specific political difficulties, but it is now starting to make some progressinside CERN since it has finally received managerial support. But the issue is presently far fromexhausted and substantial work must still be invested, including conceptual work, and it must be
supported by examples of implementation, before this chapter will have reached maturity and thus
the economy will start paying off the initial investments.

At the far front-end, there has since years been a hesitating, but now probably accelerating,penetration of industrial Programmed Logic Controllers, so-called PLCs, in particular for the moreindustrial like support services, like power, cooling water, gases, radiation protection and access
control, who previously were not always integrated with the accelerator controls. It is not excluded(and there are examples) that these techniques will also diffuse into things like power supplies andvacuum, but less likely into beam instrumentation. These PLC devices come in a kit which allows
configuring a range of controls functions and allows simplified applications development with aminimum of conventional coding. The material is robust and reliable and often comes with the fitting
patch panel material which allows organised interfacing to the sensors and actuators in the field
Although dubbed "expensive" for many years by the accelerator controls community, there is thedawning realisation in the laboratories that, all things counted, they may in the end be cheaper thanthe home built controls at that level. Now it should be clear that the influx of all this new technology
does not change human nature, and thus the specialised groups, will - even with such a kit - keep
building their own subsystems with all the required local diagnostics and with some measure of standalone capacity. So what I said a bit earlier about the need of well defined boundary conditions islikely to remain for some time to come, since that is hugely a consequence of human nature.
Coming now to applications, it is not too surprising that, since in the past so much energy went intocreating the architecture, that the applications software was always too little and too late. The causesof this were, first, the necessity to create the architecture before applications could start, secondly,that the management was not wanting to see the real cost of controls, and, last but not least, therelative programmer-unfriendliness of the system, i.e. unfriendly already for the professionals andconsequently so much more so for the uninitiated operators, equipment engineers and accelerator
physicists.
Although there is considerable progress since then in the basic environment and tools for program
development, meaning operating systems, compilers, debuggers etc., the problem of applications
development is still as severe as before since in the meantime also the user expectations have grownin step with the sophistication of the market and so one may confidently say that for any of the large
accelerator controls projects, mentioned earlier, an effort of the order of 100 man*years is required
for an applications package which is supposed to give some real comfort. This canonical value seems
to be invariant in any transformation. Over the life cycle of the system this is considerably more. Not
yet included in this are the various accompanying upgrades and rejuvenations which, depending on
their ambitions, may add large fractions of the mentioned effort to the bill. At this point I am
therefore already speaking about the order of 500 - 1000 man*years due in this decade, for theworld's five largest accelerator centres alone. If now we also include the world's medium and small
accelerators, then we may, again conservatively, triple the bill to say 2000 - 3000 man*years, so 200- 300 'Million SF or, if software houses are involved, 0.6 to 1 Billion SF. Now, try to mix into theargument the still growing level of user expectations, which is nurtured by the beautiful applications(in non-accelerator topics !), available for little money on the PC-DOS vehicle, and then there seems
to be no end to that game, say 1 to 2 BSF or, to quote a nice round figure, 1 BUS$ for the decade.
Having arrived at this point one may ask the question: is there any analogy with the topic ofarchitecture as discussed previously, is there any hope that in the next five years or so the industrial
software products move equally massively into the field of applications creation, I mean applications
which are relevant for the more sophisticated accelerator control?

S21CS01
608

Conference Summary608

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Obviously the answer must be at least partially yes ..but let us see .. There are three categories ofapplications software which are relevant: ... Fmt, there is a number of generic applications software
packages, developed for conventional process control (say chemical plants), which are alreadysuccessfully being used for controlling utilities, general services and even vacuum. Second, there
exist a number of generic applications packages, which actually grew out of the accelerator field, andtherefore may be called more or less accelerator oriented. Examples include: the Vsystem, the EPICS
system, equally born at Los Alamos, and the CEBAF system. And then, at this conference Le Goff
presented bis interesting ideas about a generic control system for large physics detectors, of which I
have the sneaking suspicion that it may well be adaptable and extensible to the accelerator field
proper... Finally, there is Rol Johnson at Maxwell Brobeck, proposing to sell the physicalapplications of Fermilab (in a manner he will no doubt divulge in due course). Third, there are a few
commercial programs which have not been made for that purpose but which may be used foraccelerator control, in cenain contexts. Examples are spreadsheets like Lotus 1-2-3, Mathematica andothers, available under DOS and under UNIX.
So far so good, the industrial packages can do a good part of the job and, with some goodwill, theirrange of reasonable usabilty in accelerators may be somewhat extended. The programs originatingfrom the accelerator laboratories obviously go a longer way towards our needs, but they seem not yet
to be covering the field for the larger installations and more sophisticated applications. Programs ofthe third category often do not have the handles by which they may be easily connected to the control
system, although, with some effort, it may be possible and often worth while. Programs of all three
categories each cover a certain field and the ranges are to a certain degree overlapping. But dataexchanges between them are in the best case aw1."Ward, which means that they lack integration. Once
I have pronounced that word, let it be said loud and clearly that what we really need in the end is aof integration like in the Macintosh. And then the question, which I asked previously, may bereformulated as follows: is there any hope that industry will, within the next few years, provide us
with the packages which are accelerator oriented and highly integrated, like they are in the
Macintosh?
And to that question my answer would be: not jolly likely! And I think that there are several reasons.
FU'Stly, the mark.et is too narrow for them to deploy the huge efforts which have, for example, been
the pre-requisites for the really nice and powerful software under PC-DOS. By huge efforts I mean
the sum of several competing firms. Remember that the high quality was rarely achieved by the firstmanufacturer. For example, of the leading spreadsheets MS-Excel is the third and Borland's Quattro
the fourth. And then there is of couISe no chance at all that industry develop our specific applications
for each individual operation (unless at cost plus basis). At best they would offer us tools and a few
selected generic packages, on condition that these stay close enough to the needs of the much larger
industrial mark.et. The second reason is that, in order to achieve a good coverage and relevance andquality, a large enough number of practicing accelerator people must be involved in the relevant
industrial firms .... and that is not the case.
We can then do either of two things: either we resign ourselves to the situation as it is, which meansthat wemuddling on with a mixture of what the mark.et delivers today and knit it all together
the best we can, accepting the limitations and frustrations, or we take the bull by the horns and try tohelp in the good direction. But how could we do so?
Well, first an foremost we must specify what we need Now some people tell me that every new
accelerator is different, so we cannot specify controls for a future accelerator. But we have seen that a
lot of functionalities, mostly those which support the specific applications, do recur in every new
accelerator in some flavour or other. There are now plenty instances to prove that point. By now thatcollection is called the applications environment and there are people (including me) who suspectthat these program codes may be made generic and thus accelerator independent, but configurable fora range of individual accelerators. Examples of the software functionalities in the applications
environment are cited in the right-hand column of the picture on the opposite page. It is from Nikolai
Trofimov's talk.

S21CS01
Conference Summary

609

609

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-S21CS01

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

The UNK Control System

Specific Applications and Application Environment

g

USER

UIDS I UIMSSESSION
MANAGERSPECIFIC APPLICATIONSMODELLING
PROGRAMS- SUPERCYCLE PROGRAMMING- MAIN POWER SUPPLIES- RF SYSTEM- ORBIT MEASUREMENT- ORBIT CORRECTION- BETATRON TUNE MEASUREMENT- CHROMATICITY MEASUREMENT- BETATRON TUNE CORRECTION- CHROMATIC ITV CORRECTION- OCTUPOL CORRECTION- INJECTION CONTROL- RF SYSTEM CONTROL- VACUUM SYSTEM CONTROL- CRYGENIC COMPLEX CONTROL- BEAM ABORT SYSTEM CONTROL- PERSONNEL ACCESS CONTROL- UTILITIES CONTROLDATA BASE
ACCESSALARM
PROCESSOREQUIPMENTACCESSEQUIPMENTS21CS01
610

610

Conference Summary

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

ICALEPCS1991, Tsukuba, Japan

JACoW Publishing

Note that the practical implementation of such a scheme will meet fewer technical baniers today thana few years ago, through the present trend for convergence of the architectures (Standard Model). But
it is essential that this specification be done by the leading accelerator laboratories together, forseveral reasons. The first reason is coverage and relevance (maximum input of different requirements
and experience). The second is political acceptance (those who participate tend to accept). The thirdis economy: only when a sufficient number of laboratories agree on these specifications, will the sizeof the market be large enough and will one be able to afford the price; conversely, only when thesame product can be sold to a number of the bigger clients, may it be attractive enough for industry
to produce it. Obviously we will never reach the price levels of Borland's Turbo Pascal at US$ 99,95
per licence, but after a few years our software bill will be vastly cheaper than it is today. And we will
gain other advantages, like time to concentrate on real accelerator control problems, in contrast to
spending our time on coding the same functionalities over and over again in different, incompatible
flavours.
Such a collaboration could have a number of positive spin-offs. First, we are obliged to compare
notes in some depth and not only by presenting each other our brilliant solutions during conferences.
Second and related, the quality of the product will in general be better (if we can avoid the camel
which, remember.. .is a horse designed by a committee). If, on the basis of these common
specifications, the bigger laboratories together issue a call for tenders and negotiate a common
contract, then, third, we may profit from a joint software maintenance organisation and, fourth, we
may at long last get good updated documentation. Fifth, many smaller labs will then certainly join,
which will stabilise the setup and improve the service. And so on...Altematively the labs may set up a
consortium of their own, but the industrial version seems to be the wiser one.
Even if we do not in the end make a common contract, the common specification exercise will be ahighly interesting and rewarding one. All parties will be corning out enriched For one thing it will
become clearer what are the essentials and what is "couleur locale". I would therefore propose to
make an exploratory workshop, sornewhen not too late in the next year (1992!), involving around 20
or so people with experience in operation, machine physics and controls, with the aim of exploring
what common ground there be ....
I shall stop my speculations at this point, but you now see why it is my feeling that there will always
be an interesting job in the applications (even if we keep muddling on like we do today), mostcertainly in the specific ones and then there will be a very challenging one in specifying, developing,
updating, adapting and extending the mentioned generic software concerning the applications
software environment..
Ladies and gentlemen, coming to the end of my long palaver, I wonder whether, by all those words,
you may have lost the thread of be argument I am trying to make. Summarised in a few short phrases
it goes as follows. A number of issues, hitherto main fields of our endeavours, which have been at thecenter of our attention and consumed most of our resources, will henceforth be industry driven andnot any more our - the accelerator controls people's - field any more. That field, a bit broadly andhand-wavingly, may be called architecture; If you want to stay in that field, then go to industry: a lotof the advanced work will be done there. The two fields where - in my opinion -. the accelerator
people will now have to concentrate their attention, where they can still be creative, where they still
can make their malk, - and where they are really indispensable I - are: first, at the front-end, inparticular its connection to the henceforth industry-supplied upper architecture, and, second, - ofcourse - the wide field of applications. But, in order to deal successfully with either or both thesefields, the controls people must become much more interested in the accelerator proper (or telescope,or tokamak, ... ) and that is not a bad thing. Not bad, since in this way we have moved a bit closer towhat we are being paid for in the first place: that is controlling accelerators.
Thank you for your patience!

S21CS01
Conference Summary

611
611

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-S21CS01

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991

List of Authors
Bold papercodes indicate primary authors; strike through/black papercodes indicate no submission received—A—
Abe, I.

,,,S02SRU09 S08NC08 S17AIA01
S17AIA02

Adachi, T.
Agababian, A.
Agueev, A.I.
Aimar, A.
Ajima, Y.
Akasaka, H.
Akiyama, A.
Albrecht, A.
Alferov, V.
Allen, M.E.
Allison, S.
Anderson, J.B.
Anderson, M.D.
Antonsanti, P.
Aoki, K.
Aoyagi, T.
Arakawa, D.A.
Araki, S.
Arnold, N.D.
Arruat, M.
Asami, K.
Azumaishi, R.

S11LLC08
S04SRS04
S04SRS04,

List of Authors

S05SRN10
S08NC07
S19SP01
S19SP01
S08NC03,

S01SRA02 S02SRU01
S20PD03

S07IC02 S13MMI08—C—

S11LLC08
S12FC08,,

S02SRU08 S04SRS08 S08NC09
S15CSE01,

S03SRD08 S04SRS04
S14OOP03,

S12FC02 S12FC03
S03SRD04
S03SRD04
S13MMI01
S02SRU10
S12FC09
S11LLC07
S10TS04
S03SRD04,

S13MMI01 S18BPA03
S03SRD14
S03SRD14—B—
Bailey, R.
Baribaud, G.
Barillère, R.
Barnett, I.
Barton, C.J.
Barton, D.S.
Bassato, G.
Battistella, A.
Baumann, R.
Beetham, C.G.
Bellato, M.A.
Benincasa, G.P.
Bérard, G.
Berrig, O.E.
Billinge, R.
Björklund, E.
Bouche, J.M.
Bourianoff, G.
Boutheon, M.
Bragin, S.
Bret, A.
Bretin, J.-L.
Briegel, C.I.
Brook, V.L.
Brownless, D.M.
Brun, R.

Bulan, V.V.
Bulfone, D.
Burla, P.
Burns, A.J.
Burns, M.J.
Burns, M.J.
Busse, W.

S01SRA01
S19SP01
S06SA02
S19SP01
S02SRU05
S20PD03
S01SRA06
S01SRA06
S01SRA05,

S08NC05 S10TS05
S01SRA06
S19SP01
S07IC02
S19SP01
S04SRS02,

S01SRA02 S02SRU01
S13MMI01

Cabas-Alonso, A.
Caccia, B.
Cahill, K.
Callaway, T.
Canella, S.
Cappi, R.
Carlier, E.
Carr, G.P.
Cavallari, G.
Cha, B.-C.K.
Chang, S.-S.
Chapman-Hatchett, A.
Chase, B.E.
Chen, C.J.
Chen, J.
Cheng, H.J.
Chepurnov, A.S.
Chevrier, F.
Chew, A.C.
Chikovsky, V.M.
Chin, M.J.
Chohan, V.
Choi, S.J.
Christiansen, M.
Chu, Z.S.
Chuang, C.Z.
Ciapala, E.
Clark, S.
Clausen, M.R.
Clout, P.N.
Coffman, L.
Cohen, S.
Cons, L.
Cork, C.W.
Coudert, G.
Cuttone, G.

S15CSE01
S03SRD06
S13MMI05,

S01SRA02 S02SRU01S01SRA06
S19SP01,

S07IC02 S13MMI08,S01SRA02 S02SRU01S04SRS01
S03SRD04,

S03SRD11 S10TS02
S18BPA02
S12FC01
S03SRD10
S03SRD10
S04SRS06,

S03SRD09 S12FC04
S15CSE01
S10TS06
S05SRN10
S01SRA03,

S13MMI03 S18BPA02
S10TS02
S14OOP03
S01SRA11
S04SRS06
S04SRS01,

S12FC03 S13MMI13
S13MMI07,,

S07IC05 S08NC10 S20PD02
S20PD03,,,

S01SRA02 S02SRU01 S11LLC06
S13MMI01 S18BPA03
S16MS02
S19SP01
S03SRD07

S18BPA01,

S13MMI02 S18BPA03
S11LLC05
S04SRS02
S07IC02,

S08NC02 S20PD02
S03SRD08
S02SRU05
S19SP01—D—
Daems, G.
Dale, D.
Dalesio, L.R.
Daly, R.T.
Daneels, A.
Dante, V.
Dasgupta, S.

S10TS05
S11LLC09,

S07IC03 S13MMI06
S03SRD04,

S15CSE01 S20PD03
S03SRD06
S13MMI14

613

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991David, L.
de Metz-Noblat, N.
Defendini, A.
Dehavay, C.G.A.
Delamare, Ch.
Deloose, I.
Deloose, Y.
Desforges, B.
Di Maio, F.
Di Pirro, G.
Dieperink, J.
Dohan, D.
Dudorova, E.I.
Dunaitsev, A.F.
DuPlantis, D.
—E—
Edamenko, N.S.
Ekimov, A.
Endo, M.
Endou, A.
Engström, M.
Ermolin, Yu.
Esin, S.K.
—F—
Fahmie, M.P.
Ferran, G.
Filipchicov, L.L.
Flor, G.
Foffano, S.
Franck, A.R.
Frolov, I.
Furukawa, K.
Futagawa, N.
—G—
Gagnaire, A.G.
Gajewski, K.J.
Gavaggio, R.
Geib, M.
Gelato, G.
Giove, D.
Goloborodko, S.G.
Goodwin, R.W.
Götz, A.
Gribov, I.V.
Gridassov, V.I.
Grillo, A.A.
Gromme, T.
Guertsev, K.F.
Gueugnon, D.
Gunderson, G.R.
Gurd, D.P.
Gussak, A.A.
—H—
Haenni, D.J.
Hanashima, S.
614

S02SRU04
S11LLC01S14OOP06
S19SP01
S15CSE01

,
,

,

,

,

S04SRS02 S13MMI03 S18BPA02
S13MMI01 S18BPA03
S19SP01
S13MMI01 S13MMI02 S18BPA03
S03SRD06
S07IC02
S08NC04
S05SRN10,

S03SRD08 S04SRS04
S11LLC09

S16MS05
S05SRN09
S04SRS10
S17AIA04
S04SRS03
S05SRN09
S10TS03

S01SRA03
S15CSE01
S10TS03
S10TS07
S15CSE01
S02SRU11
S08NC11,

S02SRU09 S08NC08
S10TS08

S11LLC01
S02SRU06
S19SP01
S08NC10S19SP01,

S03SRD07 S05SRN01S03SRD08

Harrington, M.
Heinze, W.
Hendricks, B.
Hendrickson, L.
Heubers, W.
Heymans, P.
Hill, J.O.
Himel, T.M.
Himeno, Y.
Hiramatsu, S.
Hirao, Y.
Hoh, R.
Holt, J.A.
Horie, K.
Huang, H.
Huang, J.
Huang, J.Y.
Huang, T.H.
Humphrey, J.
Hunt, S.M.
Hutchinson, D.A.W.

,

S01SRA02 S02SRU01
S11LLC04
S06SA01,S12FC02 S13MMI13
S09DPP02
S15CSE01
S13MMI06
S12FC02
S17AIA04
S11LLC07,

S03SRD14 S12FC07
S18BPA03
S11LLC07
S09DPP01
S04SRS06
S03SRD11
S12FC05
S01SRA11
S01SRA04
S03SRD02
S12FC03—I—
Ieiri, M.
Ilinsky, N.G.
Iselin, F.C.
Ishida, T.
Ishihara, K.
Ishihara, N.
Ishii, H.
Ishii, K.
Itano, A.I.
Itoh, Y.I.
Ivanov, Yu.S.
Iwashita, H.
Izgarshev, S.V.

S04SRS09
S11LLC05
S16MS03,

S04SRS08 S11LLC08
S12FC06
S12FC06
S04SRS09
S08NC09,

S03SRD14 S12FC07
S03SRD13
S10TS03
S05SRN05
S03SRD08—J—
Jan, G.J.
Jiao, T.S.
Johansson, O.
Jones, R.
Joshel, R.H.

S03SRD10
S01SRA11
S02SRU06
S14OOP06
S06SA01—K—

S08NC01
S14OOP04,

S03SRD09 S12FC04
S04SRS04
S12FC03,

S12FC02 S12FC03
S04SRS04
S18BPA03
S03SRD04
S20PD02
S04SRS04

S07IC04
S09DPP01

Kabanov, V.S.
Kadokura, E.
Kakihara, K.
Kamikubota, N.
Kanai, T.
Kanaya, N.
Kanazawa, M.
Kaneko, H.
Kang, H.
Kanzawa, T.
Kapps, E.
Kargaltsev, V.
Karonis, N.T.

S16MS05,,

S04SRS08 S08NC09 S11LLC08
S11LLC02,

S02SRU09 S08NC08
S04SRS10S20PD02,,

S03SRD14 S12FC07
S05SRN07 S05SRN08S12FC03
S05SRN05
S01SRA05
S11LLC10
S03SRD04

List of Authors

Kartashev, A.V.
Katayama, T.
Kato, Y.
Katoh, T.
Kawachi, K.
Kawakubo, T.
Kawamata, Y.
Kawamoto, T.
Kawashima, S.
Kazarian, A.
Kazarian, A.
Kerr, J.C.
Kerstiens, D.M.
Khoetsian, H.
Khoetsian, N.
Kim, J.-H.
Kim, M.S.
Kimura, T.
Kirn, J.H.
Kishiro, J.
Kissler, K.H.
Kitamura, M.
Klotz, W.D.
Knaebel, R.
Knott, M.J.
Kohler, K.
Kohno, T.
Komada, K.
Komarov, V.V.
Konovalov, V.A.
Kotov, V.M.
Kozubal, A.J.
Kraimer, M.R.
Krause, U.
Krauter, K.E.
Krendelev, V.
Kubicek, D.
Kubota, T.
Kucera, M.J.
Kudoh, K.
Kuhn, H.-K.
Kuiper, B.
Kumahara, T.
Kuper, E.A.
Kurihara, K.
Kurokawa, S.-I.

S05SRN10
S02SRU10
S04SRS09
S08NC09
S04SRS10,S04SRS08 S11LLC08
S12FC08,

S02SRU08 S10TS04
S10TS08
S04SRS05
S04SRS04
S02SRU05
S13MMI06
S04SRS04
S04SRS05
S12FC05
S10TS02,

S05SRN06 S12FC08
S03SRD11
S11LLC07,

S02SRU03 S03SRD01
S17AIA02,

S03SRD05 S14OOP04
S01SRA05
S03SRD04
S08NC05,

S03SRD14 S04SRS10S02SRU08
S03SRD08
S10TS03
S01SRA12,

S07IC03 S15CSE02,

S03SRD04 S07IC03
S01SRA07
S12FC02
S04SRS04,

S01SRA02 S02SRU01S12FC06
S08NC01
S02SRU08
S19SP01,,
S11LLC03, S11LLC10
S03SRD08 S21CS01

S03SRD13 S03SRD12S12FC08,

S02SRU08 S20PD03—L—
Lackey, S.L.
Laffin, M.
Lancaster, H.
Le Goff, J.-M.
Lécorché, E.
Ledenev, A.
Lee, J.
Lee, J.-W.
Lee, J.W.

List of Authors

S02SRU11
S07IC02
S01SRA03
S06SA02
S02SRU04
S11LLC03
S03SRD11
S12FC05
S03SRD11

Lee, M.J.
Lee, S.
Lenkszus, F.
Lewis, J.H.
Li, T.Y.
Lin, Q.
Liu, D.K.
Liu, S.-Y.
Liu, Y.
Lomoro, R.
Low, K.
Lu, P.
Lucas, P.W.
Ludgate, G.A.
Lukyantsev, A.
Luong, T.T.
Lusin, Yu.N.
Lutz, J.R.

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
S17AIA03
S10TS06
S03SRD04
S10TS05
S01SRA11
S04SRS06,

S04SRS06 S13MMI12S02SRU07
S05SRN11
S03SRD06
S03SRD02
S04SRS06
S20PD02,,

S14OOP02 S14OOP05
S03SRD08 S04SRS04
S02SRU04
S05SRN10
S01SRA05—M—
Ma, S.
Magyary, S.
Mallik, C.
Manduchi, G.
Manglunki, D.
Mannix, R.P.
Marsaudon, J.C.
Marti, Y.
Martini, M.
Martlew, B.G.
Martou, J.L.
Masuda, T.
Matevosian, A.
Matheys, J.P.
Matsumoto, S.
Matsuzaki, Y.
Matveev, M.
McCarthy, M.
McDowell, W.P.
Mertens, V.
Meyer, J.M.
Michelini, P.
Mignacco, M.
Mikawa, K.
Mikheev, M.S.
Miki, T.
Milardi, C.
Milcent, H.
Millsom, D.
Mimashi, T.
Minakawa, M.
Minohara, S.
Missiaen, D.P.
Molinari, P.
Moorhead, G.
Morii, Y.
Morita, K.I.

S01SRA11
S01SRA03
S13MMI14
S10TS07
S15CSE01
S02SRU05
S01SRA05
S15CSE01
S18BPA03
S01SRA08
S06SA05
S03SRD12
S04SRS04,

S14OOP06 S15CSE01
S04SRS07
S12FC09
S05SRN09
S01SRA08
S03SRD04,

S07IC02 S13MMI08
S14OOP04
S08NC07,

S08NC07 S13MMI04
S04SRS07
S03SRD08
S17AIA04
S03SRD06
S06SA02S12FC03,

S02SRU08 S10TS04
S04SRS09
S04SRS10
S15CSE01
S01SRA03
S15CSE01,

S03SRD14 S12FC07
S05SRN05

615

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
Morozov, S.Yu.
Morpurgo, G.
Motojima, 0.
Mozin, L.V.
Murin, B.P.
Mutoh, M.

,

S03SRD09 S12FC04
S06SA04
S05SRN08
S16MS04
S10TS03
S17AIA01—N—
Naitoh, T.
Nakabayashi, S.
Nakagawa, H.
Nakahara, K.
Nakahara, K.

S02SRU08
S12FC06
S08NC09
S02SRU09,,,

S08NC08 S11LLC02 S17AIA01

Pettersson, T.
Phinney, N.
Piacentini, I.
Pittin, R.
Pleško, M.
Poole, J.
Poore, R.
Pose, R.A.
Potepan, F.
Pozzato, M.
Priestnall, K.
Proshin, V.M.
Puccio, B.

S15CSE01
S13MMI13
S10TS07
S19SP01
S18BPA04
S15CSE01,,

S01SRA02 S02SRU01S01SRA12 S20PD03
S13MMI04
S15CSE01
S18BPA03
S04SRS04
S10TS05

S17AIA02

Nakajima, H.
Namkung, W.
Narusaka, H.
Navratil, J.
Nawrocki, G.J.
Nebogin, A.I.
Nelson, D.
Nemry, M.
Nigorikawa, K.N.
Ninane, A.H.
Nishikawa, K.
Nishimura, H.
Nishio, M.
Nobusaka, H.
Noda, K.
Nonglaton, J.-M.
Noumi, H.
Novakov, O.

S10TS08—Q—

S10TS02

Quesnel, J.-P.

S03SRD14
S08NC06
S03SRD04
S05SRN10S12FC03
S06SA05
S08NC09
S06SA05
S10TS08
S16MS02
S10TS08
S12FC09,

S03SRD14 S12FC07
S13MMI09
S04SRS09
S15CSE01—O—
Ogawa, Y.
Ohnishi, K.
Ohsawa, S.
Oleinik, G.M.
Olsen, J.D.
Oonuma, T.
Otake, Y.
Ovcharov, S.
Ovsyannikov, D.A.
Owen, E.C.G.

S11LLC02
S02SRU10
S11LLC02
S05SRN10S12FC03
S17AIA01,

S10TS04 S11LLC02
S05SRN09
S16MS05
S05SRN04—P—
Pace, A.
Pak, C.O.
Papazyan, Yu.V.
Park, M.K.
Park, S.Y.
Parker, C.R.C.B.
Peck, S.B.
Pedersen, F.
Perriollat, F.
Persigny, J.
Petrov, V.
Pett, J.
616,

S04SRS02 S13MMI02
S13MMI11
S05SRN10S12FC05
S10TS02
S08NC05
S03SRD03
S18BPA02
S03SRD01
S01SRA05
S05SRN09
S19SP01

S15CSE01—R—
Rabany, M.
Raffi, G.
Raich, U.
Rausch, R.
Rawlinson, W.R.
Rehlich, K.
Reid, D.
Reinhardt-Nickulin, P.I.
Ribes, J.-B.
Rice, D.H.
Riedel, C.
Riunaud, J.P.
Robb, A.
Rösch, W.
Rohrbach, F.
Rouse, F.
Rovelli, A.
Royer, J.-P.

,

S03SRD01 S07IC01
S05SRN03,,

S13MMI09 S20PD02
S02SRU02 S02SRU03S01SRA08
S13MMI07
S11LLC09
S11LLC05
S08NC05
S03SRD03
S10TS01
S18BPA03
S01SRA03
S10TS01
S09DPP03
S12FC02
S03SRD07
S19SP01—S—
Sakharov, V.P.
Sanchez-Chopitea, L.
Santiago, S.
Sarkar, D.
Sass, R.C.
Sato, H.
Sato, K.
Satoh, Y.
Savochkin, V.H.
Saw, S.H.
Scarborough, W.K.
Schaa, V.RW.
Schaller, S.
Scherbakov, E.D.
Schinzel, J.
Schmidt, V.
Schulte, E.
Schultz, D.
Segura-Chinchilla, N.
Seino, K.

S03SRD08
S13MMI13
S15CSE01
S13MMI14
S12FC02
S04SRS07,

S03SRD14 S12FC07
S10TS04
S05SRN10
S10TS06
S11LLC06
S01SRA07,,

S01SRA02 S02SRU01 S20PD01
S03SRD08
S15CSE01
S10TS07
S19SP01,

S01SRA02 S02SRU01
S15CSE01
S02SRU11

List of Authors

Senichev, Y.
Serio, M.
Serre, Ch.
Shea, M.F.
Shelekhov, V.A.
Shen, Z.
Shering, G.
Shibasaki, Y.
Shidara, T.
Shigeta, M.
Shimono, M.
Shoaee, H.
Shoji, T.
Shtirbu, S.
Shumakov, A.V.
Sicard, C.H.
Silin, A.
Skelly, J.F.
Smedinghoff, J.G.
Smirnov, V.P.
Smolucha, J.
Soga, F.
Solovyov, V.E.
Somers, F.
Someya, H.
Spencer, N.C.
Spiriti, E.
Stampfli, R.
Starker, J.
Stecchi, A.
Steinbach, C.P.
Steiner, R.
Strohman, C.R.
Strubin, P.M.
Stuewe, R.
Su, Y.H.
Sudou, M.
Sueno, T.
Sugimoto, M.
Surace, G.
Suzuki, Y.
Swoboda, D.K.
Sytin, A.

,

S10TS03 S11LLC05
S03SRD06,

S02SRU02 S11LLC01
S08NC01
S16MS04
S01SRA11,

S17AIA01
S11LLC02
S12FC07
S13MMI10
S12FC02
S09DPP01
S08NC01,
S11LLC01, S15CSE01
S03SRD09 S12FC04

List of Authors

S04SRS07
S10TS08
S13MMI10
S04SRS05
S04SRS07
S12FC07
S16MS01
S03SRD06
S19SP01
S03SRD08
S09DPP01
S12FC07
S03SRD14
S09DPP02
S06SA03—U—

S08NC11

Ulrich, M.
Underwood, K.K.
Urakawa, J.
Ustinov, E.A.

S14OOP01
S13MMI05
S05SRN10
S02SRU11

S02SRU04
S12FC03,

S02SRU08 S10TS04
S04SRS04—V—

S04SRS10

Vaguine, A.I.
Valentini, S.
Vande Vyvre, P.
Vaniev, V.
Vascotto, A.
Vasiljev, N.D.
Verhagen, H.
Vesztergombi, G.
Voevodin, V.P.
Vong, F.C.
Vos, L.

S04SRS04
S06SA05
S11LLC07
S12FC03
S03SRD06
S06SA02
S04SRS03
S03SRD06
S19SP01,

S01SRA07 S10TS01
S03SRD03
S19SP01,

S03SRD08 S08NC11
S03SRD06
S14OOP06
S05SRN09
S14OOP06
S16MS04
S07IC02
S09DPP03
S03SRD08
S03SRD04
S19SP01—W—,

S01SRA02 S02SRU01S04SRS06,,

S03SRD14 S04SRS10 S12FC07
S04SRS07
S05SRN02
S13MMI04
S04SRS09
S19SP01
S04SRS04—T—
Takabayashi, T.
Takada, E.
Takahashi, M.
Takahashi, T.
Takasaki, M.
Takeda, S.
Tanaka, K.H.
Tanaka, S.
Taniguchi, Y.
Terakado, T.
Thuresson, L.
Timossi, CA.

,

S03SRD01 S04SRS02 S13MMI03

Toda, M.
Torii, C.
Totsuka, T.
Toumanian, A.
Toyama, T.
Toyoda, E.
Trahern, C.G.
Trasatti, L.
Trofimov, N.
Trofimov, N.N.
Tsukihashi, Y.
Tsuzuki, N.
Tsuzuki, N.
Tummers, B.J.
Tyrrell, M.W.

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991

S10TS08,

S03SRD14 S12FC07,

S12FC08 S12FC09

Wada, T.
Wang, C.S.
Wang, L.Z.
Wang, Z.
Watanabe, S.
Westervelt, R.
White, G.R.
Wilkinson, N.A.
Winans, J.R.
Won, S.C.
Won, S.C.

S03SRD12
S03SRD10
S02SRU07
S01SRA11
S02SRU10
S08NC10S12FC03,

S08NC04 S14OOP05
S03SRD04,

S10TS02 S12FC05
S03SRD11—X—
Xu, W.

S05SRN11

S05SRN05
S04SRS09
S02SRU08
S04SRS09
S10TS08,

S05SRN07 S05SRN08S12FC09
S02SRU06
S01SRA03—Y—
Yagi, T.
Yagyu, J.
Yamagishi, K.
Yamagishi, T.
Yamanoi, Y.
Yamazaki, C.
Yamazaki, K.

S12FC07
S12FC09
S13MMI10
S12FC07
S04SRS09
S12FC07,

S05SRN07 S05SRN08

617

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
Yang, L.P.
Yao, C.-Y.
Yasuda, K.
Yei, K.R.
Yoder, N.
Yokota, M.
Yonehara, H.
Yonekawa, I.
Yoshikawa, H.
Yoshizawa, J.
Young, J.
Yourpalov, V.D.
Yue, W.

618,,

S02SRU07 S04SRS06S01SRA09 S01SRA10S12FC06
S04SRS06
S11LLC09
S11LLC02
S03SRD12
S13MMI10,

S03SRD13 S03SRD12S02SRU10
S01SRA03
S03SRD08
S04SRS06—Z—
Zagel, J.R.
Zaitsev, V.I.
Zapolski, N.
Zelazny, S.
Zelepoukin, S.A.
Zhabko, A.P.
Zhang, C.Z.
Zhen, W.
Zhou, J.
Zhou, X.
Zieman, R.C.
Zinoviev, S.V.

S12FC01
S05SRN10
S04SRS05
S12FC03
S03SRD08
S16MS05
S13MMI12
S03SRD12
S16MS01
S01SRA11
S03SRD04,

S03SRD09 S12FC04

List of Authors

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991

ANL
Lemont, Illinois, USA• Anderson, J.B.
• Anderson, M.D.
• Arnold, N.D.
• Cha, B.-C.K.
• Daly, R.T.
• Gunderson, G.R.
• Karonis, N.T.
• Knott, M.J.
• Kraimer, M.R.
• Lenkszus, F.
• McDowell, W.P.
• Nawrocki, G.J.
• Vong, F.C.
• Winans, J.R.
• Zieman, R.C.
BINP SB RAS
Novosibirsk, Russia• Kargaltsev, V.
• Kuper, E.A.
• Ledenev, A.
BNL
Upton, New York, USA• Barton, D.S.
• Skelly, J.F.
CERN
Geneva, Switzerland• Aimar, A.
• Albrecht, A.
• Antonsanti, P.
• Arruat, M.
• Bailey, R.
• Baribaud, G.
• Barillère, R.
• Barnett, I.
• Beetham, C.G.
• Benincasa, G.P.
• Berrig, O.E.
• Billinge, R.
• Bouche, J.M.
• Boutheon, M.
• Bret, A.
• Bretin, J.-L.
• Brun, R.
• Burla, P.
• Burns, A.J.
• Bérard, G.
• Cabas-Alonso, A.
• Cappi, R.
• Carlier, E.
• Cavallari, G.
• Chapman-Hatchett, A.
• Chevrier, F.
• Chohan, V.
• Ciapala, E.
• Cons, L.

Institutes List

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

Institutes List
• Coudert, G.
• Daems, G.
• Daneels, A.
• de Metz-Noblat, N.
• Defendini, A.
• Dehavay, C.G.A.
• Delamare, Ch.
• Deloose, I.
• Deloose, Y.
• Desforges, B.
• Di Maio, F.
• Dieperink, J.
• Ferran, G.
• Foffano, S.
• Gagnaire, A.G.
• Gavaggio, R.
• Gelato, G.
• Gueugnon, D.
• Heinze, W.
• Heymans, P.
• Hoh, R.
• Iselin, F.C.
• Jones, R.
• Kissler, K.H.
• Kohler, K.
• Kuhn, H.-K.
• Kuiper, B.
• Laffin, M.
• Le Goff, J.-M.
• Lewis, J.H.
• Manglunki, D.
• Marti, Y.
• Martini, M.
• Matheys, J.P.
• Mertens, V.
• Milcent, H.
• Missiaen, D.P.
• Moorhead, G.
• Morpurgo, G.
• Nonglaton, J.-M.
• Novakov, O.
• Pace, A.
• Parker, C.R.C.B.
• Pedersen, F.
• Perriollat, F.
• Pett, J.
• Pettersson, T.
• Pittin, R.
• Poole, J.
• Pozzato, M.
• Priestnall, K.
• Puccio, B.
• Quesnel, J.-P.
• Rabany, M.
• Raich, U.
• Rausch, R.
• Ribes, J.-B.
• Riunaud, J.P.
• Rohrbach, F.

619

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991• Royer, J.-P.
• Santiago, S.
• Schinzel, J.
• Schulte, E.
• Segura-Chinchilla, N.
• Serre, Ch.
• Shering, G.
• Sicard, C.H.
• Stampfli, R.
• Steinbach, C.P.
• Strubin, P.M.
• Swoboda, D.K.
• Trofimov, N.
• Tyrrell, M.W.
• Vande Vyvre, P.
• Vascotto, A.
• Verhagen, H.
• Vos, L.
CNRS/IN2P3
Strasbourg Cedex, France• Baumann, R.
• Kapps, E.
• Knaebel, R.
• Lutz, J.R.
• Marsaudon, J.C.
• Persigny, J.
Cockcroft Institute
Warrington, Cheshire, United Kingdom• Owen, E.C.G.
Consorzio RFX, Associazione Euratom-ENEA sulla Fusione
Padova, Italy• Flor, G.
• Manduchi, G.
• Piacentini, I.
• Schmidt, V.
Cornell University (CLASSE), Cornell Laboratory for
Accelerator-Based Sciences and Education
Ithaca, New York, USA• Peck, S.B.
• Rice, D.H.
• Strohman, C.R.
Czech Technical University
Prague 6, Czech Republic• Navratil, J.
DEC-Japan
Tokyo, Japan• Narusaka, H.
DESY
Hamburg, Germany• Clausen, M.R.
• Rehlich, K.
Elettra-Sincrotrone Trieste S.C.p.A.
Basovizza, Italy• Bulfone, D.
• Michelini, P.

620• Mignacco, M.
• Pleško, M.
• Potepan, F.
• Surace, G.
ESO
Garching bei Muenchen, Germany• Raffi, G.
ESRF
Grenoble, France• Götz, A.
• Klotz, W.D.
• Meyer, J.M.
Fermilab
Batavia, Illinois, USA• Briegel, C.I.
• Cahill, K.
• Chase, B.E.
• Franck, A.R.
• Goodwin, R.W.
• Hendricks, B.
• Holt, J.A.
• Joshel, R.H.
• Kucera, M.J.
• Lackey, S.L.
• Lucas, P.W.
• Seino, K.
• Shea, M.F.
• Shtirbu, S.
• Smedinghoff, J.G.
• Smolucha, J.
• Zagel, J.R.
GANIL
Caen, France• David, L.
• Luong, T.T.
• Lécorché, E.
• Ulrich, M.
GSI
Darmstadt, Germany• Krause, U.
• Riedel, C.
• Rösch, W.
• Schaa, V.RW.
• Steiner, R.
Hitachi, Ltd.
Ibaraki-ken, Japan• Asami, K.
• Azumaishi, R.
HMIBerlin, Germany• Busse, W.
• Schmidt, V.
I.V. Kurchatov Institute of Atomic Energy
Troitsk, Russia• Bulan, V.V.
• Chikovsky, V.M.
• Dudorova, E.I.

Institutes List• Kartashev, A.V.
• Lusin, Yu.N.
• Nebogin, A.I.
• Oleinik, G.M.
• Papazyan, Yu.V.
• Savochkin, V.H.
• Smirnov, V.P.
• Zaitsev, V.I.
IHEP
Moscow Region, Russia• Agababian, A.
• Agueev, A.I.
• Alferov, V.
• Brook, V.L.
• Cheng, H.J.
• Chuang, C.Z.
• Dunaitsev, A.F.
• Ekimov, A.
• Ermolin, Yu.
• Goloborodko, S.G.
• Gridassov, V.I.
• Guertsev, K.F.
• Gussak, A.A.
• Huang, H.
• Izgarshev, S.V.
• Kazarian, A.
• Khoetsian, H.
• Komarov, V.V.
• Krendelev, V.
• Lin, Q.
• Liu, D.K.
• Liu, S.-Y.
• Lu, P.
• Lukyantsev, A.
• Matevosian, A.
• Matveev, M.
• Mikheev, M.S.
• Ovcharov, S.
• Petrov, V.
• Proshin, V.M.
• Sakharov, V.P.
• Scherbakov, E.D.
• Solovyov, V.E.
• Su, Y.H.
• Sytin, A.
• Trofimov, N.N.
• Ustinov, E.A.
• Vaguine, A.I.
• Vaniev, V.
• Voevodin, V.P.
• Wang, L.Z.
• Yang, L.P.
• Yei, K.R.
• Yourpalov, V.D.
• Yue, W.
• Zelepoukin, S.A.
• Zhang, C.Z.
IMP
Lanzhou, People’s Republic of China• Chu, Z.S.

Institutes List

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991• Huang, T.H.
• Jiao, T.S.
• Li, T.Y.
• Ma, S.
• Shen, Z.
• Wang, Z.
• Zhou, X.
INFN/LASA
Segrate (MI), Italy• Giove, D.
INFN/LNL
Legnaro (PD), Italy• Bassato, G.
• Battistella, A.
• Bellato, M.A.
• Canella, S.
INFN/LNS
Catania, Italy• Cuttone, G.
• Rovelli, A.
INS
Tokyo, Japan• Katayama, T.
• Watanabe, S.
• Yoshizawa, J.
ISS
Rome, Italy• Caccia, B.
• Dante, V.
• Lomoro, R.
• Spiriti, E.
• Valentini, S.
IUCF
Bloomington, Indiana, USA• DuPlantis, D.
• Reid, D.
• Yoder, N.
JAEA
Ibaraki-ken, Japan• Sugimoto, M.
JAEA/NAKA
Ibaraki-ken, Japan• Akasaka, H.
• Aoyagi, T.
• Kawamata, Y.
• Kimura, T.
• Kurihara, K.
• Matsuzaki, Y.
• Nobusaka, H.
• Shimono, M.
• Takahashi, M.
• Terakado, T.
• Totsuka, T.
• Yagyu, J.
• Yamagishi, K.
• Yonekawa, I.

621

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
JAERI
Tokai-mura, Japan• Hanashima, S.
• Horie, K.
• Itoh, Y.I.
• Kumahara, T.
• Shoji, T.
• Tsukihashi, Y.
• Yoshikawa, H.
JAERI-RIKEN/Spring-8 Project TeamTokyo, Japan• Kumahara, T.
• Masuda, T.
• Wada, T.
• Yonehara, H.
• Yoshikawa, H.
• Zhen, W.
JINR
Dubna, Moscow Region, Russia• Kotov, V.M.
• Pose, R.A.
KEK
Ibaraki, Japan• Abe, I.
• Adachi, T.
• Ajima, Y.
• Akiyama, A.
• Arakawa, D.A.
• Araki, S.
• Furukawa, K.
• Hiramatsu, S.
• Holt, J.A.
• Ieiri, M.
• Ishida, T.
• Ishihara, N.
• Ishii, H.
• Ishii, K.
• Kadokura, E.
• Kakihara, K.
• Kamikubota, N.
• Kanaya, N.
• Kato, Y.
• Katoh, T.
• Kawakubo, T.
• Kawamoto, T.
• Kishiro, J.
• Komada, K.
• Kudoh, K.
• Kurokawa, S.-I.
• Matsumoto, S.
• Mikawa, K.
• Mimashi, T.
• Minakawa, M.
• Naitoh, T.
• Nakagawa, H.
• Nakahara, K.
• Nigorikawa, K.N.
• Noumi, H.
• Ogawa, Y.

622• Ohsawa, S.
• Otake, Y.
• Pak, C.O.
• Sato, H.
• Satoh, Y.
• Shidara, T.
• Someya, H.
• Sueno, T.
• Suzuki, Y.
• Takasaki, M.
• Takeda, S.
• Tanaka, K.H.
• Toda, M.
• Toyama, T.
• Urakawa, J.
• Yamanoi, Y.
• Yokota, M.
KFKI
Budapest, Hungary• Vesztergombi, G.
KHI
Kobe, Japan• Ishihara, K.
• Kubota, T.
• Nakabayashi, S.
• Yasuda, K.
LANL
Los Alamos, New Mexico, USA• Björklund, E.
• Burns, M.J.
• Callaway, T.
• Carr, G.P.
• Cohen, S.
• Dalesio, L.R.
• Harrington, M.
• Hill, J.O.
• Kerstiens, D.M.
• Kozubal, A.J.
• Kubicek, D.
• Poore, R.
• Scarborough, W.K.
• Schaller, S.
• Schultz, D.
• Stuewe, R.
LBNL
Berkeley, California, USA• Chin, M.J.
• Cork, C.W.
• Fahmie, M.P.
• Lancaster, H.
• Magyary, S.
• Molinari, P.
• Nishimura, H.
• Robb, A.
• Timossi, CA.
• Young, J.
LNF-INFN
Frascati, Italy

Institutes List• Di Pirro, G.
• Milardi, C.
• Serio, M.
• Stecchi, A.
• Trasatti, L.
Mitsubishi Electric Corporation
Tokyo, Japan• Ishida, T.
MRI
Moscow, Russia• Filipchicov, L.L.
• Frolov, I.
• Ivanov, Yu.S.
• Konovalov, V.A.
• Murin, B.P.
• Silin, A.
• Vaguine, A.I.
MRTI RAS
Moscow, Russia• Kabanov, V.S.
MSL
Stockholm, Sweden• Engström, M.
• Starker, J.
MSU
Moscow, Russia• Chepurnov, A.S.
• Gribov, I.V.
• Morozov, S.Yu.
• Shumakov, A.V.
• Zinoviev, S.V.
NAO-NRO
Minamisaku, Nagano, Japan• Iwashita, H.
• Kanzawa, T.
• Kawashima, S.
• Morita, K.I.
• Nakajima, H.
• Nishio, M.
• Takahashi, T.
• Torii, C.
NIFS
Chikusa-ku, Nagoya, Japan• Kaneko, H.
• Motojima, 0.
• Taniguchi, Y.
• Yamazaki, K.
NIIEFA
St. Petersburg, Russia• Mozin, L.V.
• Shelekhov, V.A.
• Vasiljev, N.D.
NIKHEF-K
Amsterdam, The Netherlands• Heubers, W.
• Tummers, B.J.

Institutes List

NIRS
Chiba-shi, Japan• Asami, K.
• Azumaishi, R.
• Endo, M.
• Hirao, Y.
• Itano, A.I.
• Kanai, T.
• Kanazawa, M.
• Kawachi, K.
• Kohno, T.
• Minohara, S.
• Morii, Y.
• Narusaka, H.
• Noda, K.
• Sato, K.
• Soga, F.
• Sudou, M.
• Takada, E.
• Tsuzuki, N.
NSRRC
Hsinchu, Taiwan• Chen, C.J.
• Chen, J.
• Jan, G.J.
• Wang, C.S.
NTUT
Taipei, Taiwan• Wang, C.S.
PAL
Pohang, Kyungbuk, Republic of Korea• Chang, S.-S.
• Choi, S.J.
• Huang, J.Y.
• Huang, J.
• Kim, J.-H.
• Kim, M.S.
• Kirn, J.H.
• Lee, J.-W.
• Lee, J.W.
• Lee, J.
• Namkung, W.
• Park, M.K.
• Park, S.Y.
• Won, S.C.
Plasma Research Laboratory, University of Malaya
Kuala Lumpur, Malaysia• Chew, A.C.
• Lee, S.
• Saw, S.H.
Power Reactor and Nuclear Fuel Development Corporation, Oarai
Engineering Center
Oarai, Japan• Endou, A.
• Himeno, Y.
• Miki, T.

623

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
RAL
Chilton, Didcot, Oxon, United Kingdom• Barton, C.J.
• Brownless, D.M.
• Kerr, J.C.
• Mannix, R.P.
RAS/INR
Moscow, Russia• Bragin, S.
• Esin, S.K.
• Ilinsky, N.G.
• Reinhardt-Nickulin, P.I.
• Senichev, Y.
Saint Petersburg State University
Saint Petersburg, Russia• Edamenko, N.S.
• Ovsyannikov, D.A.
• Zhabko, A.P.
SERC
Daresbury, Warrington, Cheshire, United Kingdom• Martlew, B.G.
• McCarthy, M.
• Rawlinson, W.R.
SHI
Tokyo, Japan• Aoki, K.
• Ohnishi, K.
SLAC
Menlo Park, California, USA• Allison, S.
• Clark, S.
• Grillo, A.A.
• Gromme, T.
• Hendrickson, L.
• Himel, T.M.
• Humphrey, J.
• Hutchinson, D.A.W.
• Kang, H.
• Krauter, K.E.
• Lee, M.J.
• Millsom, D.
• Nelson, D.
• Olsen, J.D.
• Phinney, N.
• Sanchez-Chopitea, L.
• Sass, R.C.
• Shoaee, H.
• Spencer, N.C.
• Underwood, K.K.
• White, G.R.
• Zelazny, S.
Space and Laser Communication Development Division, NEC
Corporation
Yokohama, Japan• Futagawa, N.
• Nishikawa, K.
• Takabayashi, T.

624

SSCL
Dallas, TX, USA• Allen, M.E.
• Bourianoff, G.
• Christiansen, M.
• Coffman, L.
• Dohan, D.
• Gurd, D.P.
• Haenni, D.J.
• Hunt, S.M.
• Low, K.
• Trahern, C.G.
• Zhou, J.
Sumitomo Electric Industries Ltd., Yokohama Laboratory
Yakohama, Japan• Tanaka, S.
TMEICTokyo, Japan• Morii, Y.
Tohoku University, School of Science
Sendai, Japan• Kitamura, M.
• Mutoh, M.
• Oonuma, T.
• Shibasaki, Y.
Toshiba Corporation
Tokyo, Japan• Morii, Y.
• Shigeta, M.
• Toyoda, E.
• Tsuzuki, N.
• Yagi, T.
• Yamagishi, T.
• Yamazaki, C.
Toshiba Mitsubishi Electric Industrial Systems Corporation
Tokyo, Japan• Tsuzuki, N.
TRIUMF
Vancouver, Canada• Dale, D.
• Ludgate, G.A.
• Wilkinson, N.A.
TSL
Uppsala, Sweden• Gajewski, K.J.
• Johansson, O.
• Thuresson, L.
UCD
Davis, California, USA• Rouse, F.
UCLouvain-FYNU
Louvain-la-Neuve, Belgium• Martou, J.L.
• Nemry, M.
• Ninane, A.H.
• Somers, F.

Institutes List

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
USTC
Hefei, Anhui, People’s Republic of China• Liu, Y.
• Xu, W.
USTC/NSRL
Hefei, Anhui, People’s Republic of China• Yao, C.-Y.
VECC
Kolkata, India• Dasgupta, S.
• Mallik, C.
• Sarkar, D.
VISTA
Los Alamos, NM, USA• Clout, P.N.
• Geib, M.
• Westervelt, R.
YerPhI
Yerevan, Armenia• Kazarian, A.
• Khoetsian, N.
• Toumanian, A.
• Zapolski, N.

Institutes List

625

3rd Int. Conf. Accel. Large Exp. Phys. Control Syst.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991
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 DOIPARTICIPANT LIST OF ICALEPCS '91 (NOV. 11 • NOV. 15, 1991)

626

Harada, Shunji (MELCO-NFDD)
Heinze, Wolfgang (CERN)
Hendricks, Brian (Fermi/ab)
Hendrickson, Linda Joyce (SLAC)
Heubers, Wim (NIKHEF)
Hien, Pham Zuy (CANT)
Hsu, K. T. (SRRC)
Huang, Jung-Yun (POSTECH)
Humphrey, John (Rusty) (SLAC)
Hunt, Steve (SSCL)
Iselin, Christoph F. (CERN)
Ishii, Kazuhiro (KEK)
Jan, Gwo-Jen (SRRC)
Jiao, Tian-shu (IMP)Joshel, Robert H. (Fermi/ab)
Kabe, Seiji (KEK)
Kadokura, Eiichi (KEK)
Kamikubota, Norihiko (KEK)
Kanaya, Noriichi (KEK)
Kanazawa, Mitsutaka (NIRS)
Kaneko, Hiroshi (NIPS)
Kase, Masayuki (RIKEN)
Katoh, Tadahiko (KEK)
Katsura, Tomotaro (KEK)
Kawakubo, Tadamichi (KEK)
Kawamoto, Takashi (KEK)
Kijima, Yuko (MELCO-NFDD)
Kimura, Toyoaki (JAERI-Naka)
Kimura, Yoshitaka (KEK)
Kishiro, Jun-ichi (KEK)
Kitamura, Masaharu (LNS)
Klotz, Wolf-Dieter (ESRF)
Knott, Martin John (ANL)
Kohno, Toshiyuki (NIRS)
Komarov, Vladimir (IHEP-Protvino)
Kouno, Satoshi
Kraimer, Martin R. (ANL)
Kubota, Tetsuya (Kawasaki. H.L)
Kudo, Kikuo (KEK)
Kuiper, Berend (CERN)
Kumada, Masayuki (NIRS)
Kumahara, Tadashi (JAERI-Tokai)
Kuper, Edward (/NP-Novosibirsk)
Kurokawa, Shin-ichi (KEK)
UcorcM, Eric (GANIL)
Lee, Martin Joe (SLAC)
Le Goff, Jean-Marie H. (CERN)
Liu, Shi-Yao (/HEP-Beijing)
Lucas, Peter Wayne (Fermi/ab)
Ludgate; George Arthur (TRIUMF)
Lukyantsev, Alexander F. (IHEP-Serpukhov)
Luong, Tam T. (GANIL)
Lutz, Jean-Robert (IN2P3-CNRS)Magyary, Steven Bela (LBL)
Mannix, Rbert Patrick (RAL)
Marsaudon, Jean-Claude (IN2P3-CNRS)
Participants List

Abe, Isamu (KEK)
Akiyama, Atsuyoshi (KEK)
Alferov, Vladimir (IHEP-Protvino)
Allen, Mike (SSCL)
Amtey, Sharad (SSCL)
Araki, Sakae (KEK)
Bailey, Roger (CERN)
Baribaud, Guy (CERN)
Barton, Carole Joan (RAL)
Barton, Donald S. (BNL)
Batskikh, G. (MRI)
Beetham, Christopher Gary (CERN)
Blumer, Thomas (PSI)
Bork, Rolf (SSCL)
Bourianoff, George I. (SSCL)
Briegel, Charles I. (Fermi/ab)
Bulfone, Daniele (INFN-Trieste)
Burns, Alan James (CERN)
Busse, Winfried (HM/)
Cahill, Kevin (Fermi/ab)
Canella, Stefania (INFN-LNL)
Cavallari, Giorgio (CERN)
Chang, Suk Sang (POSTECH)
Chepurnov, Alexander S. (MSU)
Chohan, Vinod (CERN)
Ciapala, Edmond (CERN)
Ciriani, Paolo (CERN)
Clausen, Matthias (DESY)
Clifford, Tom S. (BNL)
Clout, Peter Norman (VISTA)
Coffman, Lindsay (SSCL)
Crowley-Milling, Michael
Cuttone, Giacomo (INFN-LNS)
Dalesio, Leo Robert (LANL)
Daneels, Axel Jean (CERN)
Dasgupta, Subrata (VECC)
Dimaio, Franck (CERN)Di Pirro, Giampiero (INFN-LNL)
Dickey, Carl Edward (SSCL)
Dohan, Don A (SSCL)
Dunaitsev, Anatoly F. (IHEP-Serpukhov)
Emura, Katsuji (Sumitomo E.L-Osaka)
Engstrom, Mats (MS!)
Ermolin, Yuri (IHEP-Serpukhov)
Frolov, I. (MRI)
Furukawa, Kazuro (KEK)
Gajewski, Konrad Jan (TSL)
Giove, Dario (INFN-LASA)
GOtz, Andy (ESRF)
Grant, Peter Angus (TRIUMF)
Gribov, Igor V. (MSU)
Gurd, David P. (SSCL)
Hacker, Uli (KFA)
Haenni, David Richard (SSCL)
Hama, Hiroyuki (IMS)
Hanashima, Susumu (JAERI-Tokai)

619

Skelly, Joseph Francis (BNL)
Starker, Josef (MSI)
Stecchi, Alessandro (INFN-LNF)
Steiner, Rudolf (GSI)
Strohman, Charles Ralph (Cornell)
Stuewe, Robert B. (LANL)
Sugimoto, Masayoshi (JAERl-Tokai)
Suwa, Shigeki
Suzuki, Yoshihiro (KEK)
Takada, Eiichi (NIRS)Takahashi, Minoru (JAERl-Naka)
Takahashi, Mitsuyuki (IHI)
Takebe, Hideki (RIKEN)
Takeda, Shigeru (KEK)
Tanabe, Eiji (ABT-Japan)
Tanaka, Shigeru (Sumitomo E.L-Yokohama)Tanaka, Hitoshi (RIKEN)
Trahern, Charles Garrett (SSCL)
TrasattiI, Luciano (INFN-LNF)
Trofimov, Nikoly Nik. (IHEP-Serpukhov)
Tsybin, Alexander S. (MSTU)
Tumanian, Arsen Rafael (YPI)
Tyrrel, Mark William (CERN)
Urakawa, Junji (KEK)
Utsumi, Masafumi (MELCO-NFDD)
Vaguine, Alexei (MRI)
Vande Vyvre, Pierre (CERN)
Wada, Takeshi (RIKEN)
Wang, Zhen (RIKEN)
Watanabe, Shin-ichi (INS)Weng, C.S. (SRRC)
Wilkinson, Neil Adam (TRIUMF)
Won, Sangchul (POSTECH)
Xu, Weimin (HESYRL)
Xue, Jing-Xuan (!HEP-Beijing)
Yagi, Takao (Toshiba-Fuchu)
Yamada, Kohji (NKK)Yamamoto, Noboru (KEK)Yamazaki, Kozo (NIFS)
Yao, Chih-Yuan (HESYRL)
Yonekawa, lzuru (JAERl-Naka)
Yasunobu, Seiji (Hitachi-Ozenji)
Yoshikawa, Hiroshi (JAERl-Tokai)
Zagel, James R. (Fermi/ab)
Zaitsev, V.I. (Kurchatov)
Zlelepoukin, Sergei (IHEP-Protvino)

Masuda, Takemasa (RIKEN)
Matsutomi, Shokichi (Toshiba-Fuchu)
Matsuzaki, Yoshimi (JAERl-Naka)
McDowell, William P. (ANL)
Menens, Volker (CERN)
Miki, Tetsushi (PNC-Oarai)
Mimashi, Toshihiro (KEK)
Minohara, Shinichi (NIRS)
Miura, Takeo (Nippon Eng.)
Morita, Koh-Ichiro (NAO-NRO)
Mozin, Igor (Efremov)
Mueller, Klaus-Dieter (KFA)
Murai, Katsuji (Hitachi-Omika)
Murin, Boris P. (MRI)
Mutoh, Masakatsu (LNS)
Nakabayashi, Shiro (Kawasald H.L)
Nakagawa, Hidetoshi (KEK)
Nakamura, Takeshi (RIKEN)Navratil, Jiri (CTU)
Nguyen, Huan T. (SSCL)
Nigorikawa, Kazuyuki (KEK)
Ninane, Alain H. (UCL)
Nishimura, Hiroshi (LBL)
Nishio, Masanori (NAO-NRO)
Ogata, Hiroshi (RCNP)
Okumura, Susumu (JAERl-Takasald)
Otake, Yuji (KEK)
Owen, Edward Charles (Daresbury)
Oyamada, Masayuki (LNS)
Pace, Alberto (CERN)
Pak, Cheol On (KEK)Peters, Franz (DESY)
Pose, Rudolf (JINR)
Potepan, Franco (INFN-Trieste)
Protasov, Yuri S. (MSU)
Rabany, Michel (CERN)
Ratti, Gianni (ESO)
Raich, Ulrich (CERN)
Rausch, Raymond (CERN)
Rawlinson, William Robert (Daresbury)
Reinhard-Nickulin, Petr I. (INR)
Riedel, Larry Dean (SSCL)
Saban, Roberto (CERN)
Sarkar, Surajit (SSCL)
Saw, Sor-Heoh (Univ. Malaya)
Schaa, Volker R.W. (GS!)
Schaller, Stuart (LANL)
Schekochihin, Arkady V. (INP-Protvino)
Schimmel, Fred (NIKHEF)
Schmidt, Volker (!GI)
Serre, Christian (CERN)
Serre, Claudia (IN2P3-Paris)
Shea, Michael F. (Fermi/ab)
Shering, George Craig (CERN)
Shibasaki, Yoshinobu (LNS)
Shibata, Shinkichi (TCT)
Shirakawa, Aldhiro (KEK)
Skarin, Igor A. (INP-Protvino)

627

Participants List

620

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.
ICALEPCS1991, Tsukuba, Japan
JACoW Publishing
ISBN: 978-3-95450-254-7
ISSN: 2226-0358
doi:10.18429/JACoW-ICALEPCS1991