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:

• The subnetwork controller name (a unique identifier)
• The name of the subnetwork that the controller participates in

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:

• SUBNETWORKCONTROLLERNAME – Unique identifier of the controller.
  
• SUBNETWORKNAME – The subnetwork name the controller participates in.
  
• FEATUREGLOBALID – The feature the controller is assigned to.
  
• FEATURETERMINALID – The terminal on which the controller is assigned.
  
• ISDIRTY – Whether the controller is dirty or not.
  
• ISDELETED – Whether the controller has been deleted or not.
  
• LASTUPDATESUBNETWORK – When was the last time the subnetwork was updated.
• LASTACKEXPORTSUBNETWORK – When was the last time the subnetwork was exported with the acknowledgement (ACK) option.

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.

Subnetwork State

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

• Dirty: A dirty subnetwork is a subnetwork that has been edited or recently created. All the controllers for a given dirty subnetwork have their isDirty property set to True.
  • Validate Network Topology marks controllers of a subnetwork as dirty when any feature in that subnetwork has been edited.
• Deleted: A deleted subnetwork is a subnetwork that all its controllers have been deleted. All the controllers for a given deleted subnetwork have their isDeleted property set to True.
  • Even if a subnetwork has some of its controllers deleted, as long as there is at least one active controller on the subnetwork, the subnetwork is not considered deleted.
• Consistent: A consistent or clean subnetwork is a subnetwork that has been successfully updated. All the controllers for a given subnetwork have their isDirty property set to False.

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:

• Three circuit breakers (Three Phase)
• Underground medium voltage (Three Phase)
• Riser
• Overhead medium voltage line (Three Phase)

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

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:

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

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).

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.

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:

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.

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.

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.