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.
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.
@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]
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).
