Well before we get started programming alarms we're going to talk about something that's even more important
and more fundamental and that is consideration before we start putting any logic into a program.
The first thing we really need to do is stop and think and plan how to program alarms and notifications
for each and every system.
The reason is there are several factors that you want to consider and not all alarms and notifications
are alike.
The first consideration on a programmer's mind is always safety.
What alarms do we absolutely have to have no matter what.
What are the alarms that have to be in our program.
And obviously for anything critical we want to notify an operator but there are limits to all of these
things.
We don't need an alarm for every single thing that happens in our system.
There are certain things that don't affect the process that don't endanger anybody they don't damage
equipment.
And even though you have an analog signal coming in you might not need a high high and or low low alarm
condition just because you know how to program and LLN and H.H. doesn't mean you need to.
Every single time.
Also you want to be particular about what notifications you provide your operators if you give them
an abundance of notifications for everything that happens every day in a system.
They're probably going to start looking at them after a few days in which case anything important that
you try to notify them of is going to be lost and they're not even going to know what happened.
They're going to hit a reset button here a clear button hit an acknowledged button and make your important
notifications disappear with all the garbage that you decided to put into the system.
Just because you know how to do it more is not always the merrier.
You have to take consideration.
What does the operator need to know.
What does the operator want to know what's beneficial.
What is going to keep people safe.
What's going to keep the system running the way that it's supposed to be running.
Take into consideration how your alarms are actually going to function and how your notifications are
actually going to function.
For instance if a problem occurs at 3:00 in the morning when nobody is monitoring a system let's say
a part of your system is going to shut down.
Well if that condition resolves itself automatically do you really want to leave the system shut down
for six hours until somebody comes in to look at it or if the problem goes away on its own and it's
nothing too critical.
Would it be smarter to let the system go ahead and resume operation.
Well consider that system might be filtering drinking water for a small community.
Do you really want them to wake up in the morning and not be able to take a shower because maybe at
one point in the night your tank level got a little too low that's going to seem really silly when the
operator comes in in the morning and the tank is full and everybody's yelling at them because they don't
have any water.
Obviously if the tanks are running low that's something the operators are going to want to know about
.
Maybe he's going to need a larger pump or a secondary pump for times of high demand.
On the other hand you don't want to leave the system shut down if it's not critical.
On the contrary if you have a boiler that's getting out of control and heats up to a high high set point
you probably do want to shut the system down and leave it down until an operator comes in physically
interacts with that system.
Otherwise somebody could die.
So while consistency is oftentimes desirable especially when it comes to a learning curve for a new
system if you have 20 or 30 alarms it's not necessarily reasonable that all 30 of those alarms are going
to work exactly the same.
Some of those conditions might be able to reset themselves.
Others might require an operator to interact some of those notifications can probably be silenced.
So they're not perpetually annoying an operator on the other hand some of those notifications might
be a little bit more persistent and depending on the nature of the condition.
So before we start programming before we started dropping logic and XICs and TEONs.
Let's take a minute.
Consider our process.
Consider our operators needs and really think hard about what alarms do we need how are those alarms
going to work what notifications do we need.
Who's going to see those notifications and so on and so forth doing that in the beginning is not only
going to save you a lot of rework down the road it's also going to make you a much more popular programmer
with your own company and with your customers as well.