Alarm/Alert features and importance - post your opinion here

Which feature set is most important to you
[poll]

  • Template components
  • Mobile Module V2
  • Alerting Overhaul
  • Reporting Module V2
    [/poll]
    What are important alarm/alert features to you? Here’s what I’m tracking that customers have asked for so far:

Better Re-notifying, contact groups, escalation, better remote acknowledgement, voice enunciation with callback.

I added a request for native “bitwise” support on behalf of zxclo here.

Also noted Curlyandshemp’s request for dot matrix printing support here.

No request besides what is already listed, but I’d like to reiterate desire for escalation and remote ack. Very important features for Water/Wastewater industry.

As long as we’re putting it all in one place, Alarm reduction.

This is the ability to build a hierarchy of alarms and have the higher alarms hide the lower alarms.

NEED support for alarm heirarchy/groups with the ability to suppress an entire group including all subgroups.

Distribution list escalation. For example, if an alarm is triggered x times in y period, send a notification to z people.

I would like to see a New Alarm Event on both the client and the gateway. In the event, include the alarm path, state, etc.

Having a system call to acknowledge all alarms for a certain system, path, etc would also be nice.

The ability to suppress all alarms for a device.
This would allow users to take something out of service, fix it, test it, etc without driving operators nuts with alarms.

Ability to temporary suppress individual alarms. eg: faulty sensor.

The ability to group alarms by process somethging like ozone system, main plant and distribution system.

@Robert - Could a “device” be a hierarchy of alarm nodes and children? In that way you could effect a whole section of a plant, a line, an individual device, single alarm, etc.

[quote=“Robert”]The ability to suppress all alarms for a device.
This would allow users to take something out of service, fix it, test it, etc without driving operators nuts with alarms.

Ability to temporary suppress individual alarms. eg: faulty sensor.[/quote]

@Henry - I imagine that could work like how gmail does “tags” on your emails. Once you have your alarms grouped/tagged, what does that do? Anything besides who gets notified and how the alarm is displayed on the screen?

For fun, I want to think of ways that all these could be supported. The tricky part will be keeping it simple. I’m thinking right off the bat that there will need to be some sort of alarm hierarchy that is separate from the conditions that set it off (tag mapping or whatever). It also seems like there will need to be some sort of rules engine for all the elevating/re-sending, logging, etc.

[quote=“nathan”]@Robert - Could a “device” be a hierarchy of alarm nodes and children? In that way you could effect a whole section of a plant, a line, an individual device, single alarm, etc.
[/quote]

Yep.

Configurable from a spread sheet like how it is now except having the AlarmState in individual columns.

This seems like the easiest part, JBoss has a complete rule engine called Drools licensed as ASL2.

I’d ideally like to see something like this for creating alarm/alert conditions and building notification logic:

@gbuehler - do you envision retransmissions, groups, and escalation to be incorporated in the same rule engine?

Omit my previous statement. After working on the Alerts this last week I got to like it the spread sheet format the way it is.

That is the easiest route I see. Notification Profiles already exist, but if they can be extended with additional information like acknowledgement history that can be consumed by users in a rule engine, I think that it should be able to cover as many possible usage scenarios as possible.

For example I can have a rule that says (warning psuedo code):

if (alarms.unacknowleged > 0)
{
    foreach (alarm in alarms.unacknowledged)
    {
        notify.group("Local_Maintenance");

        if ((alarm.history.Where(x=>x.lastactive > (now() - now().add(-24, "hours"))).Count() >= 5)
        {
            notify.group("District_Maintenance");
            notify.user("District_Maintenance_OnCall");
        }
    }
}

Make the rule engine rich enough, and I can cover what I need using rules.

Id like the ability to create alarm groups. I also think that re-notifying i by far the most important feature missing. Also a +1 for alert escalation.

If what has been referred to as remote acknowledge is the ability to configure another tag as the acknowledge tag then I would like to second this.

If its something completely different then I would like to request the ability to have another tag defined in the tag alerting configuration section as the acknowledge tag. So that if the alarm is acknowledged, its associated acknowledge tag will be set to 1, allowing a PLC based alarm acknowledgement routine to run.

This will help out when I have multiple HMIs looking at the same PLC (i.e. a panelview HMI plus a Ignition SCADA client)

I could probably do this through scripting but I imagine there are others out there who would like this. This is a standard option in Alarms in RSView32

@Alex - I think that situation would be covered by the proposed rules engine. If not, it sounds like a reasonable feature to me.

When I said “better remote ack”, I was referring to situations like where the system calls/texts your cell phone and you acknowledge the alarm by PIN on the keypad (or if possible an incoming text message from a trusted number).

Alarming, then, almost as important, a complete Reporting module upgrade. Thanks! (Add +1 for Alarming).