ArcGIS Utility Network

Managing Electric Networks: Updating Subnetworks

In our previous blog, we discussed how subnetworks in the utility network are configured using the Electric Utility Network Foundation. In this blog, we are going to dig into what happens behind the scenes when you update a subnetwork and what types of data errors it can detect and report as subnetwork errors.

It is important to understand what these errors are and how to correct them because these errors will prevent you from exporting your subnetworks from the GIS for use in other systems. The reason we require you to fix these errors before you can export data is that we know that these errors will either prevent us from being able to correctly extract the subnetwork or they will prevent downstream systems from being able to import/process the data correctly.

Update Subnetwork

Update subnetwork is the primary operation used to update and validate subnetworks in the system. You can learn more about how this tool works in the update a subnetwork section of the online help.  At a high level this operation performs the following tasks:

  1. Validates the consistency of the subnetwork to ensure there are no dirty areas present on the subnetwork.
  2. Validates the network topology and the contents of the subnetwork conform to the subnetwork definition. Subnetwork errors will be created for any issues encountered.
  3. The last modified date of the subnetwork will be updated in the subnetworks table.
  4. The subnetwork line (SubnetLine) will be updated to reflect the latest features and calculates, as defined in the subnetwork definition
  5. The features that participate in or support the subnetwork will have their attributes updated to indicate their relation to the subnetwork.

This operation is most commonly run from the Find Subnetworks pane, shown below, but can also be called using the geoprocessing tool or using any of the APIs provided by Esri for interacting with the utility network services.

Updating a subnetwork using the Find Subnetworks pane

You may have noticed that each of the subnetworks in the dialog has a Status column. When you are updating a subnetwork, the subnetwork must be in a dirty state, indicated by a yellow triangle. Because you cannot the update operation, you must also save your edits before the tool will appear as enabled. You can learn more about using the find subnetworks pane in the find a subnetwork topic in the online help.

Subnetwork Errors

When the update subnetwork operation a subnetwork error it will create an error dirty area in the database associated with one or more error codes indicating the type of error discovered. You can find the full table of utility network error ids in the online help. Below is an abbreviated version of the table that describes the most common errors:

Error Type Error Description Resolutions
Invalid Equipment 24 / 26 / 40 / 41 / 42


An invalid feature was discovered during update subnetwork.

1.      If the affected features have been drawn correctly and should be allowed to participate in this tier of the network, then your geodatabase administrator can update your subnetwork definition to allow them to participate in this tier.


2.      If you determine that the features have an incorrect asset group / asset type, then you should correct their classification.


3.      If the features are correctly classified and should not participate in this tier, then you will need to correct your data to prevent them from participating in this tier.

Inconsistent Network Controller 29


Inconsistent subnetwork name on multiple subnetwork controllers in the same subnetwork discovered during update subnetwork.

1.      If the features connected to each controller should be a single subnetwork you should update the subnetwork names associated with each controller to match.


2.      If the features connected to each controller are different subnetworks and should be isolated from each other, you will need to determine why they are connected and update your data so they are isolated.


3.      If only one of the controllers is active but they have different names then you will need to either isolate the backup controller from the active controller, or you will need to set the backup controller to not be a subnetwork controller.

Inconsistent Network Name

An inconsistent subnetwork name error occurs when two subnetwork controllers share the same set of connected features but have different subnetwork names. When this happens the update subnetwork operation reports the list of affected subnetwork controllers and create errors for each subnetwork controller.

Inconsistent Subnetwork Name

We will discuss the most common solutions to resolving inconsistent subnetwork name errors below.

Isolate the networks

If the features connected to each controller are different subnetworks and should be isolated from each other, you will need to determine why they are connected and update your data, so they are isolated.

To discover how these subnetworks are connected, run the shortest path trace between the two reported subnetwork controllers. To do this perform the following:

  1. Place a starting point on the terminal of each subnetwork controller.
  2. Choose the Shortest Path trace from the Utility Network tab
  3. Set the Shortest Path Network Attribute Name to use shape length.
  4. Under Traversability, specify the Condition Barriers for your network as follows:
    1. Device Status is Open
    2. Lifecycle Status is not ‘In Service’
  5. (Optional) Under Output options, choose the “Aggregated Geometry” result type option under the output options to create an output set of layers containing the features.
We use the shortest path trace to find the path between the two subnetwork controllers

Next, you should review the path returned by this trace. You are looking for the feature(s) that allow the two networks to be connected with each other. The most common examples are switches with an incorrect status or proposed/abandoned features that do not have the correct lifecycle status.

It often helps to have a special layer in your map that symbolizes the lines in your network by their subnetwork name. If you’re troubleshooting existing subnetworks, you can use the subnetwork line layer. Otherwise, you may need to use the electric line layer and either reference a legacy feeder id field or the subnetwork name field on the features themselves.

In the image below, you can see the aggregated lines layer created by the trace result overlaid on the subnetwork line layer in our map, with the location where the two subnetworks meet called out with an arrow.

We compare the shortest path with the existing subnetwork lines

If we zoom into the area and turn on the aggregated points from the trace result, we can see that the switch between these two circuits is set to closed (red with a solid line) instead of open (green with a broken line).

In this image the tie switch between the two circuits is closed, as indicated by the red symbol

Before changing the operational status of a switch in the system we need to confirm its correct status with either a field crew or operation. Once we’re confident this switch should be open, we make the edit in the GIS, validate the device, validate each controller (to remove the errors associated with each controller), then rerun the update subnetwork operation on each of the subnetworks.

Update subnetwork name

If the features connected to each controller should form a single subnetwork, you should update the subnetwork names associated with each controller to be the same. This is most likely to occur when you are dealing with mesh networks where you have inadvertently named the subnetwork using the device’s name instead of the name of the mesh network itself.

This image shows the three subnetwork controllers for a spot network

Let’s revisit the example from our previous blog where we have a spot network providing power to an important building on a customer’s campus. When we initially loaded this data, each transformer had its own subnetwork name.  When we then ran update subnetwork, we received an inconsistent subnetwork controller error.

Because each controller had a unique subnetwork name, we receive an error

To correct the error, we remove the subnetwork controllers with each device and recreate them with a common subnetwork name. After validating the controllers and running update subnetwork, we can now see that all three controllers are providing power to a single spot network with the desired name.

The spot network after correcting the errors

Make sure you follow the steps outlined in the online help for deleting a subnetwork to completely remove the old subnetwork(s) from the system.

Remove the subnetwork

When data is first converted into the utility network many customers elect to treat all medium voltage circuit breakers as subnetwork controllers. Customers who model their substation internals will often run into problems when they first trace their subnetworks because the circuit breakers that are internal to their substations conflict with the subnetwork names on their power transformers and/or distribution circuits. You can see an example of this below:

In this image the power transformer and the circuit breaker are providing conflicting subnetwork names

To correct the issue, you will disable the subnetwork controller on any internal circuit breakers using the Modify Subnetwork Controller pane. Select the subnetwork controller device, click the red X next to the terminal, click apply, and then use the validate topology command on the dirty area surrounding the device.

Remove the subnetwork associated with the tie circuit breaker

Make sure you follow the steps outlined in the online help for deleting a subnetwork to completely remove the old subnetwork(s) from the system.

Finally, you should review the classification of the circuit breaker and ensure it is correct. In our case the medium voltage circuit breaker should be classified as a medium voltage bus tie breaker. Correctly classifying the equipment is important because it controls the connectivity rules for the feature as well as the symbology, available fields, and labels for the feature in our display.

After correcting the error the bus tie breaker is now acting as a but tie, instead of a subnetwork controller

Invalid Equipment

An invalid equipment error means that a feature was discovered in the subnetwork that, according to the tier’s subnetwork definition, is not allowed to participate in that tier.

Update subnetwork definition

If the affected features have been drawn correctly and should be allowed to participate in this tier of the network, then your geodatabase administrator can update your subnetwork definition to allow them to participate in this tier. This error most often occurs when a new asset group or asset type is the model without updating the corresponding subnetwork definitions.

The relays in our substation are being reported as invalid equipment

To correct the issue, we disable the topology, update the subnetwork definition, and re-enable the topology. You can see where we’ve added the MV relay to the list of valid devices in the subnetwork definition in the screenshot below:

Using the set subnetwork definition tool we add the substation relay to the list of valid equipment for the subnetwork tier

Once the subnetwork definition is corrected, we then update the distribution subnetwork to include the new relays. We see the relays participating in the distribution substation in the screenshot below:

After updating our subnetwork definition we trace the north bus of our substation to confirm the relays are now connected

Isolate the equipment

Because medium voltage equipment cannot be part of a transmission subnetwork it is important that all the power transformers in your distribution substations are set to be subnetwork controllers for the distribution. If they are not, then the transmission subnetworks will try to include the medium voltage inside the substation in the transmission tier. When this happens the update subnetwork operation will create an error for the first invalid line, device, or junction it discovers during the trace.

In the example below you can see that when we try to update the 115kV transmission subnetwork, it traces through one of the power transformers in our distribution substation. The error isn’t necessarily the first invalid feature discovered during the trace.  In this case, it first identifies the bus tie breaker inside the substation.

This error in this image shows that our transmission subnetwork is including several distribution circuit breakers

To correct the issue, we use the Modify Subnetwork Controller pane to turn the power transformer into a distribution subnetwork controller. This will cause the transmission trace to stop at the power transformer and will allow the substation internals to belong to their own subnetwork.

Turn the power transformer into a subnetwork controller for the distribution substation

After validating our edits and updating our subnetwork we can see the transmission subnetwork stops at the power transformer.

The transmission subnetwork stops at each power transformer that is a subnetwork controller

We can also see that the entire substation is its own subnetwork.

Tracing the power transformers shows us everything in the distribution substation

Correct the classification

The last option to consider when correcting invalid equipment errors is whether the object(s) have the correct asset group / asset type. Connectivity rules are good at preventing this type of error from happening, but there are some edge cases where an object can be topologically correct but not allowed in the corresponding subnetwork.

To demonstrate this, let’s consider the following example: the utility has just purchased and installed several SCADA enabled fault indicators to help improve reliability on one of their circuits. Because this isn’t a frequent operation, we aren’t sure which feature template to use. We know that the feature isn’t a normal fault indicator, so we don’t want to use that feature template. After some experimentation we determined that the Line Monitor’s Relay feature template allows us to connect the feature to an overhead line end.

We've created and attached a fault indicator in our network

We are now able to successfully validate our dirty areas without receiving any errors, but when we run update subnetwork, an invalid equipment error is created.

The SCADA fault indicator, depicted as a relay, has an error associated with it

If we look at the subnetwork definitions for the tiers in the electric domain network, we can begin to understand why this is a problem:

Asset Group Name Asset Type Name Electric Distribution Electric Distribution Primary Electric Subtransmission
Medium Voltage Line Monitor and Relay Fault Indicator MV Yes Yes No
Instrument Transformer MV Yes Yes Yes
Programmable Logic Unit MV Yes Yes Yes
Relay MV No No  Yes
Remote Terminal Unit MV Yes Yes Yes
SCADA Load Monitor MV Yes Yes Yes
SCADA Weather Station MV Yes Yes Yes

We can see that medium-voltage relays are only allowed in the subtransmission tier, and because we placed the feature on a distribution subnetwork, we received this error. After discussing the situation with other mappers in our organization, we determined that the medium-voltage fault indicator is the correct asset type to use but that we also must set the Remote-Control Indicator field to indicate whether or all phases are being monitored and put the unique identifier from the SCADA system in the Asset ID field instead of the system generated GIS ID.

We correct the classification and attribution of the fault indicator

Once we’ve made these changes, we are then able to validate and update the subnetwork without receiving any errors. Remember, any time you start modelling new types of equipment that you have a clear set of instructions on how to model these features in your GIS!


You should now have a better understanding of how to manage and update subnetworks using the Electric Utility Network Foundation. Most importantly, you are now equipped with an understanding of the most common subnetwork errors and several techniques that you can use to address these issues in your own data.

How does data quality assurance differ from error management? Isn’t error management part of a data quality assurance process? What are the checks we recommend you include in your data quality assurance process? We will answer all these questions and more in our final blog in this series where we discuss the tools and processes you can use to implement a more thorough data quality assurance process for your electric networks.

About the authors

Robert Krisher is a Product Engineer with Esri who has over 15 years of experience implementing Enterprise GIS for Utilities.


Commenting is not enabled for this article.

Next Article

Engaging Volunteers for a Cause

Read this article