Hi Kay,
We actually try to do the way you describe.
Besides device drivers/IOCs we have intermediate JCA server, where are
"soft records" which serve as logic for CSS panels.
There is no need for CALC record, since with JCA server you write
processing directly in Java. So far we have feedback loops, powersupply
cycling, network ping checks, remote process watchdog and similar in
JCA. Status display and controls are in simple CSS panels. There are
some scripting attached to the panels, just to make display nicer for
operators.
So yes, there is something like "alarm calc", which has list of
(unbounded) input PVs and can process and filter both Status and
Severity (or DBR if you want) into single alarm source. This is
happening in our JCA server in Java.
I plan to write something for PCaPac, which will be at ANKA this year.
Give me few days and I will gather overview and some examples. I should
write some docs by now anyhow.
Best regards,
Igor
On 06.03.2014 15:39, Kasemir, Kay wrote:
Hi:
Conceptually, I think that is exactly the right approach.
It's usually wrong to simply add 100 raw "temperature" PVs as alarms. It's better to have an operator display that shows these alarms, with summary PVs for sections of the machine, options to disable them, and those summary PVs are then used as alarm triggers.
For the displays, we already have good tools: EDM, BOY, … editors where you can create displays that suit the purpose.
For the logic, we have CALC records, which have limitations for their number of input links, length of the formula, and also nothing in there that is specific to alarms.
So often you end up with one "formula" that has to be split into several calc records.
Or you put the SEVR of other records into the INPx fields because you really want to summarize based on the raw alarm states, not the raw values.
Do you have a web link, paper, … on your intermediate layer?
Maybe it would also be worthwhile to create a new "alarm calc" record that has many inputs plus formulas that are aware of not just an INPuts value but its alarm severity?
Thanks,
Kay
On Mar 6, 2014, at 9:26 AM, Igor Kriznar <[email protected]> wrote:
Hi,
at ANKA we have implemented filtering, which filters alarms regarding
the operation mode. When machine is in shutdown or maintenance, most of
alarms are suppressed, before they reach CSS BEAST.
All our alarms are feed into our intermediate alarm server, which
decided if they should go further to BEAST or be suppressed or be
somehow otherwise processed. For example have summary alarm PV, which
sums alarms from whole subtree.
Our intermediate alarm server is based on JCA and looks like bunch of
plain PV channels which are used by BEAST. No changes were made to
BEAST, everything is in configuration.
Enable feature of BEAST I see more like permanent switch, if you want to
disable misbehaving alarm source.
Hope this helps,
Igor
On 05.03.2014 04:39, [email protected] wrote:
Hi
We are currently using BEAST. There is the ability to put alarm system in Maintenance mode. But it puts the whole entire system in Maintenance mode. We would like to be able to put an Area or a System in maintenance mode.
I’m wondering if there is any plan to implement such feature. Or would anyone else find this feature useful?
We have started investigating this implementation. Essentially the ENABLED_IND database field should be move to ALARM_TREE table from PV table, and isEnable() should be a base class method.
Thanks,
Xinyu WU
ASKAP Computing
Australia Telescope National Facility
CSIRO Astronomy and Space Science
phone: +61 2 9372 4727
postal: PO Box 76 Epping, NSW. 1710
- References:
- CSS BEAST alarm hierarchy Xinyu.Wu
- Re: CSS BEAST alarm hierarchy Igor Kriznar
- Re: CSS BEAST alarm hierarchy Kasemir, Kay
- Navigate by Date:
- Prev:
RE: Sequencer is not monitoring Pvs from another IOC Mark Rivers
- Next:
Question on Autosave Westfall, Michael D
- 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: CSS BEAST alarm hierarchy Kasemir, Kay
- Next:
Re: CSS BEAST alarm hierarchy Rolf Keitel
- 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
|