Easily create derived tags

We are working through a tag-naming and tag-folder-organizing problem. i think this is a common goal, but haven’t seen an easy way to do it.

Goal:

Have a tag tree that allows us to view machines in a number of different paths. Let’s say there are 50 tags related to one of our stamping presses … commonly known as StampingPress Baker10. It was made by ACME Corporation, Model DEF, and has SN 12345

  • Location: the path to the tags would be State\City\Plant\Area\…\CommonName
    • Coyote\PlantA\AreaB\SectionC\StampingPress\Baker10
  • AssetTracking: the path to the tag would be based on function, manufacturer, model, serial number
    • StampingPress\Acme\DEF\12345
  • MaintenanceTeam: the path would be just a list of tags by CommonName
    • Maintenance\Baker10

We are familiar with derived tags … but … was wondering if there’s a way to more easily create a folder of derived tags (i.e. select a folder … click on COPY … have an option for PASTE … PASTE AS DERIVED

Notes:

  • We do understand that we could just create our own database of tag paths and then mix/match as needed. But we think (?) that there will be value in having these alternate views of the machine embedded in a tag tree instead of a database.
  • We have a UDT that is supposed to be instantiated with each asset, that tracks Mfr, Model, SerialNumber, GlobalTrackingNumber, Category, CommonName … so we CAN devise a method of re-arranging the “view” based on the contents of that UDT.

What do folks do about this?

I would make one UDT instance using a unified namespace, like your "Location". I would include the other metadata as custom properties on the UDT instances, and maintain an in-memory cache of metadata strings versus UNS tag paths. (I've helped clients do similar with my globalVarMap() function from my Integration Toolkit.)

Make your UI components accept UNS tag paths. Make navigation views per hierarchy, traversing the desired tree.

FWIW, I also recommend that plants in an organization be given short unique codes to use in place of State/City/Plant, and use them as tag provider names. Maintain a separate static index of tag provider names versus State/City/Plant. It is then easily extensible to include Country, and if you make your remote tag providers use them too, everything 'Just Works'.