Alarm rules based on tag property values or other tags

[andre.buurman@carya]

Hi,

Is it possible to create alarm rules based on property values or values of other tags?

At this time I see a possibility to create an alarm child tag for a tag and use that to trigger an alarm for that tag. This would require code in my target to apply the alarm logic.

It would be very clean to be able to use tag properties or values of e.g. child tags to configure alarm rules.

[GreyGrey]

At this time, it is not possible to use tag properties to trigger alarms. I'm not sure that I understand the use-case that would require the use of property values to trigger alarms. Tag properties are usually used to store more static information that may add context or organization to your tags and are less used to store values that frequently change. If you are wanting to store and frequently change multiple values on a tag, I would usually recommend using two separate tags. 

I do see how being able to use properties to build more complex alarm strategies would be useful. For instance being able to indicate 'child tags' which may also have to satisfy some criteria before the alarm is triggered. For this use case, you would have to write a small application or service that could run, monitor multiple tags, and based on your logic, write to a separate tag which would trigger the alarm. You could also write to that tag's properties with other tag's values to provide the alarm with more contextual information that you could send via email. 

Can you provide more context as to where being able to trigger alarms off of values of tag properties would be helpful? 

[andre.buurman@carya]

Hi  Brandon,

I'm basically trying to figure out how to organize my tags in such a way that I only need to define 3-5 alarm rules for all my tags (e.g. tag name template/regex). In addition the customer wants to be able to select which tag-alarm rule combination actually triggers a notification (e.g. enabled by property or child tag).

Consider these alarm zones. Zone B and E are normal values, although E has a time criteria making it an alarm after 15 minutes. Zones A and D are genuine alarms, although it could be that D has a sample when going from B to E and back. C is a warning zone which is triggered after a number of consecutive samples in that zone.

The limit between A and B may be adjusted to be different for section (unit to be monitored).

The limit between B and C will be different for each section.

The other 2 limits are fixed.

Each section has these limits, they are 

alarm levels

I'd like to prevent configuring 800+ times 3-5 alarm rules times 2 in case I want alarm, but not a notification.

For this I think I need:

1. A tag search regex

2. A set point that can be another tag (for limits that are the same for all tags) or tag property (for limits that differ for each tag)

3. Ability to enable the notification strategy using a tag property

[GreyGrey · Accepted solution]

Currently you can perform a search for tags that will be used to trigger an alarm. For example, if have multiple tags named "tag1", "tag2", "tag3", and "tag4", in your alarm rule configuration, you are prompted for a 'Tag Search Path'. That search can return multiple tags. To capture all four tags that I mentioned, you could put "tag*" as your search path, and if a value change on any of those tags matched the condition that you set in the alarm rule configuration, it would trigger that alarm. That can be used to limit the number of alarms that you have to set up as long as you use name your tags in an organized fashion. 

Regarding the interaction between tags and tag properties, that isn't currently implemented but we appreciate the feedback!

[andre.buurman@carya]

Thanks,

Could you provide me some more insight road map wise when these option could be implemented? If not public, maybe through DM?

These options would make the alarm rules a lot more flexible and prevent me from implementing a work-around in code.

[MarkBlack]

Hi Andre, 

While I cannot make a firm commitment on schedule, we are currently we are scheduling this work for our 18.5 release (early 2019). I like to get your feedback whether the workflow we are designing would be sufficient for your needs. 

User Goal

To associate alarms to tags based upon a tag property and/or keyword (rather than tag path exclusively) such that tag path conventions do not have to change in order to ensure the tag has the correctly associated alarms or duplicating alarms due to differences in tag paths. 

Workflow

1. User creates a new alarm rule
2. User provides a name and description of the rule
3. User provides a data type for the tag
4. In the new Match Criteria section
1. User determines the match criteria by selecting tag path, property, or keyword from a dropdown 
2. User enters value in the available fields that are appropriate for that match criteria
3. User optionally chooses to add another match criteria
4. User chooses whether this match criteria should be AND or OR with the results returned by the previous match criteria(s). 
5. User repeats steps 4.1 - 4.5 as needed
5. User configures the remainder or their alarm rule. 

Requirements 

• Match criteria are evaluated in the order they are listed. Subsequent match criteria are evaluated against the results returned by the match criteria immediately preceding it. 
  
  • e..g (((a -> b) -> c) ->) d
• Search path is removed from Alarm rule grids since its no longer guaranteed to a field used for match criteria 
• Tag section should be renamed to match criteria. Tag Data type should be pulled out and made into its own section. 

[andre.buurman@carya]

Hi Mark,

I think I understand the workflow you are describing, however find it a bit difficult to visualize how it would look like.

I think I miss the possibility to use a tag path/property/keyword as value in the match criterium.

E.g. consider the following tags:

Generic.pipe.alarm.temperature.HH (this is generic alarm that is valid for all temperature sensors of pipe)

Pipe.sectionA.temperature

Pipe.sectionB.temperature

Pipe.sectionC.temperature

Specific alarms as tags:

Pipe.sectionA.alarm.temperature.H (This value can be different for each section)

Pipe.sectionB.alarm.temperature.H

Pipe.sectionC.alarm.temperature.H

My HH alarm rule would be: Pipe.section*.temperature >= Generic.pipe.alarm.temperature.HH

My H alarm rule would be: Pipe.section*.temperature >= Pipe.section*.alarm.temperature.H (This definition is a ambiguous now)

Specific alarms as tag properties:

Pipe.sectionA:alarm.temperature.H (This value can be different for each section)

Pipe.sectionB:alarm.temperature.H

Pipe.sectionC:alarm.temperature.H

My HH alarm rule would be: Pipe.section*.temperature >= Generic.pipe.alarm.temperature.HH

My H alarm rule would be: Pipe.section*.temperature >= alarm.temperature.H

Drawback is that in case a property is updated in the SL API it is immediately sent to the server, I would like the option to prepare all updates and then call the method that sends everything to the server. Like multi-write tags, but also including properties.

[MarkBlack]

André, 

Thanks for the clarification. I want to make sure I understand this correctly. You find value in the ability to match tags for an alarm rule based upon tag properties and keywords. Beyond this capability, you'd like to be able to use tags or tag properties for the values used for the set point within the condition statement.

I will need to discuss with my team regarding the possibility of using tags and tag properties as the set point (and potentially other parts of the alarm condition statement). An alternative that jumps to mind is a better G API for alarms that would allow setting condition fields in code. But perhaps even with that you would want the capability to "bind" these condition fields to a tag so that you might change one tag value and update multiple alarm rules?

One other input I would like to share than might influence your feedback, we are also planning (for the same aforementioned release) to allow for multiple severity levels for a single alarm rule. This would likely take the form of enabling the creation of multiple condition statements within a single rule. 

[MarkBlack]

André,

I actually want to take a step back and talk less about how you or I think we could solve a particular problem and instead better understand your goals and (hopefully) align those goals with the largest collection of users. Can you tell me how much you align with the following goals:

I want to be informed of the severity of an alarm such that I am informed differently and react differently depending on that alarm severity. 

I want to create as few alarms as possible that can be applied to as many tags as possible such that the effort to create and maintain alarms is as low as possible.

I want an API for alarms rules so I can automate defining and modifying alarms. 

[andre.buurman@carya]

Hi Mark,

I fully align with the those three goals.

And I believe that there are more than one way to reach those goals.