Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: RE: AlarmHandler as a daemon or service
From: "Liyu, Andrei" <>
To: Matthias Clausen <>, "Williams Jr, Ernest L." <>
Cc: EPICS tech-talk <>
Date: Wed, 05 Apr 2006 11:32:37 -0400

I would like to add a little.

"These are the mandatory functions" 
We need to start from definitions of ALARM objects+goals and
relationships between objects. As minimum:
	- Alarm daemon (thread) in IOC
	- Alarm server in Epics distributed control system 
	- Alarm client and system client
	- Alarm daemon API. API must be max simple and flexible. Rules
are clear (that record and other objects (in future) can use.)
Fortunately, libCom library is fine :)
	- Alarm server API for IOC and clients
	- message definition: delimiter(s) + head (like IOC name, PV
name, timestamp (real from IOC!) and so on}

>From implementation point of view
- of course, fixed size but it can be changed when by setting in config
- maybe IOC needs to have 2 buffers and sends message on 1 Hz rate (that
is not real time!)
- config file need to have list of Alarm servers. That gives possibility
to increase reliability. If Alarm server #1 would drop IOC will connect
to Alarm server #2. Also Epics administrator can handle with Alarm
server CPU loadings. Of course, Alarm client needs to be a little smart
- config file need to have setting of Alarm thread priority. Alarm
priority depends from type of control system. Data (CA protocol) is more
important for one set of systems, Alarm for another and so on.

	I am not sure about ORACLE or another commercial DB as base
ALARM client. Epics is free(?) and community needs to follow this way
(?). But I agree that bridge to DB is useful and definitions give that
possibilities. I am not sure that XAL or another smart client
application is fine. Why? We need to separate Control system as control
system and other slave (but important) goals. Alarm subsystem is part of
control system and control system must have tool! So control system must
have Alarm client. It must be simple, reliable and work all time on
chief-operator display. Maybe Alarm can join to Epics Office (if I am
not mistaken with idea of Epics Office)? 
	Actually, I see way with OS restriction - Alarm client & server
can be Linux, Windows, or MAC. Plus Alarm client can be C++/Qt or Java.

"Message display and acknowledge"
- It totally depends from message definition.
- configure the hierarchy. I don't see possibility to do real hierhical
because Epics record programming is not object-oriented. (I can give
example what is really means and how solution comes). But there is one
point how problem can be solved. That point is record name. Record name
and EDM (or other) displays should be synchronized. When alarm came PV
name gives possibility to chose correct display. So IOC engineer will
become a little smarter :)
	I suppose another variant will come to have record name and
display name relationship table ... and we will come to headache of
supporting the table (if you will change PV name you need to ...).

Thanks, Andrei.

-----Original Message-----
From: Matthias Clausen [] 
Sent: Wednesday, April 05, 2006 5:56 AM
To: Williams Jr, Ernest L.
Cc: EPICS tech-talk
Subject: Re: AlarmHandler as a daemon or service

Back from my trip to eclipsecon and my visit at SLAC - thanks to the 
organizers of the little eclispe/XAL workshop I want to summarize where 
we are with the alarm message approach.

>> For the future we want to change the alh message stream from opt-in
>> it is now) to opt-out - any alarm will be sent from the IOC to an
>> queue. 
> Following the idea of iocLogServer?  This is a really good idea; what
> your time frame?
To implement this feature we will need the right hook into IOC-core to 
make sure that we will catch all alarms generated on an IOC. There has 
been a discussion on tech-talk already about this subject:

The discussion going on there is a good starting point to find out which

implementation would be the 'right' one.
There's one implementation (or is it really a hack?) for the D0 IOC's
There's the proposal from Andrei and the comments from Kay.
Did someone else already think about this and what are the results?
In any case we will need an implementation which is EPICS-core 
compatible and will in the end make it into one of the next EPICS
- Point (1) on the to do list.

Second is the implementation on the iocAlarmMessage task on the IOC.
These are the mandatory functions:
- Receive triggers from record processing that an alarm has been raised
- Retrieve alarm information from record and prepare the alarm message
- (We are currently working on the necessary properties for alarm 
messages and messages in general. This list will be close to the cmlog 
- Write alarm message to message queue (fixed size - no malloc/free here

;-) )
- Write messages to message servers (one at a time)
- Implement redundant paths to redundant message servers
- Point (2) on the to do list
(This might a quick one because we have implemented a lot of these 
features already for the caPutLog tasks on the IOC.)

The message server will forward the messages to the JMS message server.
- Point (3) on the to do list

The messages will get written to the Oracle database by a message client

receiving the messages from the alarm message queue.
- Point (4) on the to do list
(This will be implemented in due time)

Message display and acknowledge

Displaying messages from the (Oracle) archive
Implemented in eclipse-BIRT - is one of the results of the eclipsecon!

Displaying online messages:
Open questions:
- What shall the hierarchy look like?
- How to configure the hierarchy? (using the existing alhConfig files?
- How to implement acknowledge alarms?
- What kind of filters are currently used/ necessary - or missing?
- Point (5) on the to do list

Alarm actions:
What kind of actions are necessary?
- Sending mail
- Sending SMS messages
- Send speech messages
- Changing values on the same - or other - records
- Point (6) on the to do list

So in the end we have - at least - 6 action points.
We plan to work on them during this year to get at least the basic 
features running.
We can speed up the process if others step in and we work on it 
collaboratively ;-))

Does this answer the question?
> what is
> your time frame?

>> This way you will run a system process in the background which 
>> makes sure that any alarm from an IOC (independent of any
>> file) will be written to e.g. Oracle or a file.
> I saw an option in the current alarmhandler to write to ORACLE. hmmm?
Yes it's being used here for some of the alarm handlers.
But also this approach relies on running alarm handlers (with the same 
dependencies) writing through a message queue to an Oracle service 
writing the alarm messages to the database.
> By the way have you thought about having the AlarmHandler speak
> messages?
For now we just send SMS messages.
Since Nokia joined the eclipse foundation we might get an easy way in 
the future to send text messages to GSM phones. Also the text to speech 
package in eclipse is really interesting to implement something in this 
But - it's at least not our list for now.
In the overall design it would 'just' be another message client 
converting message strings into speech messages and calling the on call 
> We are playing with text annunciation (on miniMAC) here at the SNS.
We might discuss future alarm message designs during the upcoming EPICS 
Maybe we can form an interest-group before?


Matthias Clausen                         Cryogenic Controls Group(MKS-2)
phone:  +49-40-8998-3256                Deutsches Elektronen Synchrotron
fax:    +49-40-8994-3256                                    Notkestr. 85
e-mail:                           22607 Hamburg                                                 Germany

Navigate by Date:
Prev: Re: for Intel OS X machines? Andrew Johnson
Next: adding a scan period john sinclair
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: RE: AlarmHandler as a daemon or service Ernest L. Williams Jr.
Next: RE: AlarmHandler as a daemon or service Liyu, Andrei
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·