Hierarchical Tiers for Electric Distribution Network?

[EstherSmith_Dev]

Hi,

I have a question about the exact differences between Partitioned and Hierarchical tiers.

I have a read all the documentation and numerous threads here.

The documentation at https://pro.arcgis.com/en/pro-app/latest/help/data/utility-network/tiers.htm shows the differences with nice graphics. However, it mentions that 

• Partitioned—Supports systems that are sequential in nature, such as electrical and telecommunications utilities
• Hierarchical—Allows you to model networks that are nested, such as gas and water networks

Does it mean that electric and telco networks have to choose Partitioned and gas/water have to choose Hierarchical?

The graphics for "partitioned" tier shows only "radial" network while graphics for "hierarchical" tier shows "mesh" network. But the same document says 

• Radial—Consists of one or more subnetwork controllers
• Mesh—Consists of one or more subnetwork controllers

Note:

The topology type currently does not provide a difference in behavior for tracing or subnetwork management. The functionality is under development and will be applicable in a future release.

(Curiously, above note is present from day-1 of the UNM model documentation)

So, apart from hierarchical tier having multiple subnetwork name attributes and asset belonging to more than one tier at the same time, what is the difference?

In Electric Network, we have a need for EHV, HV and LV tiers (standard Australian model). And we need to denote each LV asset with EHV, HV and LV tier it belongs to. One way is to define the model as 

1. "Electric" domain,
   • "Electric Distribution" hierarchical tier group
     • "EHV" tier with rank 1 and EHVSubnetworkName attribute
     • "HV" tier with rank 2 and HVSubnetworkName attribute
     • "LV" tier with rank 3 and LVSubnetworkName attribute

Then by identifying any LV asset such as electric meter, user knows which transformer it is fed from (LV tier's Subnetwork Controller), which feeder it belongs to (HV tier's SNC) and which zone/terminal transformer it is sourced from (EHV tier's SNC). For HV assets, LVSubnetworkName will be empty/unknown.

Will I lose or compromise any UNM functionality if I configure Electric Distribution Network like above? Is the performance of UNM editing, tracing upstream/downstream, running Update Subnetwork impacted?

Thanks,

[SahilBhouraskar]

-

[gis_KIWI4]

 @EstherSmith_Dev  Excellent Question!
My understanding is that the key difference is that in partitioned network a feature can only exist in one tier at any given time, meaning the tiers are sequential and not overlapping. 

Hierarchical Tier a feature can be part of multiple tiers. Essentially a subnetwork within a subnetwork. 

Example - An Electrical switch can only be part of EHV or HV Tier any given time whereas is if you were looking at a gas utility then a valve could a part of the one or more tier (pressure and isolation zone)

What you are suggesting could work in theory.
So your LV service (meter) would be part of all 3 tiers - EHV, HV and LV
Distribution Transformer would be HV and LV and so on. 
One consideration here would be working with the UN. Say you wanted to extract or trace EHV section of your network. EHV subnetwork now contains the whole network (HV and LV too), you would then have to set up all feeder circuit breakers as barriers. Not to mention the naming might also prove confusing EHV Tier contains LV and HV. 

Tracing should work and as mentioned the Tier Definition doesn't have any effect.
The only change would be that'd be tracing an entire Tier as opposed to Tracing from Start Tier to Target Tier.

Although something that did catch my attention. Hierarchical Tiers only support mesh topology. 
I wonder how you'd model your HV and LV circuits which will most likely be radial.

https://pro.arcgis.com/en/pro-app/3.3/help/data/utility-network/network-hierarchies-with-tiers.htm

Have you tried foundational model for gas or water and just reimagining it as your electrical network to see if it works? 

[gis_KIWI4]

@EstherSmith_Dev Also found another thread that might be of interest to you. 
https://community.esri.com/t5/arcgis-utility-network-questions/electric-unm-queries-with-migration/m...

Robert K mentions this might be bad for performance. 
John A said there is Hierarchical model for Transmission Systems. 

If I had this problem statement then I would set up a partitioned network as this works and aligns well the concept of an Electrical Network.

I would then schedule an overnight script to trace subnetwork controllers of each tier and append the subnetworkname to new fields EHVSubnetworkName, HVSubnetworkName, LVSubnetworkName.

[EstherSmith_Dev]

@gis_KIWI4 Thanks for your responses.

I have had few Electric Distribution and Transmission UN clients and all are implemented as "Partitioned" domain. Never had a courage to go against the advise / best practices and implement as "Hierarchical".  Now starting with a new client doing GN to UN and same questions/problem have re-surfaced.

I am aware that we can configure a pop-up using Arcade and provide the names of parent, grandparent and great-grandparent Subnetwork calculated on the fly. And we can always calculate them using a nightly process as you mentioned. However, pop-ups only work in ArcGIS Pro and web maps but not when querying data using GDB / REST for interfaces to EAM etc. It is better to have EHV and HV subnetwork names persisted in the geodatabase (and is one of the requirement). And we are trying to avoid "nightly" processes as much as possible.

One option is to include subnetwork name in the next level SNC e.g. Distribution Transformer that acts Subnetwork Controller for LV assets will have its Subnetwork Name including parent HV feeder e.g. "Feeder123-TFR1" or "ZZZSubstation-Feeder123-TFR1". But, there are possibilities of Feeder Transfer where by part of the feeder is moved to another feeder to manage load, new subdivisions etc. Then "Feeder123-TFR1" becomes wrong if the transformer TFR1 is moved to Feeder124 using some switching operations. We will then have to drop Subnetwork "Feeder123-TFR1" and recreate it as "Feeder124-TFR1", a bit of overhead.

Thanks,

Vish

[gis_KIWI4]

@EstherSmith_Dev  - You are spot on with your comment about NOT wanting to include the preceding tier's subnetwork controller name in the current one. This is guaranteed to have overheads when the switching changes.

Fair comment about nightly processes and arcade calculated fields. 

In theory, I think what you are proposing should work but it will be interesting to see if others have had success following this route. 

[EstherSmith_Dev]

And good point about EHV subnetwork trace containing HV and LV assets in traces. I think it can be managed by creating named trace configurations e.g. "EHV Only" that stops when a tier is crossed, subnetwork controller is encountered or certain asset type is encountered etc.

[Jens_Dalsgaard]

Following Esri Inc recommendations, which is typically wise, and using partitioned tiers for your electric grid, there might be a way around your need for 'denoting each LV asset with EHV, HV and LV tier it belongs to'.

The answer, I believe, lies in in not actually writing the EHV- and HV tier names onto the low voltage feature yet still offering this information to the end user using attribute (Arcade) expressions - results of an Arcade script appearing to the user just as any other attribute in the popup. https://developers.arcgis.com/javascript/latest/sample-code/popuptemplate-arcade/ 

You would then add such Arcade attributes revealing the names of the EHV- and HV tier feeding the LV tier feeding the relevant feature.

[SamDeLore]

You definitely can structure it that way, being a water utility, that is how we've structured our UN

(Water Source > Treatment > Supply > Pressure).

But there are some considerations, your higher tiers are going to be really big & you need to be very explicit in what constitutes a barrier for those tiers or not

You also need to be very careful about the lines you include in the subnet line aggregation, EHV & HV are going to have many parts to the geometry, any maps your subnet lines are included in, will suffer for having subnet lines in them.

Your subnetwork build for the higher tiers is going to increase quite a bit in processing time and any topology errors at any point of the network will prevent every tier that finds that error feature from building / tracing.

For other creative ways to do this with a Partitioned network without the use of popups etc...

I wonder, if you have a domain for your feeders, could look to use propagation to pass the values down via network attributes? You would need to do a bit of data model work, I think it would be possible, but it's not really the intended use for that function.

The temptation is to use attribute rules, but firing rules with subnetwork process can really hit performance

[EstherSmith_Dev]

Thanks @SamDeLore, all are good points to consider. I understand that subnet line geometry for EHV and HV can be really big and can cause degradation of the mapping (zoom/pan) experience and also subnetwork build times can escalate.

Re. propagation, I believe propagation works only for the numeric attributes and not for text fields. We will need to introduce numeric codes for feeder ids and zone substation ids and bind it to attribute domain. But worth considering...

Thanks,