4th Alarm Priority

hi, I know DeltaV comes out of the box with 3 alarm priorities (low, med & high). As a company, we are looking at introducing a 4th alarm priority for 'Highly Managed Alarms', which would be a higher priority then the standard high alarm. I would be very interested in hearing DeltaV Users thoughts around using a 4th alarm priority and would be more interested in hearing from users that are actively using more then the 3 standard alarm priorities. Various discussions within alarm management courses have identified a 4th alarm priority is becoming more common for highly managed alarms and the common color seems to be purple. We're on version 11.3.1 so not sure if newer versions come with more options. I'm aware of the DeltaV setup for alarms, with alarm priorities ranging from 1 to 15, 15 being the highest.

any comments would be greatly appreciated.

12 Replies

  • Hi Stuart,

    Adding one or more alarm priorities isn't something I would see as a problem. As an example, batch prompts or other types of "messages" would certainly have a separate priority. I have had a customer add "Operator Alerts" as a medium type of priority to give the operators a set of non-engineered alarm limits to use at their discretion.

    The question I am asking back is two-fold: 1) what is the purpose of "Highly Managed Alarms" as a priority? How does this fit into your alarm philosophy? 2) Why does this need to have a higher severity than "Critical" alarms?

    Recall that the three out-of-the-box priorities are pretty standard: 1) Advisory (low) - device alerts, maintenance items, etc 2) Warning (medium) - your process is trending in a negative direction but isn't critical yet, and 3) Critical - process shutdown is imminent.

    It is hard for me to place an alarm with a higher severity than Critical - unless it was either very limited number of items or something truly safety related. As an example: if you wanted your SIS alarms to have a different sound or color, then that would be an example that seems reasonable to me.

    On the topic of colors, I have used orange for the afore-mentioned "Operator Alerts."

    If you do not have an alarm philosophy document or have not developed an alarm rationalization process, I would strongly encourage you to do so.  Emerson has a partner, Exida, who's sole purpose is to do and advise on these types of topics.


    That is my $0.02.

    Dave

  • In addition to what what Dave said, changing the order of the alarm priorities (i.e. moving Critical to something other than 15) can be done but it has some "opportunities". See another discussion on the same similar topic here: emersonexchange365.com/.../7259

    I would suggest leaving Critical where it is and have that be the SIS/Highly Manged Alarms and create a CRITICAL-PAS priority (also change the color table so it's different color and noticeable) and then do your alarm rationalization using the new priorities. This process is alot easier in v13 as there is a bulk edit format file (Module_Alarm.fmt) that can be used that will export all alarms in the system (regardless of name). If not v13 then the bulk edit format file will need to have all the alarms with the proper name and fields in the format file itself.
  • We have the same issue but opted to stay with 3 alarm priorities. The concern is that an Operator may not recognize an alarm belonging to an HMA class (with only 3 priorities) and take the proper steps to mitigate the hazard. Our solution was to add a custom alarm description identifying the alarm as an HMA in the Advanced tab of the alarm properties so that it would be easy to recognize in the alarm summary; however, I don't believe this is an option on versions below 12.3.
  • In reply to gxmontes:

    That's correct Gilbert, Alarm Description was released in v12.

    Here's a view of where it resides:

  • In reply to Matt Stoner:

    Just wanted to weigh in with some other considerations. "Highly Managed Alarm" is a term defined in the ISA-18.2 standard that is applied to alarm classifications, not to alarm priority. Below is the definition from ISA-18.2:

    "highly managed alarm (HMA): alarm belonging to a class with additional requirements (e.g., regulatory requirements) above general alarms
    EXAMPLE: safety alarm"

    Classification and priority have two different purposes. Priority is for helping the operator understand the relative importance of one alarm compared to another (so they know which alarm to respond to first). Classification is a way to group alarms that have common sets of requirements for things like training, testing, MOC, reporting. Examples of classes include personnel safety, safety (related) alarms, LOPA listed alarm, Environmental, Product Quality, Equipment Reliability.

    This is important for DeltaV users, because a deltav alarm can be assigned both a priority and a class (called functional classification). DeltaV V13 provides the ability to filter the alarm summary display based on class, run audit reports based on class, and filter reports in DeltaV Analyze based on class.

    So the takeaway recommendation is if you are going to create a fourth priority, don't call it "Highly Managed Alarm" and consider leveraging functional classification in DeltaV to help manage alarms that have unique requirements above and beyond the typical process alarm.
  • In reply to Todd Stauffer:

    Thank you all for your comments. I asked the original question as we have an HSE action post a 'Human Factors / Alarm' audit by the HSE to identify to the operator that the alarm is classified as 'Highly Managed'. As Todd mentions, the term Highly Managed is taken from ISA-18.2 and is defined by us as an alarm that has been taken credit for in a safety assessment i.e. LOPA. We do use the functional classification field and have an entry named 'highly managed' but this field isn't available to display in the standard alarm list, so we cant identify the alarm as highly managed to the operator.

    We have a number of assets and not all are DeltaV, so our solution to our issue will need to be able to be implemented on all alarm systems (which just complicates things even more).

    When we have our onsite meeting to discuss the 4th priority, I will certainly base my response around your inputs, many thanks for taking the time to respond.
  • In reply to Stuart Jolley:

    If you have v13, you can edit the Alarm Summary object on the AlarmList graphic and add "Func" on the Column tab so this can be seen.
    Unfortunately this column isn't available in an earlier release.
  • In reply to Matt Stoner:

    unfortunately we're currently on v11.3.1
  • In reply to Stuart Jolley:

    I'm curious, How does identifying an alarm as belonging to the "Highly Managed" classification to an operator help improve their alarm response/performance? Are they expected to respond faster or better to that classification of alarm than others? I might be missing something, because all I can see this action doing is adding another layer of complexity on top of the alarm system that I find hard to justify.

    To be clear, I understand why you classify them. If you were using DeltaV Analyze (or some other method) to research the alarm performance/KPIs, then it makes sense. What I'm not clear on is why does the operator have to know and care about that in addition to responding to alarms.
  • In reply to dave_marshall:

    I would filter on "LOPA Listed Alarms", for example, and see how many times an operator had to take action / response time and so on to validate its usefulness as an IPL. Or, I might be able to argue that the hazard frequency claimed in the LOPA was too great / too low or whatever. The HAZOP revalidation team might use the statistics as well . . . just a few thoughts.
  • In reply to John Rezabek:

    Yeah, but that is not at the Operator level correct? If I read the question right, he's adding the priority so that the operators know what classification it is. I totally understand the purpose from an administrative/research/review standpoint, but not from an Operator running the facility standpoint.
  • In reply to dave_marshall:

    It is not necessarily related to alarm response/performance but for operator awareness/recognition. For example if an IPL class alarm is not available due to an instrument failure, the operator is expected to formally document how the loss of the alarm is being mitigated and to ensure that proper priority is placed on the repairs by maintenance. You don't want to depend on a person's memory where there are more than a few HMAs.