Control of the QUENCH Protection System at HERA
R. Bacher, P. Duval, S. Herb, K.H. Mess and H.G. Wu
Deutsches Elektronen Synchroton (DESY), Notkestrasse 85, 22603 Hamburg, GermanyAbstract
We describe the control of the Quench Protection System for the superconducting magnets of the HERA
proton storage ring in DESY. General control (operator to hardware) follows “standard model” -like concepts
with multiple consoles communicating with front ends via the ethernet. The front end control is based on
redundant VME CPUs running the VxWorks real-time operating system. The data-link to the lower level
quench microprocessor and PLC based alarm control center is connected via the CAN fieldbus. A network
server task communicates with consoles running MS WINDOWS and Visual Basic via UDP. Importantquench data are automatically archived following critical events, allowing follow-up expert system analysis
while the machine is brought again into operation.

Introduction
The HERA proton ring consists of 422 superconducting dipole magnets and 224 superconducting
quadrupole magnets. These magnets are cooled by 4.5 K liquid helium. A current of 5025 A goes throughall these magnets for a proton beam energy of 820 Gev. The superconducting magnets are ultimately
protected via hardware as opposed to relying exclusively upon software logic, the quench detection
electronics being monitored independently. Passive quench protection is achieved by using bypass diodes.
Active quench protection is carried out by using transducers to measure the current flow in bridges to detect
quenches, and then activating the corresponding dipole heaters to protect the magnets and operating the maincurrent switches. Futhermore, redundant components are integrated into the system as much as possible, atboth at the hardware and software levels. The present system uses front end VME-based CPUs running
VxWorks and makes use of the CAN fieldbus and PLC modules. A microprocessor-based computer
provides local intelligence for monitoring, testing and fault state detection of all the quench hardware
components. A PLC-based microprocessor functions as an alarm control center collecting alarm signals,
such as quench electronics status, power status, status of switches and alarm status from beam loss
monitors. This processor makes critical decisions regarding beam dumps and machine operation. Various
hardware test commands can be excuted from the control system consoles. The current state of the quench
protection system is collected asynchronously at the consoles from the VME CPUs via the ethernet. The
front-end CPUs and the quench microprocessor and alarm control center are linked via the CAN bus.
Logically the VME CPU acts as a front end supervisor, collecting data, coordinating the behavior of thequench microprocessors and alarm control center and serving as a network server.
A more detailed description of the quench protection system at HERA is given elsewhere [1]. In this report
we concentrate on the design of the software control, starting at the level of the VME crate and progressing
to the GUI at the console level. Specific details of the hardware controllerss such as the PLCs will not bepresented here. A schematic of the system architecture is given in figure 1.

Remote PC
ConsoleRemote PC
ConsoleWINDOWS

Ethernet

cpu

VME CPUMVME 162

cpu

VxWorks

CAN bus (octant 1)

microprocessor
forQuenchdetection
monitor

Alarm
Control
Center(PLC)CAN bus (octant 2)

microprocessor
forQuenchdetection
monitor

Alarm
ControlCenter(PLC)Figure 1. Schematic drawing of the hardware architecture for a quadrant

The Console Software
We use PCs running MS WINDOWS 3.1 in the machine control room as consoles. Several application
programs written with VISUAL BASIC are responsible for controlling and monitoring the quench
protection system. Data exchange between application programs and the front end servers is via ethernet.
We use a socket-based RPC-like protocol, developed for the HERA PC control system [2]. Changes ofstate are noted promptly at the console via asynchronous messages from the front end. Furthermore, thefront end appears as an integrated device at the console, allowing specific commands, such as to activate aheater test, to operate specified main current switches, or even to dump the beam to be performed by amouse click on a synoptic display. The total response time (mouse click to hardware setting and return) for
command execution is typically less than one second.

Front End Hardware
A total of eight MVME162 CPUs are used for front ends, two CPUs being housed in a VME crate in eachof the four HERA halls.They are used to control and monitor quench operation and the alarm center. One ofthese CPUs is always executing as the master, the other as a redundant partner. The data-link to the lower
level quench microprocessor and PLC-based alarm control center is provided by the CAN fieldbus. Twoseparate CAN buses are connected to each of these CPUs. One CAN bus connects one alarm control centerand four quench microprocessors. Two of these four microprocessors provide redundant control for the dipole
magnets, and the others deal with the quadrupoles, and groups of dipoles and groups of quadrupoles. TheCAN data transmission speed is set to 500 kHz, and the overall time of one CAN telegram transmission is250 µs.
Live insertion cards are used for the VME CPUs. One can remotely or locally power one CPU on or off,
without disturbing the operation of the othes. All front end hardware is powered through an uninterruptable
power supply (UPS). Furthermore, each front end in the hall operates independently of the others and iscapable of operating in a stand-alone manner.

Front End Software
The front end software has been developed for the VxWorks real-time multitasking operating system.
A network task services remote consoles and runs at rather low priority. As mentioned above, the HERA
PC control RPC protocol is used for updating registered consoles. Commands which change the state of themachine can only be executed by allowed users.
A PLC task is responsible for communication with the alarm control center, by sending a request command
via the CAN bus every second. A hardware redundancy check is also performed upon request from the alarm
control center. According to the result, it will send an alarm to the alarm center to dump the beam ifwarranted. A message queue is used for collecting console commands from the network task. A test task
can be excuted for testing transducer and heater electronics if the console application sends a test request.
A CAN message receive task collects CAN bus data, and sorts and distributes them to mailboxes; it
operates on semaphores according to CAN-IDs. During quench detection, it will perform heater statuschecks and send heater commands to the quench microprocessor if necessary. Quench telegrams come at
speeds of 200 Hz, the maximum speed from 4 crates at once being 800 Hz. This means that the CAN datatransmision must take place less than 1ms. The 250µs message transfer time mentioned above is more thanadequate. A massive quench situation has been simulated with programs written for VxWorks, to test thisextreme situation. No performance problems were detected.
A monitor task, running at 10 Hz, checks the status of all other running tasks and the data integrity withthat of the redundant CPU, as well as the status of the CAN bus connections. According to this check it
marks itself as ‘OK’ or ‘NOT OK”, and sends its status information to its partner CPU via the CAN bus.
Upon receiving this CPU status information, it will determine whether it should continue to act as slave ortake over as master.
Only the master CPU responds to the console commands and sends commands via the CAN bus to thequench microprocessor and alarm center. Although the slave acts as a passive listener, it runs exactly thesame code and possesses all current information.
In the unlikely event of a CPU hang, a ‘COLD BOOT’ is still possible by toggling the power on the live
insertion card remotely from the console program.

The Quench ArchiveA dedicated client application running on a PC is responsible for archiving important data upon quench or
beam loss alarm. It monitors the quench status and initiates a data archive if necessary. The archive datacontain the complete state of the machine at the time of the quench or other critical events. The experts canthen use these data at their leisure while the machine is brought up into operation again. The archived data
are read by the same application program in the same way, but the data link is to an archive file, instead ofthe front end program.

Performance
The current system has been in operation since April 1995, and operates as designed. Although the wholesystem is composed of so many different hardware and software components and involves data exchange
from different platforms on the field bus, it has proven to be a reliable system. During the half-year ofoperation, the built-in master-slave redundancy has not been invoked.

Acknowledgements
We would like to thank all colleagues who have been involved in this project.

References[1] K.H. Mess et al. “Quench Protection at HERA”, proceedings of HEACC 92 in Hamburg[2] P. Duval, “Implementation of PCs in the HERA Control System”, ICALEPCS 95 in Chicago, theseproceedings