[IGN-4921]Alarm Aggregation/Summary

Hi,

I would like to know what the best way is to get a summary of the alarms on a UDT. What I need is the highest priority active alarm (for a colour around the UDT symbol) and if there are any unacknowledged alarms (to blink). I need to do this for about 50 UDTs on a page with about 100 clients active.

I see the following options:

  1. Use an expression tag on the UDT that monitors all configured alarms and presents a summary integer (priority code and negative if unacked). Similar to below:
if(max({[.]Alarm1/Active/Alarms.HighestActivePriority}
		,{[.]Alarm1/Active/Alarms.HighestUnackedPriority}
		,{[.]Alarm2/Active/Alarms.HighestActivePriority}
		,{[.]Alarm2/Active/Alarms.HighestUnackedPriority}) = null, 
		null,
	
		if ({[.]Alarm1/Active/Alarms.HasUnacknowledged}
			|| {[.]Alarm2/Active/Alarms.HasUnacknowledged}, -1, 1)
				*
			max({[.]Alarm1/Active/Alarms.HighestActivePriority}
					,{[.]Alarm1/Active/Alarms.HighestUnackedPriority}
					,{[.]Alarm2/Active/Alarms.HighestActivePriority}
					,{[.]Alarm2/Active/Alarms.HighestUnackedPriority}))

The disadvantage of this is that if a new alarm is added to the UDT, one must remember to add it here. It also occasionally (very infrequently) shows an alarm when none are present, as if the expression didn’t evaluate.

  1. Use 5 custom properties bound to isAlarmActiveFiltered() expressions, one for each priority and one to see if anything is unacked.
    I do not know the performance impact of this across potentially 50 UDTs per page and 100 clients.

  2. Use system.alarm.queryStatus() and analyse the results to the summary. There is a warning in the documentation about performance, so I am hesitant to use it for my use case.

If we had this structure aggregated to a UDT or folder level, it would all be automatic:
image

What would you recommend?

Regards,
Deon

I have a feeling you may be best off going with the 5 separate expression tags option. At least with this method, you could use the {PathToParentFolder} parameter available to UDT tags to build out the path argument of the isAlarmActiveFiltered() function and it would dynamically check all of your alarms. That function may only check for alarms in the folder that you point the path argument to (even with a wildcard at the end of your path string), so you will probably want to double check that if all of your UDT’s alarms are not contained within the same folder.

This is basically what we do, albeit with a focus on DisplayPath instead of tag path.

We use a UDT that takes a DisplayPath as a parameter and provides a separate expression tag for each priority using isAlarmActiveFiltered (with a reasonable polling rate). Since it’s all done in tags the execution happens on the gateway and the clients don’t see any performance impact.

I filed a ticket when this was first suggested to see if we could potentially evaluate these automatically at the folder level as suggested. That ticket wasn’t immediately shot down, but is still in the ‘incubation’ phase; there’s (legitimate) concerns about performance, so we might have to do something more complex like only aggregate that calculation if the folder/instance tags are actually subscribed.

But, that’s hopefully going to be a feature available at some point in the future, for what it’s worth.

2 Likes