Alarm Suppression PLC Level

Hi Guys,

Has anyone successfully implemented Alarm Suppression on the PLC level. For example, take a motor that shuts down on a low flow switch, and right after a bunch of suction or discharge pressure alarms also get triggered. Our customer wants it so that only the alarm that caused the shutdown be displayed on the alarm summary and any other alarms should be suppressed. In the past I don`t suppress anything, I let all the alarms just come up on the HMI. Note, this alarm needs to be only suppressed automatically on the alarm summary and not on HMI graphic objects.

This whole alarm suppression thing is fairly new to me. This whole alarm suppression thing has evolved from alarm management discussions etc. So that in a shutdown situation, the operator doesn`t get overwhelmed by the flurry of alarms.

Anyway, I was thinking of doing it so that we create two alarm bits, one for the PLC and one for the HMI. The PLC alarm bit will never be suppressed only the HMI bits will be. I will have a suppression bit that will be triggered based on a group whether its area specific or equipment specific. It will be a ton of work but the client wants it.

Let me know if any of you guys have any other ideas to do this.

Thanks!

Just don't set the suction/discharge alarm bits if the other failure has alarmed. That's what I do.

Say I have a pressure switch that monitors hydraulic oil pressure on a system. If that pressure switch isn't on, an alarm is set saying that the hydraulic oil pressure is low. But, I only turn that bit on if the hydraulic pump motor is actually running. If it's not running, and it should be, I turn on an alarm saying that the pump isn't running.

Rather than trying to fancy up the alarm system, just take a more logical control of when you turn on the various alarm bits.

In my case, I usually only display one alarm at a time, and choose which one takes precedence. But the same way I use to only display one alarm, the most important alarm, can be used to ignore specific alarms if their state may be caused by the previous alarm.

Yes.

We do it exclusively. The only feature that is not in the PLC is the disabled - which is managed by the HMI.

Standard features of our alarming are:
Conditionalizing (permissives)
Alarm Delay (debouncing)
Hysteresis

We incorporate the standard features into all of our alarms. Of course, a discrete signal won't have hysteresis, but the others apply.

And now that we have leveraged AOI's into our ControlLogix processors, all of the features are "built in", and all the programmers have to do is configure the AOI and verify the configuration. The logic no longer has to be tested and validated, as it is done at the AOI level.


Now, you mentioned that your customer wants to conditionalize all downstream alarms that are caused by the initial event. This can be done, and we have successfully done this as well. It takes a lot more knowledge of the process, and causal factors. Sometimes downstream alarms have nothing to do with the initial event. This is a difficult concept to master.

Good luck.

Alarming done well adds a lot of value to the system and saves a lot of questions from the operator.

Alarming done well can be quite a challenge, especially if you are trying to automatically identify root cause alarm.

Greg

I'm with Tharon's approach. Sounds like some of those alarms should only be enabled if other conditions are satisfied. I would think of it less like supressing the alarms and more like defining the conditions under which the alarms are valid.

Thanks for getting back guys. My motor example was not a good choice. A better example would be for example a plant shutdown. Say a high level in an amine vessel causes a plant shutdown. When this occurs other domino effects might occur such as pressure surges etc. In this situation we only want the high level shutdown to appear and all the other domino alarms or shutdowns need to by dynamically suppressed.

This would help the operator tremendously. I have programmed class C timers on compression panels numerous times but its not the same thing.

I will come up with an add on instruction with alarming, hysterisis, rate of change, dynamic and static suppression. I will also incorporate first outs as well. This new project is a really big one for me. We have 15 17 slot racks with redundant l75 controllogix processors.

Rockwell has a process object library which is cool but it chews up a lot of memory and scan times are not within acceptable limits. Our client has only allowed us a maximum of 300 ms scan time So our code has to be very efficient. Will go ladder for everything accept for pid loops.

Oakley are your Aoi's in ladder? Do u incorporate first outs? do you ever do suppression at the hmi level? I will be spending a lot of time with the process engineers regarding this whole suppression.

Thanks again guys. This thread is more of thinking out loud. Besides its a good thing for other programmers to know as clients have their own standards on alarm management. It's a lot of work but its worth it.

elmatador said:

I will come up with an add on instruction with alarming, hysterisis, rate of change, dynamic and static suppression. I will also incorporate first outs as well. This new project is a really big one for me. We have 15 17 slot racks with redundant l75 controllogix processors.

Rockwell has a process object library which is cool but it chews up a lot of memory and scan times are not within acceptable limits. Our client has only allowed us a maximum of 300 ms scan time So our code has to be very efficient. Will go ladder for everything accept for pid loops.

Oakley are your Aoi's in ladder? Do u incorporate first outs? do you ever do suppression at the hmi level? I will be spending a lot of time with the process engineers regarding this whole suppression.

Click to expand...

All of our programming is in Ladder as a standard. We have one exception ... we placed a FB Totalizer into an AOI. This in effect makes the Totalizer exposed to ladder programming.

We actually evaluated our programming standards against RA PlantPax. We weren't satisfied that PlantPax was sufficient. So for some of our AOI's, we started with their version, stripped off the bloat, and added in our standards. Other AOI's we just started from scratch.

As for our Input AOI's (Analog In and Discrete In), I would say we have conditionalizing, debouncing, and hysterisis (except discrete). All our alarm suppression (disabling) is done at the HMI level.

As for first out, yes we do have a system with a very complex alarming system. We did in fact leverage AOI's again. Basically creating a heiarchy of alarms. The upper layers would prevent downstream alarms from occuring. We did have to do an alarm rationalization analysis on all the alarms as well. One of the outcomes was that we did not want to include our Process Critical, Safety Critical, Enviromental Critical, nor our COD-MU points within the heiarchy.

In our small coal yard, Wonderware over Controllogix - I wouldnt recommend doing any 'handling' in the HMI - the way we are set up (multiple PC's reading redundant PLC's) the PLC data is stored a lot more 'reliably' than any data in the HMI PC's.

As an example- we store tagout numbers in the PLC, (entered and cleared via the HMI) that way - if an HMI needs to be rebooted, the tagout data (which logically disables the equipment also...) is still stored.
This means that if you stop or reload the PLC program, you need to handwrite what all is tagged out. But since PC reboots happen much more often than PLC reboots (PLC is reduant L35's, power supplies are on an ABT...) this is the better way to go.

And before you jump me - yes, the tagout on the HMI happens alongside a tag hung on the breaker, so we arent using the HMI to disable equipment.

Given this, I'd suppress alarms on the PLC level also - it gives the fix-it-guy only one place to look for what is going on.

-John

Johnster said:

In our small coal yard, Wonderware over Controllogix - I wouldnt recommend doing any 'handling' in the HMI - the way we are set up (multiple PC's reading redundant PLC's) the PLC data is stored a lot more 'reliably' than any data in the HMI PC's.

As an example- we store tagout numbers in the PLC, (entered and cleared via the HMI) that way - if an HMI needs to be rebooted, the tagout data (which logically disables the equipment also...) is still stored.
This means that if you stop or reload the PLC program, you need to handwrite what all is tagged out. But since PC reboots happen much more often than PLC reboots (PLC is reduant L35's, power supplies are on an ABT...) this is the better way to go.

And before you jump me - yes, the tagout on the HMI happens alongside a tag hung on the breaker, so we arent using the HMI to disable equipment.

Given this, I'd suppress alarms on the PLC level also - it gives the fix-it-guy only one place to look for what is going on.

-John

Click to expand...

John,

You do bring up a valid argument.
In our current configuration, we have a "crawler" that get's the suppression (disable) tag value and store it in a SQL database. The crawler is activated every hour or upon engine failover. In addition, this SQL database is redundant. So, it doesn't matter which server is writing to the database, the other has it too.
The upon restart, the server reads this database for it's current configuration.

But you did lead into a valid argument that depending on your network stability, your design may be different.