Help Me Understand ALMA/ALMD Parameters

(or industry alarming in general)

Hi all,

I’m working to implement (in C++, in a more or less platform-agnostic way) Alarm/Event detection, handling, and so on and started teasing the problem by modeling my solution after the Rockwell ALMD/ALMA objects. On that path, my most pressing curiosity I have would be why there’s a distinction between ‘Operator’ and ‘Program’ when it comes to alarm acknowledgement, shelving, suppression, and so on. If the end result is the same, are the ostensibly redundant parameters just that?

I tried my best at Googling this one. Thanks for the help!

Operator acknowledgement is typically done by acknowledging the alarm using a SCADA interface.

Program acknowledgement is typically done within the PLC code.

The end result of either, as you say, is the same. But it's useful to have the two options so that you can have acknowledge code in the PLC without interfering with acknowledge signals from the SCADA.

Thanks ASF!

Under what kinds of conditions would you acknowledge by code? Wouldn't this defeat the purpose of requiring operator notification/action?

you would ack via code when it's something that doesn't require human intervention


consider a tank with H & HH level indicators. HH may actually latch a bit for an alarm, and through code be reset (when level fall below, via a timer, etc.)

Small disclaimer: I don't actually use the rockwell ALMD instructions. They are missing a critical feature, so I made my own ALM_D instruction using the same tag names. But here's how I use my version:

Consider a system with a PLC, SCADA system, alarm indicator/siren, and a physical reset pushbutton.

If there are any unacknowledged alarms, the alarm indicator flashes and the siren sounds. Once all alarms are acknowledged, the indicator turns solid and the siren is silenced. Once all alarms are cleared, the indicator turns off.

The operator can acknowledge the alarms on the SCADA to silence the alarm. Under normal circumstances, they'll do that. Each alarm is acknowledged and silenced using the Operator Acknowledge. But I also want the physical reset button to silence the alarm. So, the reset button acknowledges all the alarms using the Program Acknowledge. At this point, the alarm is acknowledged at the PLC level - so the siren is silenced - but it's not acknowledged at the SCADA level. The operator still has to select and acknowledge the alarm at the SCADA, so you know that it's been seen.


Another example might be some motor alarms. Let's say you have a motor with three alarms: overload, isolator, fail to start. Motor overload trips, electrician tests and finds motor needs replacing, they turn off the isolator and replace the motor. Then they come back to the control room and on a motor popup faceplate, click "reset". This reset button can now acknowledge/reset both the overload and the isolator alarms programatically, to allow them to test the new motor. Once again, at the SCADA level they'll still need to be acknowledged before they go away, so you know they've been seen, but it's just a simpler way of testing the motor than going "reset - oh, hang on, have to acknowledge the alarm first - alarms screen - acknowledge this alarm - acknowledge that alarm - back to the main screen - find the motor popup - reset - now let's try that test again - whoops, forgot to turn the isolator back on, guess I'll have to go through that whole process again". Instead, you reset, test, and then acknowledge all the alarms once you're done testing.

There are of course different ways to achieve the above examples without the need for a program acknowledge. But hopefully that gives you a bit of an idea as to why it might be used?

Okay great, those responses answer the question.

What was the missing feature you implemented, by the way?

JeremyM said:

Okay great, those responses answer the question.

What was the missing feature you implemented, by the way?

Click to expand...

ASF said:

If there are any unacknowledged alarms, the alarm indicator flashes and the siren sounds.

Click to expand...

Try and achieve that functionality using the existing ALMD instruction. Assume you have several thousand alarms and aren't terribly interested in a parallel branch thirty metres long.

ASF said:

Try and achieve that functionality using the existing ALMD instruction. Assume you have several thousand alarms and aren't terribly interested in a parallel branch thirty metres long.

Click to expand...

Yup.

I found out pretty quickly during this project that I would need to be able to group (and monitor, and manage, and notify, and record, and add, and retire!) potentially very many alarms in a robust and predictable way. Developing something like this has been quite the challenge since it crosses the domains of controls, safety, and computer science.

The header file alone is in excess of 500 lines... perhaps it could double as my Capstone project.