Recommendation on Canary tag names for multiple purposes views
Hello Canarians,
I've been trying to come up with a good way to manage Canary tag names that can manage multiple views that we would need to build. We need to satisfy at least three different hierarchies:
- Physical View (for example: country.plant.floor.unit type.unit.tags, like SE.Umea.F01.Blenders.BT2.Speed)
- Equipment View (for example: unit type.unit.tags, like Blenders.BT2.Speed)
- Process View (for example: process.unit type.unit.tags, like LiquidMedia.Blenders.BT3.Speed)
In bold is what we would get from the OPC Server (Device.Tag)
The two main questions/dilemmas I have are:
- How to name the Canary tag. What's coming out of the OPC server will not be sufficient as the tags will be named by what it represents, and not necessarily with an "encoded" set of characters that can be used to build views. At first, my line of thought is to build a naming convention based on physical assets (like country.plant.floor.unit type.unit.tags, similar to first bullet point above).
- How to build the Process View. An Equipment View can easily be built based on a physical asset naming convention, as it's just a "portion" of the entire tag name. However, the Process View is built on what's being used on a particular process, say 1 blender, 1 mill, 2 water tanks (which may be in different physical locations and are totally different pieces of equipment). I believe this could be achieved by a set of "exclude" rules in the Canary View definition (I have not tried yet though), but wondering if any other practice is around to build such cross asset view. Any examples are also very welcome.
Thank you
1 reply
-
Hi ,
If there isn't enough information in the tag path to build the desired hierarchy, we allow you to include tag properties for this very reason. These could be properties that come from the data source and Collector, properties that are managed in an external MSSQL database, or a combination of both.
If you're using the OPC Collector, you can only include properties if you're using Tag-Based sessions. (Path-Based sessions do not support property consumption.)
When tag properties are included in a virtual view, they are appended to the end of the tag path and separated by ##'s (i.e. DataSetName.BT2.Speed##Poland##Warsaw##Blender). You would then create regex rules that target the property value strings to create the desired naming convention. If a tag does not have the property, it would appear as ##NA.
With the Process View, I'm not sure how this would work as it seems that this would be changing often, no? You could potentially have a Process property set to 0 or 1 which you could build a regex rule to exclude if they're set to 0, but any Axiom dashboard or calculation that is built on the view would break once the view changed.
Print this page