Many times we have an alarm point. Let's say we have a Boiler, many times on the boiler there is a bool point that wires back to the controller and it is labeled alarm.

I'm worried about using the exact name "alarm" as some systems out there might think it's part of their alarm system. Maybe we should come up with something like:

alarmMode alarmable

Just my 2 cents.

So a boiler alarm might look like this

boiler

alarmable

sensor

point

and a pump

pump

alarmable

sensor

point

Jason, could you provide few more details for me and everybody else:

• so this a boolean input point?
• what might be the physical manifestation for this point in a boiler or pump? Is it a software point that is internally comparing the command to some sensor sensing temp, pressure, or flow?
• is extra information ever provided some as some summary message string?

Typically this point would be the same on let's say a Chiller, Boiler, VFD, etc... Most of the time it's just a digital input that is on or off. Meaning, it's in Alarm, or not in Alarm.

However, there are also Boilers and chiller's that send out an alarm as an enum or string over the wire. I think this should just be handled as a custom solution, as this typically isn't a standard.

So my vote is to call it alarmable, and it is just a digital input.

I personally think alarm sensor makes more sense than alarmable. I think this also what Nick posted in some his examples

Yeah, I would say alarm is better too

Mmmm, but how do you cover the case where (like in Niagara) we have out of range alarm extensions on numeric points.

The point is alarmable but the exact value or state of the point doesn't indicate that it is in alarm.

There is some crossover here with the override concept/issue from previous posts.

It depends on how the system is programmed. Sometimes you have specific alarm points like Jason has illustrated, in other circumstances you take the sensor point and make it alarmable.

I'm not sure we've really got this captured.

Both alarm sensor and alarmable are valid tagging semantics to my way of thinking.

Currently, we're using alarm sensor to indicate a boolean (or enum) point that is coming from the device whose value represents an alarm status or alarm code. Typically these are not software points, but I suppose they could be done that way (for example: with a status demux block in Niagara).

We do not currently have any tagging established for tagging points with alarm extensions. If we did want to know this information, I would think alarmable would be an appropriate tag for any point with an alarm extension.

Recap:

• alarm sensor
  • Point whose value represents an actual alarm status or code
• alarmable
  • Point on which an alarm condition could be triggered
  • Value does not represent alarm status/code

If we want to standardize alarm sensor for right now as a Bool or Str enum point then I'm fine with that. However, it barely scratches the surface of alarming and has the potential to conflict or put into a corner when we try to model alarming more holistically.

So what is the vote? Is everyone okay just standardizing alarm sensor for now?

Has this been resolved on the alarm?

How about "alarmTrigger" this will allow for a numeric min or max alarm as well as boolean or strings.

Just a suggestion.