Asset hierarchy lost when replicating from Historian Tier 1 to Tier 2?

Hi! We have a large customer who is planning to replicate many Tier 1 historians to a regional Tier 2 Historian as part of their global digitalization program.

They complain that the asset hierarchy is being lost on Tier 2. Under "Replication Sources" there is one folder per Tier 1, with a flat list of thousands of tags.

Navigating such a flat list in Historian Client makes navigation a nightmare.

They have invested a lot in building a global naming convention and asset structure across sites and really wants to keep the asset structure from the different sites.

I know that the asset hierarchy address is available as an extended property being replicated to Tier 2, but it does not help the user experience.

The customer suggests a workaround where they rebuild the hierarchy on Tier 2 based on meta data, but I foresee that this is going to be very difficult to maintain over time.

Any ideas or solutions to this would be highly appreciated.

  • There is not currently a great solution for getting the namespace hierarchy from a "tier 1" to a "tier 2" for use with Historian Client Desktop (e.g. Trend and Query). 

    You did mention the "Location" extended property does include the same information and that is automatically propagated to the "tier 2", but it is only really useful with the search functionality in Historian Client Web and there is not a way to visualize the hierarchy. 

    As suggested by the customer, it would be possible to recreate the "Public Namespace" from the extended property using SQL (or an external program). If you make an attempt at that, a SQL "Common Table Expression" (CTE) might be helpful (this example creates a path from the namespace--you sort of need the reverse). Also plan some means to clean up "orphaned" namespace entries (e.g. after initially creating the hierarchy, area or object "Foo" is renamed as "Foobar" might otherwise leave "Foo" behind in the namespace).

  • Thanks for very fast response Elliot.

    You are correct, that is the exact problem. To me it seems to be a UI issue in the desktop clients, and not with the historian server or replication itself. The information to build that tree structure is clearly available. Can this be expected to be available in near future releases or should we advise the customers to use the web client?

    I guess it would make sense for local power users/admins would have the desktop client and have access to the tier 1. For the general office user the web client get data from Tier 2 might suffice. Not sure they will love the idea…

    In your experience with the orphans, are they coming from the location extended property not being updated if you rename an object or is it coming from not monitoring the location for changes?

  • On roadmap questions, I make a distinction between "ideas" (features we'd like to add) and "plans" (which have an assigned budget, schedule and staff). Using those definitions, we rarely have "plans" more than 3-4 months out (a consequence of our "agile" philosophy). In this specific case of replicating the hierarchy for Trend, there are no "plans". 

    Though this isn't a "one size fits all" answer, I'd expect Historian Client Web to be a better fit for a lot of "tier 2" users. 

    Finally, the comment about handling renamed objects/areas was meant as a design consideration, should you decide to implement a custom mechanism to populate the hierarchy. Those renames do come through to the "Location" just fine, but your implementation would need to consider that case so it doesn't leave behind the clutter of the old name in the hierarchy. The native "tier 1" namespace hierarchy has some problems with this case occassionally, too. 

  • Thanks for the clarifications. We will discuss this further before making any decisions.