ArcGIS Utility Network

Managing Gas and Pipeline Networks: Subnetwork Errors

In our previous blog, we discussed how Utility Network Subnetworks are configured for Gas and Pipeline pipe networks. In this blog we are going to dig into the process of building the subnetwork and how to resolve some of the errors which may arise.

Gas organizations’ gas and pipeline pipe networks are constantly changing. When these changes occur, the Subnetwork representation of the System, Pressure, Isolation, and Cathodic Protection zones for the modified area need to be updated. The Update Subnetwork geoprocessing tool is used for this task. The Update Subnetwork tool checks for errors, populates the subnetwork name field on features in your subnetwork, and updates a subnetwork line layer with the extent and statistics of the modified subnetwork(s). You can learn more about the update subnetwork process on the Update a subnetwork page in the online help.

If the tool finds one or more problems with your subnetwork it will create errors in your database, often referred to as subnetwork errors. You can read more about subnetwork errors in the subnetwork error section of the online help. The purpose of this blog is to describe the most common subnetwork errors and their resolutions.

Below you will find an error with the most common error codes and their resolutions. The error type in this table is a shorthand description of the error code that users typically use when discussing these types of errors.

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

 

An invalid network feature was discovered during the 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 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.

Invalid Equipment

Update subnetwork definition

Whenever a new type of feature is added to the utility network definition there are several steps you need to take to ensure the feature works properly in the model. In the topology error article, we mentioned the importance of adding connectivity rules to ensure that you don’t receive any connectivity errors. If you forget to add the feature to the list of valid devices, junctions, and lines for any tiers then you will receive an error when you run the update subnetwork tool and a subnetwork encounters one of these features.

Invalid Junction Feature

In the following example, we added a new asset type to our model “Metal Service Saddle” along with the corresponding connectivity rules that allow it to connect to metal distribution and service pipe.

New Asset Type

To correct the error, we add the new junction asset type to the list of valid junctions for all the tiers that we have in our model. In the case of the standard model, this means we need to add it to the system tier, pressure tier, isolation tier, and cathodic protection tier using the update subnetwork definition tool. Once we’ve finished adding it to all the tiers, we can then re-run the update subnetwork tool to clear the error.

Valid Equipment

Isolate the equipment

This issue resolution is only something you should encounter if you are on an older data model that has separate tier groups for gathering, transmission, and distribution. However, because this error often occurs with an inconsistent network name error even in newer models you should refer to the Isolate the Networks resolution for the Inconsistent Network Name error below.

Inconsistent Network Name

Update subnetwork name

System and Pressure subnetworks are typically designed to have multiple sources feeding them natural gas. As previously mentioned, in the Utility Network we refer to these sources as subnetwork controllers. The Utility Network understands that a subsection of the pipe network is intended to represent the same system zone or pressure zone when the subnetwork controllers have the same subnetwork name. If one or more of these subnetwork controllers (sources) has a different name from the other subnetwork controllers which were identified as part of the Update Subnetwork process, you will receive an error.

.

These regulators have inconsistent subnetwork names

In the case of a pressure zone, if all the features are designed to operate at the same pressure level and are in the same area, then each of the regulators in the area should be configured to use the same subnetwork name. Each regulator will still need to have a unique subnetwork controller name.

The first regulator controls the Naperville Pressure Subnetwork
The second regulator controls the Naperville Pressure 2 subnetwork

To correct the issue, use the modify subnetwork controller tool to remove the subnetwork associated with the regulator with the incorrect name.

Delete the subnetwork from the second regulator

Then you can re-add a subnetwork on the low-pressure out terminal with the shared subnetwork name and unique subnetwork controller name.

Add the Naperville Pressure subnetwork to the second regulator

You will need to visit and validate each of the subnetwork controllers that reported this error, and once you’ve corrected and verified all the controllers you can then run update subnetwork to finish updating the subnetwork. If you attempt to update the subnetwork without validating all the errors, you will receive an error saying that one or more dirty areas were discovered in the subnetwork.

The regulators after correcting the subnetwork names

Isolate the networks

If you receive this error and the two subnetworks should be different pressure zones or systems, then you will need to identify how they have become connected.

Inconsistent Pressure Zones

Run the shortest path trace between two of the network controllers that have errors to find the path between the two controllers. You can then review the pipes and devices along this path to determine where the problem is.

Shortest Path Trace

The most likely causes are pipes that are incorrectly snapped, equipment that wasn’t properly abandoned, or a valve that should be closed. Once you’ve identified and corrected the issue you should repeat this process until the trace can no longer identify any paths between the controllers.

No Path Discovered

You should then be able to validate all the controllers and update the subnetwork.

Corrected Pressure Zone

Remove the subnetwork

The last case is the rarest, but it occurs when one of the subnetwork controllers is an emergency or alternative source for an area but needs to have a different name.

Alternate Gas Source

If this is the case, 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.

Second Custody Transfer Meter

In the example above we reviewed the system with our engineers, and they let us know that the station with the interconnect is still being constructed and they need it modeled in the GIS for planning purposes. The engineers let us know that the valves at the station will be closed until the system redesign is complete, at which point the existing system will become two different systems.

By keeping these valves normally closed we have isolated the alternate supply from the main system

Next Steps

Now that you’ve read this blog you are well-equipped to deal with any errors that you encounter while creating and validating subnetworks for gas data. While you’re waiting for the next blog to release I recommend you download and familiarize yourself with the Gas and Pipeline Referencing Utility Network Foundation from the ArcGIS Solutions team. This solution includes sample maps and datasets you can use to explore the ideas discussed in these blogs.

In our third, and final blog in this series, we will show you some tips for performing data quality assurance on your subnetworks to make sure you’re getting the most out of your data! You will learn techniques to identify problems with your data that are not severe enough to cause an error but may result in some features not being connected to the correct subnetwork.

About the authors

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

Tom DeWitte

Tom is the technical lead supporting the natural gas, district heating, and district cooling industries at Esri. Mr DeWitte joined Esri in 1998. He earned his BS in aerospace engineering from Iowa State University.

Connect:

Remi is the Product Manager for the ArcGIS Utility Network and spends his free time exploring the US Southwest desert and California beaches.

Next Article

Searching for Features in Maps and Apps

Read this article