ArcGIS Utility Network

The Life Cycle of Subnetwork in Utility Network

Subnetworks are used to represent circuits in an electrical distribution network, or a cathodic protection zone in a gas pipeline network. They represent a topological subset in a tier where all participating features have traversability to the same subnetwork controllers. In this blog I want to walk through the basic building blocks that make up a subnetwork and discuss the life cycle of a subnetwork from its creation, update, export, and finally its removal.

Read more about the subnetworks

Subnetworks

Subnetworks can have one or more controllers that are considered the source or sinks of a subnetwork commodity. A controller is assigned to a terminal on a device or junciton object and have two main attributes:

To be considered a valid subnetwork, all controllers participating in the subnetwork must have the same subnetwork name. That means if you run a subnetwork trace from a controller, all controllers returned should share the same subnetwork name.

 

Subnetworks Table

The subnetworks table stores all the subnetwork controllers and their attributes. There are many fields on the table which are covered in more detail here if you want to learn more. We are primarily interested in just a few of them for our purposes:

You can open the subnetworks table in ArcGIS Pro by clicking on the View button found in the Subnetwork group of the Utility Network tab.

View Subnetworks button

Subnetwork State

The subnetwork can be dirty, deleted, or consistent. Those states carry to the controller level. Let us define each of these states.

Subnetwork Operations

Here are operations that affect subnetwork management.

  1. Add Controller – creates a new controller for a given subnetwork
  2. Delete Controller – deletes a controller on a given subnetwork (set isDeleted = True)
  3. Validate network topology – marks controllers as dirty
  4. Update Subnetworks – Run a trace, updates subnetwork name of features, create subnet lines and mark all its controllers as clean
  5. Export Subnetworks – Run a trace and export features that are part of the subnetwork. This removes deleted controllers from the subnetworks table.

 

Subnetwork Life Cycle

Now that we know the basics of a subnetwork management, let’s step through the life cycle of a subnetwork.

Using the Naperville Electric data model, we will first create the following features:

Note: All operations are performed on the DEFAULT version as the owner of the feature service.

Representation of the features outlined above
Here is a representation of the network features we just created

Next, we’ll set each of the circuit breakers as a controller.  We will use the Modify Subnetwork Controller pane and select each of the Circuit Breaker and enable the controller on the busbar side of the terminal. (cb01/South Circuit, cb02/South Circuit, cb03/South Circuit)

The initial state of the subnetworks table is as follows:

Controller Name Subnetwork Name isDirty isDeleted Last Update Last Exported
cb01 South Circuit True False null null
cb02 South Circuit True False null null
cb03 South Circuit True False null null
Use Modify Subnetwork Controller to set the circuit breakers as subnetwork controllers.
Setting each circuit breaker to serve as a subnetwork controller.

We’ll then run Validate Network Topology. If necessary, the process will mark the subnetworks as dirty. At this stage all controllers are dirty.

Controller Name Subnetwork Name isDirty isDeleted Last Update Last Exported
cb01 South Circuit True False null null
cb02 South Circuit True False null null
cb03 South Circuit True False null null

 

Next, we’ll run the Update Subnetwork geoprocessing tool and specify the tool to run against the South Circuit subnetwork.  This process will execute a trace from all controllers, update the subnetwork name in all the traced features, and then update the isDirty field for all controllers in the South Circuit to False (clean). This will also update the LastUpdatedSubnetwork (Last Update) date to the current time (assume 10-07-2020 8:00 am).

Controller Name Subnetwork Name isDirty isDeleted Last Update Last Exported
cb01 South Circuit False False 10-07-2020 8:00 am null
cb02 South Circuit False False 10-07-2020 8:00 am null
cb03 South Circuit False False 10-07-2020 8:00 am null

 

Final step.  We want to run the Export Subnetwork geoprocessing tool using the South Circuit (now that it is clean and can be exported); we want to do this operation with acknowledgment. You might want to do this to update an outage management system or distribution management system with the changes.

Exporting with acknowledgment is only applicable when working with the DEFAULT version. This will generate a JSON file (we’ll probably analyze that file further in another blog) and it will also update the last exported date on all the controllers, (assume 8:20 am). The exported JSON file can then be consumed by other external systems.

Controller Name Subnetwork Name isDirty isDeleted Last Update Last Exported
cb01 South Circuit False False 10-07-2020 8:00 am 10-07-2020 8:20 am
cb02 South Circuit False False 10-07-2020 8:00 am 10-07-2020 8:20 am
cb03 South Circuit False False 10-07-2020 8:00 am 10-07-2020 8:20 am

This is the happy path of the life cycle status.

Let’s now explore what happens if we delete a controller for a subnetwork. Keep in mind that this workflow will not delete the subnetwork entirely, because we will still have other active controllers for the subnetwork remaining.

Using the Modify Subnetwork Controller pane, delete controller cb01. This operation will update the row for cb01 in the subnetworks table as dirty and deleted as shown below:

Controller Name Subnetwork Name isDirty isDeleted Last Update Last Exported
cb01 South Circuit True True 10-07-2020 8:00 am 10-07-2020 8:20 am
cb02 South Circuit False False 10-07-2020 8:00 am 10-07-2020 8:20 am
cb03 South Circuit False False 10-07-2020 8:00 am 10-07-2020 8:20 am

Since we have a dirty area on the controller (because we deleted cb01), we need to run Validate Network Topology to update the network topology with the change. Running Validate will mark all our controllers for this subnetwork as dirty.

Controller Name Subnetwork Name isDirty isDeleted Last Updated Last Exported
cb01 South Circuit True True 10-07-2020 8:00 am 10-07-2020 8:20 am
cb02 South Circuit True False 10-07-2020 8:00 am 10-07-2020 8:20 am
cb03 South Circuit True False 10-07-2020 8:00 am 10-07-2020 8:20 am

We then follow this with a run of the Update Subnetwork tool to mark all the dirty controllers as clean (isDirty=False). We also set the Last Updated field to reflect the time (assume 8:30).  Now we only have one dirty controller and it is deleted.

Controller Name Subnetwork Name isDirty isDeleted Last Updated Last Exported
cb01 South Circuit False True 10-07-2020 8:30 am 10-07-2020 8:20 am
cb02 South Circuit False False 10-07-2020 8:30 am 10-07-2020 8:20 am
cb03 South Circuit False False 10-07-2020 8:30 am 10-07-2020 8:20 am

 

To completely remove the deleted controller we need to export the subnetwork with acknowledgement. This will delete the row from the Subnetworks table and update the Last Exported field for all of the remaining controllers.

Controller Name Subnetwork Name isDirty isDeleted Last Updated Last Exported
cb02 South Circuit False False 10-07-2020 8:30 am 10-07-2020 8:40 am
cb03 South Circuit False False 10-07-2020 8:30 am 10-07-2020 8:40 am

About the author

Product Engineer at Esri, Author of several GIS books and Software Engineering Content Creator on YouTube and a podcast host.

Connect:

Next Article

Monitor assignment status in ArcGIS Dashboards using a joined Workforce layer

Read this article