nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Nested Subnetworks in Electrical Model

SergioOM

Hello everybody,

I am aware that the Electrical Model is Partitioned, but I am trying to replicate somehow the Circuits within the Distribution Tier the same as they were modelled in a previous GN Model of a client, where for example a Service Point could have two Feeders (CB), belonging this way to two different circuits. So, when trying to replicate same behavour into the UN, this obviously creates only one Subnetwork feeded by two Subnetwork Controllers (CB). Then, I try to Modify Controller and change the Subnetwork Name to see if the field Subnetwork Name of the Assets downstream changes to both of them (This way behavour would be kind of replicated) and when I Update Subnetworks it works just fine. Here you see the field Subnetwork Name of an Asset downstream of the CB with different Subnetwork Names, both from the Distribution Tier:

Until now, everything works as expected, I even inserted an extra Directional Switch under the CB in order to prevent the flow from one CB reaching the other one. So, now when I try to check the Subnetwork Controllers feeding this Asset using the Trace tool, the error 001890: Invalid subnetwork connectivity, multiple subnetwork controllers with different subnetwork names found is populated.

My question then is:

If the tool Update Subnetwork worked just fine and populated the right attributes in the right fields , giving the two subnetwork Names to the Asset (Circuit1::Circuit2) but also, it correctly created the two features into the ElectricSubnetLine with its geometry. Why the Subnetwork Controllers or Subnetwork Trace Tool doesn't do it as well? I understand that, if this is not possible in the UN because in reallity is like that, the Update Subnetwork shouldn't work as well, should it?

Thanks for your help 🙂

Trouver plus de publications taguées avec

Accepted answers

JohnAlsup

It sounds like this is a case where you have multiple wires you want to represent as a single line, which is going to be an issue in the Utility Network, as the UN is designed to model physical assets. So, to accomplish this you could create a container feature, like an aerial span, where it contains the two lines from the two different circuits. The other option is to make all your lines containers and make all wires non-spatial content, but I would not suggest that, as it would be a bit more complex to edit.

JohnAlsup

Assuming this is not a mesh network, but two separate circuits, then normally you would have an switch that connects to both circuits just before the service. It is typically called a Source Selectable Switch or Automatic Throw Over Switch. This switch would have three terminals (two upstream). Then the terminal path on the switch would set to only provide a path to one source or circuit at a time. Then the service is only part of one subnetwork at any time.

All comments

RichardKoch

Pierre,

few questions -

How often do these lines change from one SN to the other?
Is having both names on the line driving reporting or some downstream workflow or process?

Richard Koch

JohnAlsup

Hierachical won't help you here. You will have to make this two seperate lines.

PierreloupDucroix

In this case, there is only one physical line (containing multiple wires, but as you suggested, I will not model non-spatial content) but two different circuits can pass through this line... This is the reality of the field.

I am thinking about switching to a hierarchical model, and then to have a tier for MV, and a tier group for LV containing one tier for LV electric distribution and one for LV Streetlight.

Do you think it makes sense ?

RichardKoch

Based of Johns reply above I am unsure how "both" feeders are connected at the same time. I can see an either/or situation like at any TIP POINT. One part of the line is NORMAL configuration as to what SN energizes it. Which brings me to my point. for our model the GIS is system Normal, and the OMS/NMS is system AS OPERATED.

In the example above you need a second device at the left/east end (intelligent or manual?) that tells L and ABC that each is no longer tied together unless I am misunderstanding the configuration.

JohnAlsup

PierreloupDucroix

Hi,

I have a similar case, where some lines in my network share conductors from two different circuits (one LV and one Streetlight) coming from two different feeders...

Here is a drawing of the case :

As you can see, the middle line is composed of several conductors from the two feeders, with or without a shared neutral. In this case, that middle line will get both subnetwork names, and the rest will have only one. Note that I do not model each conductor with edge objects.

I found it pretty similar to the topic described here, and wonder if this can be modeled with the partitioned domain.

JohnAlsup

Does the downward leg to the service actually (electrically) belong to both circuits? The only way I could think of that being the case is it were getting one phase from CB 1 and another from CB 2, which is probably not what is occurring. Is it actually the case where you have two physical lines running down to the service, each a separate line?

SergioOM

Sorry, I put the example of the Service but the thing is that what we are having now is all Assets within the two circuits with the information of the both Circuits stored in Feeder IDs fields. The schema of what I want to check if it is possible is the following:

Nowadays the Feeder Manager of ArcFM working against the GN allows to have 2 or more feeders supplying any asset downstream of the CB, having different IDs for any additional circuit. In the next example we see an Asset having two different circuits:

At the end, I would like to know how to properly model this in the UN because apparently, even if at the first glance, the Update Subnetwork allows to do it and populates correctly both the geometry and the two records in the ElectricSubnetLine and also it fills the field "Subnetwork Name" of all Assets downstream the CBs as well, the Tracing fails because of the error already commented above.
So at the end, either it is not possible to model it like that (and I understand because the power is actually coming from both of them) but then, in my opinion, the Update Subnetwork shouldn't work as well. Or, if it would be possible to do it so, then the Tracing Tools should work as well.

Hope I did myself a bit more clear and I really appreciate all your comments regarding this topic:)

JohnAlsup

Hi Richard

Responses

#1) We do not have an example of this in the sample data, but I will make sure to add this.

#2) The subnetwork name of the service would only get one subnetwork name. The subnetwork name of the switch would get both. What you could do is add a new asset type to one of the Service Asset Groups and assign it a terminal configuration with three terminals (two upstream terminals) and define the path like what is shown in this diagram and then assign this terminal config. Then connect the each of the incoming circuit lines to each of the upstream terminals such that each terminal is connected to only one line.

RichardKoch

John,

Does ESRI have (or could they provide) an example of this in the Naperville data?
Would this setup give the naming on all features as outlines in the original question (Circuit1::Circuit2). I cannot remember if there were character limits on SN naming at this point from when we did our setup.

Our Open Tie switches do name out like the user mentions. Keep in mind that they are that open point between. All the other features have only the SN name of one circuit or the other.

JohnAlsup

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.