Adding more Alarm Priorities

I couldn't find any documentation on this. But does anyone know if it is possible to change and/or add to the Alarm Priorities in Vision? I am working on a project with pretty strict guidelines one of which is having 7 alarm priorities. Which is obviously 2 more than currently available in Vision.

EDIT: I am looking for a different solution if the above mentioned does not work like mentioned by jlandwerlen

This question has come up before, perhaps search the forum, but priorities are hard coded so you can't add or remove or even change the name.

Edit, also this isn't a vision thing, it's a tag/platform thing.

Perhaps refer to ISA 18.2, it's quite clear on the number of priorities to use, it's not 7.

Maybe I should have phrased it differently. I have seen this post, but I was wondering if anyone knew of an alternate solution since that wasn't discussed in the original or if any new information was available.

However much I want to refer to ISA 18.2 and stick to the 5 priorities Ignition offers, I don't have a say in how this project has been designed or how the guidelines have been set up. Unless there is absolutely no other feasible way to get around this problem, me and my team will have to build it with 7 alarm priorities.

These priorities will be almost exclusively just be used for filtering and visuals though.

There's no practical way to modify that enum, but there are plenty of ways to filter visuals. I imagine what you are wanting to do could be resolved in a simpler manner than recreating the alarm prioritization system. What kind of visuals are you wanting to create/filter?

We need to build a couple of alarm tables where we can sort, visualize and deal with the alarms through acknowledgement or suppression depending on their priority:

Current Alarms Table
Current Notifications Table (same as Current Alarms but lower priorities)
Suppressed Alarms Table
Historic Alarms Table
Historic Notifications Table (same as Historic Alarms but lower priorities)

Visually they get their own colors depending on their priority and status.

We are allowed to design the way the tag and their alarm structure works. But we are very much stuck to the 7 priorities.

This is something I know how to do with WinCCOA but not in Ignition.

There really isn't.

Ignition's alarm prioritization cannot be extended or customized in place.
You could, in theory, attach your own prioritization information to every single alarm using custom metadata.
If you do that, you are giving up:

  1. Every piece of configuration UI in the designer related to alarm priority.
  2. Every bugfix/workaround/piece of internal logic specific to alarm prioritization
  3. Every first party component, in Vision or Perspective, to display or interact with alarms. No Alarm Status Table, no Alarm Journal Table; you have to roll your own.

You are inviting future engineering confusion and, even if all future engineers are perfectly aligned with your custom alarming solution, guaranteed to be spending an enormous amount of engineering effort up-front to get anything working.

3 Likes

I have run into this on my own projects. The work around I found best was to figure out who specified the specific software or hardware. In this case, if the same person(s) that is requiring 7 priorities chose Ignition, then they should have known about how Ignition does alarm priorites. I was able to get exceptions to specific requirements this way. Worth a shot at least.

2 Likes

Or, did someone write the spec by just pulling some datasheets off some HMI software they found and really aren't needing all 7 priorities, but it was listed somewhere so it got included in the spec. (I've seen this before where some strange spec was listed that was so specific that it excluded every vendor except 1, and it was really only there because whoever wrote up the spec just copy/pasted some info off of a datasheet for the hardware/software even though they really didn't need/use it)

2 Likes

Or maybe someone did this deliberately, for this reason. Or to set up a vendor to fail. :man_shrugging:

2 Likes

Remember that the built in alarm status table (current alarm list) and journal (historical) both have ways of customizing the colors based on conditions. In theory, a developer could combine the alarm's priority with alarm's status and create up to 20 different conditions that could be used to "color" and filter the alarms.

I could imagine meeting the spec requirements by creating three templatized alarm status tables for the current and suppressed alarms along with two templatized alarm journal tables for the historical stuff.

Example: Priortiy + Status (Active or Inactive)/(acked or Unacked)
• Critical with Active (ack or unack) = Priority 1
• Critical with Inactive.(ack or unack) = Priority 2
• High with Active (ack or unack) = Priority 3
• High with Inactive.(ack or unack) = Priority 4
• Medium with Active (ack or unack) = Priority 5
• Meduim with Inactive.(ack or unack) = Priority 6
• Low (Active or Inactive).(ack or unack) = Priority 7
• Diagnostic (N/A)