Experimental Physics and Industrial Control System
Hi,
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
files.
- 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 [mailto:[email protected]]
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
(as
>> it is now) to opt-out - any alarm will be sent from the IOC to an
alarm
>> queue.
>>
> Following the idea of iocLogServer? This is a really good idea; what
is
> 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:
http://www.aps.anl.gov/epics/tech-talk/2005/msg00809.php
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
versions.
- 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
approach)
- 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
configuration
>> 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
regime.
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
shift...
> We are playing with text annunciation (on miniMAC) here at the SNS.
>
>
We might discuss future alarm message designs during the upcoming EPICS
workshop...
Maybe we can form an interest-group before?
-Matthias
--
------------------------------------------------------------------------
Matthias Clausen Cryogenic Controls Group(MKS-2)
phone: +49-40-8998-3256 Deutsches Elektronen Synchrotron
fax: +49-40-8994-3256 Notkestr. 85
e-mail: [email protected] 22607 Hamburg
WWW-MKS2.desy.de Germany
------------------------------------------------------------------------
- Navigate by Date:
- Prev:
Re: EpicsHostArch.pl 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024