| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: CSS BEAST alarm hierarchy |
| From: | Igor Kriznar <[email protected]> |
| To: | [email protected] |
| Date: | Thu, 06 Mar 2014 15:26:48 +0100 |
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