“How much time does alarm rationalization take?” 

It finally happened. Alarm management problems at the plant led to an incident and now management wants action. You have “volunteered” to put together a plan to execute alarm rationalization. You need to create a defendable estimate of how long rationalization will take so that management can approve the project resources.

What is Alarm Rationalization?

Alarm Rationalization is a process for evaluating alarm candidates against criteria defined in an alarm philosophy to establish their rationale and document their design requirements. The process follows a structured methodology performed by a multifunctional team that conducts Rationalization Meetings (Workshops) in order to review, justify, and prioritize alarms.  Alarms resulting from the methodology are said to be “rationalized.”  

The following is a fictitious conversation similar to what might take place when scoping an alarm rationalization project.

How long it will take to complete alarm rationalization for my plant?

It depends on a number of factors which you should understand before attempting to estimate the duration.

Can’t you just give me a typical value to use? I think I heard 100 – 200 alarms could be rationalized per day.

The 100 – 200 alarms / day is a common figure that is cited. It is also said that 300 – 400 alarms per day are possible with good prework [1]. Before applying these benchmarks, you really need to understand the factors that impact how long it takes.

Okay, so what are these factors?

There are numerous factors that influence the time it actually takes. Let’s run through these first and then circle back to estimate how long it will take for your plant.
Factors Influencing the Time it Takes to Complete Rationalization

  1. First and foremost is the number of alarms that need to be rationalized. The more alarms to review, the longer the process.
  2. Existing system (brownfield) or a new installation (greenfield) - It takes longer when there is no or minimal operating history / knowledge. So a greenfield will typically take longer.
  3. The process and operations knowledge of the rationalization team. It makes a difference whether your process engineer is fresh out of college or whether he is a “lifer” that was there when the plant was commissioned 30 years ago.
  4. The expertise and experience of the rationalization facilitator. This shouldn’t be their first rationalization project.
  5. The tool that is used to document the rationalization results. A good rationalization tool can drive consistency, prevent mistakes, and make it easier to copy results from one alarm to another (the key to efficiency).
  6. The level of preparation and “homework” done behind the scenes by the facilitator.
  7. The level of commonality in the design (e.g., if there are multiple identical operating units, then we can copy the results from the first unit to the other units without extensive discussion). A good tool helps here.
  8. The extent of rationalization rules and “go-bys” defined in the alarm philosophy document. Some alarms, especially “diagnostic” alarms, can be best rationalized by following a rule that applies across-the-board to similar alarms. This minimizes time and drives consistency.
  9. The level of rationalization. Not all steps of the rationalization need to be done at once. It often makes sense to discuss advanced alarming requirements in a separate session. Alarm deadbands and on/off delays can be reviewed as needed outside of the rationalization workshop.

Wow, that’s a lot of factors to think about. In terms of the number of alarms, I was told the operators get 1000 alarms / day.

Actually, that’s not the right number to use. We need to look into the configuration to see how many alarms are possible (configured or configurable), not in the history database to see how many alarms the operator gets.

Okay. Looks like we have approximately 10,000 total alarms. That means it would take 50 to 100 days (10 – 20 weeks). Yikes!

Yes, that is way too conservative. The 100-200 alarms per 8 hour day applies to a system where you have too many alarms enabled; rationalization will focus primarily on review and elimination of enabled alarms that are not needed. This means that the figure applies to Enabled alarms (those alarms that could activate if the trigger condition is satisfied). How many of your 10,000 total alarms are enabled (vs. disabled)?

Looking through the configuration file, I see that roughly 6000 of the alarms are Enabled (60%). If I split the difference and assume 150 Enabled alarms / day, that gives me 40 days (8 weeks) as the estimated duration.

Still kind of high. The fact that 60% of your alarms are Enabled could be what’s creating problems. We could get a better estimate if we know the breakdown of the types of alarms.

What do you mean types of alarms? I can run a pivot table to see like how many High and High-High alarms there are, is that what you mean?

Yes. Run the pivot table on all of your enabled alarms and let’s see what you get.

OK here it is. What does it mean? I don’t even know what some of these alarm types are used for!

Alarm Type

Quantity

Category

Hi, Lo, HiHi, LoLo, ROC

2000

Process Alarm

Disc_ALM, Fail_ALM

1000

Process Alarm

Invalid Mode,
Module Error,
SP Write Error,
PV Ignored Alarm,
PV Bad,

3000

Diagnostic Alarm

If you don’t know what they mean, I doubt the operator does either. Alarms like “Invalid Mode” or “SP Write Error” might not be relevant and actionable to the operator, so they could go away or become an “alert”. The best way to treat these diagnostic alarms is to define a rule in the alarm philosophy and have it apply across-the-board to all Invalid Mode alarms. These alarms can then be rationalized outside of the meeting. So we cut the number of reviewable alarms from 6000 to 3000.

Nice. If I divide by 150 alarms / day, I am now down to 20 days (4 weeks). Much better.

Not so Fast. We are not done yet. Looking at the configuration it seems like there is duplicate equipment?

Yes, there is a Train 1 and a Train 2. The alarms for Train 2 should match that of Train 1. 

Great. That allows us to take credit for duplication, which improves the number of alarms per day to 2X or 300 alarms / day.

Wow, dividing by 300 alarms / day, we are now down to 10 days (two weeks). My boss will be much happier with that number. 

You can see how we were able to get more accurate as we understood more details about the alarm configuration. If you had blindly applied 150 alarms / day to the total number of alarms, your estimate would have been approximately 13 weeks instead of 2. Quite a difference.

 

Method

Estimated Rationalization Length

Estimate # 1

Total # of Alarms (10,000) divided by 100 - 200 alarms/day

50-100 days (10-20 wks)

Estimate # 2

Qty of Enabled Alarms (6000) divided by 150 alarms/day

40 days (8 wks)

Estimate # 3

Qty of Enabled, Process Alarms (3000) divided by 150 alarms / day

20 days (4 wks)

Estimate # 4

Qty of Enabled, Process Alarms (3000) divided by 300 alarms / day (accounting for efficiency of Train 2)

10 days (2 wks)

As a final data point, below is a table showing the actual rationalization duration for selected projects. Most of them were led by exida facilitators, but in a couple of cases they were led successfully by the customer after some facilitator training by exida.

Example Projects

Project

Application

Facilitator

Control System

Total # Alarms

Duration

Progress  Avg Alarms / day

Customer N

Hybrid Brown / Greenfield

exida / Self

Yokogawa

27,177

28 days*

970**

Customer O

Brownfield

exida

DeltaV

33,571

11 ½ days*, ½ day sessions (Remote)

2919**

Customer M

Brownfield

Self

DeltaV

27,000

30 days (4 hr sessions)

900

Customer D

Greenfield

exida

DeltaV

91,730

13 wks (65 days)

1411

Customer T

Brownfield

exida

DeltaV

6,046

4 ½ days

1343**

Customer S

Brownfield

exida

Honeywell

10,929 (Console 1)

11 days

993

Customer S

Brownfield

exida

Honeywell

22,946 (Console 3)

18 days*

1275

Customer B

Brownfield

exida

PCS 7

6400

15 days

427

Notes:
* Indicates rationalization workshops were held remotely via the web
** Indicates a “go-by” ruleset was developed based on Alarm Type

All projects used exida SILAlarm rationalization tool for documentation

Conclusion:

Alarm Rationalization is a systematic process. Having a good tool, a good team, and a good facilitator can minimize the amount of time it takes and ensure that you end up with quality results.

References

[1] Management of Alarm Systems (IC39), ISA Training Course.
[2] ISA-TR18.2.2-2016, Alarm Identification and Rationalization (also known as TR2)

For More Information


Tagged as:     Todd Stauffer     Alarm Rationalization     Alarm Management  

Other Blog Posts By Todd Stauffer