PC Based Alarm System for the HERA machine
M.Bieler, P.Duval, S.Herb, F.Willeke, DESY, Hamburg, Germany
A.Kurakin, V.Soloviev, V.Yarygin, IHEP,Protvino, Russia
Abstract
The new HERA Alarm System is based on the TINE dataexchange protocol, and consists of three levels: the Local
Alarm Server (LAS), a Central Alarm Server (CAS) andan Alarm Console. Alarms are generated by the Local
Alarm Server running on each of the approximately 50
front-end computers used for machine control. The CAS
gathers and filters the alarms and loads them into an alarmlist. It is a Microsoft Visual C++ application runningunder Windows NT and is both a TINE client and server,where the client-side makes use of the ACOP (AcceleratorComponent Oriented Programming) ActiveX component.
The Alarm Console is a Visual Basic application runningon Windows NT, which collects alarms from the CAS
and displays them for the control room staff. The Alarm
database is distributed as files on the Front-End
Computers (FECs), which are read in on start-up of theLAS. These files contain detailed information about
alarm events displayed on the Alarm Console. The FECs
themselves run on a number of platforms supported byTINE.

1 INTRODUCTION
The Hadron-Electron-Ring-Accelerator HERA atDESY, Hamburg, is an Accelerator facility for theinvestigation of electron--proton collisions[1,2].
The HERA control system[3] is a heterogeneoussystem based on the TINE[4] data exchange protocol, witha mixture of several different hardware platforms,
operating systems and network protocols, resulting in a
mixture of different application programs on the consolelevel. Error messages and alarms from the accelerator
hardware are displayed on the application programs of therelated hardware components, but until the end of the1997 run there was no general alarm system, combining
alarms from the different components of HERA on one
screen. This made it very difficult for the operator toidentify the reason for a beam loss or for bad machine
performance, because the operator had to go through manydifferent application programs to find the relevant alarm
messages.
The experience of the creation the similar Alarm
Systems for other acceleration control systems wasused[5-9].
The HERA alarm system was designed to be a system
which collects all kinds of alarms from the different
components of the HERA storage rings, generates thealarm information to be displayed on a console and stores
the alarms for further analysis in the central archive.
The local FEC first handles the alarm messages fromthe hardware. The FEC writes to a local list of alarm
messages. These alarm messages contain detailed
information about the alarms, a time stamp for each alarmand information about the FEC and the related hardware
system. The CAS reads these local alarm lists from theseveral FEC's, it joins these messages to a central alarm
list and provides this information for a console in thecontrol room, which displays a selection of the latest
alarms. All alarms will be stored in the central alarmarchive. In order to determine the precise sequence of themost important Alarms events so-called Time Stamp
FECs are used. A distributive Alarm database contains thedetailed description of alarm event.
In the following sections the different components of
the alarm system will be described.

2 THE LOCAL ALARM SERVERAs most control system alarms ultimately originate
during hardware or service IO operations, it is mostnatural to locate the first layer of alarm processing directlyon the front-end computer or middle layer server.
Furthermore, as the overall HERA control system isclient-server oriented, where clients are anonymous (i.e.
have no systematically known identities), a server doesnot “send” its alarms anywhere. Instead, it maintains a
local alarm list containing all the relevant information
about each alarm. Clients can then at any time query aserver, i.e. the LAS, as to its alarm state. The primaryclient for all local alarm servers is the CAS, where thenext stage of alarm processing takes place.
The LAS maintains a subset of information (snapshot)
describing its overall alarm state, namely: the total
number of alarms, the timestamp of the most recentalarm, the number of alarms with this timestamp, thehighest severity, and the number of alarms with thisseverity. The CAS obtains these data from all servers ona regular basis and then reacts when something changes.
When new alarms appear in the list, the snapshot
information changes, and the CAS then requests all of thealarm information after a particular timestamp.
Among other information, an alarm message (72 byteslength) contains a 16-byte character description of thealarm, the name(16-byte characters) of the server process(i.e. equipment module) which generated the alarm and 16byte character description of the equipment name. Eachalarm also carries a descriptor byte, which describes thetype of the alarm, alarm code, alarm severity level andsubsystem code.
Note that an alarm can carry up to 6 bytes of alarmspecific information(data set), such as pertinent hardware
channels, which caused the alarm. The timestamp used is
the traditional UNIX time stamp. As all HERA front-end
devices are generally synchronized to within 1 to 2
seconds of each other, this is the appropriate time
granularity.
The LAS responds to queries concerning static
information about an alarm code, such as text descriptions
concerning the alarm, the alarm data, sub system
information, etc. Tantamount to having a functioning
alarm system is that the alarm API is easy to understandand simple to use. In particular, questions as to whether aparticular alarm is oscillating (regularly coming andgoing) or whether it’s time to set its heartbeat descriptor
are best settled in a systematic way by the LAS. To thisend, most front-end developers need only make use of twosimple API calls SetAlarm() and ClearAlarm() inside theirhardware IO loops, always calling ClearAlarm() for eachdevice at the top of the loop, and SetAlarm() wheneveralarms arise. . As the front-end developer is most familiar
with the nature of the alarms he wishes to set, he is also
responsible for maintaining the local alarm database,which is primarily comprised of human-readable comma
separated value (CSV) files, which contain the text andseverity information associated with the alarms.

3 TIME STAMP FEC
In order to determine the cause of a beam loss inHERA, it is often necessary to reconstruct a sequence ofalarms with a precision of a few HERA turns. Therefore
some alarm message of critical components contain atime stamp with a precision of one HERA beam
revolution (21 µs). The HERA Integrated Timing(HIT)system is used to create time stamps for these alarmmessages.
The Time Stamp FEC(DOS, Borland C) is designedwith the following functionality:• receive triggers from hardware and read HIT countervalue• generate Alarm messages• test HIT counter value• check correct connection input signals with usinglocal database• provide filtration of the flickering input triggers
Now 7 Time Stamp FECs are working in HERAcontrol system.

4 CENTRAL ALARM SERVER
As mentioned above, the CAS(Windows NT, VisualC++) consists of client and server parts, where the clientsideuses
Accelerator
Component
OrientedProgramming(ACOP)[10], which is based on latest
Microsoft COM technology.
The CAS has a set of different functions that help toobtain and process a lot of information from the FECs of
the HERA control system. At first, the main function of
the CAS is maintaining a local double linked list of allalarms present in the control system at the moment and isready to give all or a part of this list to any interested
client. The alarm messages that have been collected by theCAS are structures of 72 bytes long and have a complete
specification that could be used by the CAS to put themin the list properly. The CAS is providing some
important functions to process the messages before they
will be put in the linked list. This class of functions isproviding different mechanisms to process an alarm
messages. Once alarms are in the local alarm list, they areaccessible via RPC mechanism to the specific function
calls.
To get information from the CAS, a client subscribes
to it and uses one of CAS properties. The specification ofsuch requests as well as the properties that will be used
depend of the type of information the client wants.
REFRESH mode guarantees that the client will receive
event notification as soon as it happens (subject to thepolling interval defined, for instance 1000 milliseconds).
Likewise, the CAS has some specific components thatprovide this service as easy in use to the specific client
like a console.
The CAS provides a refresh process as well. It isrelated to the local alarm message list and to the list of
the FECs that had been used since the start of the CAS
session. With that, the server refreshes the counter ofalarms with the most recent time stamp that could be usedby the console or another client to decrease the network
traffic. This allows the possibility of making a request for
the newest alarms only. The refresh functions have accessto both the local list of alarms and to the list of the FEC
names through four seconds and five minutes timeintervals respectively.
Upon startup, the CAS queries the TINE name server
as to which other TINE servers export alarm information.
This information is in turn used by the CAS to set up its
internal alarm information tables. The CAS periodicallyrepeats this query in order to keep these tables up to date.
The alarm console is the principal alarm client for theCAS-server and uses a network connection to it,following the TINE protocol, which allows asynchronous
event notification upon change of data. The console (orany other client) is able to get sufficient data in order to
identify front-end hardware parameters.

5 ALARM CONSOLEThe user interface was written using Microsoft VisualBasic, and consists of two processes. One process receives
and analyses the alarm messages from the CAS. The
second process displays information and interfaces to theuser. The inter-process communication was realized using
ActiveX technology and OLE. The Alarm Console
receives the main information about alarms as soon as
they appear. The information is displayed as a text string.
The string has the necessary alarm description(timestamp, code, descriptor, device name, equipment name,data, etc.). User may receive the detailed information
about the alarms from the Alarm database. Fourforeground colors are used for displaying Alarms with thedifferent severity levels. Alarm Console displays two
scrolled lists separately for the FAST alarms(which havenot got termination event) and for the SLOW alarms.
SLOW alarm list is infinitive and FAST alarm list
contains max 100 last alarm messages.
The Alarm Console uses ACOP ActiveX object,which allows easy reconnection to the CAS automaticallyin the case of the network errors, or in case the CAS isrestarted. In addition to that ACOP provides an easy way
to receive another information from the CAS usinggrouped links.

REFERENCES[1] HERA, A Proposal for a Large Electron Proton
Colliding Beam Facility at DESY , DESY HERA81-10
1981.

[2] F. Willeke, "Status of HERA", HEACC' 92, 15International Conference on High Energy Accelerators,Hamburg, 1992.
[3] P. Duval, "Controlling DESY Accelerators withPCs", PCaPAC '96.
[4] P.Duval, "TINE: An Integrated Control System forHERA", These Proceedings.
[5] J.-M. Bouché, J.Cuperus, M. Lelaizant, "The DataDriven Alarm System for the CERN PS Accelerator
Complex", ICALEPCS'93, CERN/PS 93-54 (CO), 1993.
[6] C. Cameron,"CERN Alarm System Front-End
Software", CERN/SL Note 94-83(CO), 1994.
[7] N. Gonthier, "CERN Alarm System User Interface",
CERN/SL Note 95-117(CO), 1995.
[8] C. Lemoine, M. Tyrrell,"CAS and Alarm Console New Features", CERN/SL Note 93-102(CO), 1993.
[9] P. Lefort,"Technical Manual of the Central Alarm
Server", CERN/SL Note 93-24(CO), 1993.
[10] I. Deloose, P. Duval, H. Wu, "The Use of ACOP
Tools in Writing Control System Software", CERN/PS
97-67 (CO), 1997, Int. Conference on Accelerator andLarge Experimental
Physics
ControlSystems(Icalepcs'97), November 3-7, 1997, IHEP, Bejing, China.