We're looking to start doing some alarming, on fairly simple tags. EG, fill level above a threshold. I was reading through the manual on alarms, and was interested to see that the alarm associated data page says the following
The third way, and the most recommended way, is to use associated data. It's a common design practice to associate alarm groupings on the associated data of the alarm.
One of the planned use cases for the alarms, is to trigger a set of lights if any are active and unacknowledged within a building. So, we want a simple way to group the alarms by building, and then have a tag which becomes active when there are any alarms in that group. The natural way to handle this is with isAlarmActiveFiltered
.
However, this expression does not provide a way to filter based on alarm associated data, meaning all of those tasks would need to be delegated to scripting. What advantages does associated data provide for grouping, over using the displayPath property?
Associated data is another layer of customization that allows for custom grouping unrelated to the tag path source. Not everyone structures tags well.
You are correct that having a well defined and standardized tag structure will yield an effective way to filter alarms as well and will give better access to that expression. It depends on your system and structure, but you may not need to use associated data.
That being said, associated data is a useful tool because it is available for filtering in most of the major alarming locations: alarm pipelines, alarm status tables, alarm journal tables.
Even if the tags are laid out messily, isn't it still possible to make a clean alarm display path out of them, and display them like that?
Eg, some of our tags are in weird places, but all of our display paths match the format buildingName/MachineName/alarmName -- so we can match any overflow alarms in building alpha by using "buildingAlpha/*/overflow"
Any display path hierarchical organization only allows one hierarchy.
You could have display path based organization working great - then someone decides they want an alarm summary for all pumps. If every pump related alarm is tagged with associated data, that's easy. If it's not... it's not.