ArcGIS Utility Network

Analyze wastewater networks using the ArcGIS Utility Network

Performing network analysis in a wastewater system is a critical activity periodically performed by engineers to perform sewer capacity analysis, evaluate the impacts of new construction on existing infrastructure, as well as simulating the effects of wet weather events on the overall system. While all these activities are performed by highly trained individuals using very specialized software, the pipe and elevation data that drives all this analysis is often stored and maintained in the GIS.

This article is the second in a series where we explore how the ArcGIS Utility Network can be used as a modern network management solution to help track, maintain, and analyze wastewater infrastructure. These articles are intended to not only demonstrate these topics, but also to contextualize the industry-agnostic terminology used by the utility network so you can better navigate discussions within the utility network community as well as the online help.

In the previous article, we showed how the utility network organizes data using a series of well-defined data models. We also showed how these data models include a rule base that is used to guide quality assurance which allows you to ensure that the connectivity represented in your database is accurate.

In this article we will demonstrate how you can take this validation to the next level and ensure that not only the individual features are connected correctly, but that your data represents a valid network where all features can be proven to be participating in a wastewater management system.

Tiers

So, how does the utility network determine which direction materials flow through pipes on their way to a treatment plant? Like many other aspects of the utility network, this is a question that is answered by providing a configurable framework that allows each industry to answer this question using their own rules; because what works for an electrical network won’t necessarily work for a wastewater network.

The first step is to look at how the sample wastewater domain network is configured.

A table showing the properties of a sewer domain network. The table shows the name and alias of the domain are Sewer, the tier definition is Hierarchical, and the subnetwork controller type is sink.
Sewer domain network properties

Every network has both sources (inputs) and sinks (outputs) and these points are used to determine the direction of flow within the network, however most systems only require you to define either the sources or the sinks. While the flow in a sewer network could be modeled by establishing all the sources in your network, it is typically handled by setting treatment plants as sinks. This allows upstream traces to identify all the sources for that area, and a downstream trace to identify the path wastewater will take to the treatment plant.

The graphic shows two example networks. The left network shows downstream flow originating at manholes and cleanouts and flowing towards a treatment plant. The right network shows upstream flow originating at a treatment plant and flowing towards the manhole and cleanout.
Upstream and downstream tracing in a wastewater network

The decision to configure the wastewater domain to use sink-based subnetwork controllers is one of both convenience and correctness.

It is convenient to model the wastewater treatment plants as sinks because there are relatively few of them, and the accuracy of their information is quite high. There are significantly more sources in a wastewater network, but because this data is not always accurate or complete within the GIS it is not suitable for analysis. Finally, consider that water can naturally infiltrate a wastewater system through leaks in manholes and pipes, so even if you modeled all the known sources of water inlets for your system you still wouldn’t be ablet to capture all the water infiltration. By setting the wastewater treatment plant as a subnetwork controller you can capture downstream flow to the treatment plant, and any upstream traces will capture the inflow and infiltration upstream of that location.

Now that you see why wastewater treatment plants are treated like sinks in the network, how does the system account for the flow changes caused by pumps and lift stations? How does the system know that the area managed by a lift station is always a subset of the area managed by a wastewater treatment plant? How can we account for subbasins within the sewer collection system?

The answer is that a utility network can have multiple definitions of systems, known as tiers, with each tier having a different rank within our network that determines whether it is the ultimate source/sink (rank 1) or is a lesser area (rank > 1) within the network.

The graphic shows a table describing the definitions for two tiers in the sewer domain network. The first tier is the sewer collection system with a rank of 1. The second tier is the sewershed with a rank of 2.
Tiers in a wastewater utility network

Because Sewersheds are rank 2 and the sewer model is a sink-based network, that means that they are considered upstream of any Sewer Collection Systems. In use, this can be modeled by creating the Sewer Collection System to model each basin within your network while the Sewershed areas represent the subbasins. It’s also worth noting that not everything that belongs to a Sewer Collection System must belong to a Sewershed, but everything that belongs to a Sewershed should also belong to a Sewer Collection System.

This graphic shows an example of the hierarchies of 8 subnetworks. The Sewer collection system 1 subnetwork contains two sewersheds: Sewershed A and Sewershed B. The Sewer collection system 2 subnetwork contains three sewersheds: Sewersheds C, D, and E. Sewer collection system 3 contains no subnetworks.
Tier ranks in a wastewater utility network

Another important benefit of tiers is that each tier allows you to define separate configurations for tracing along with which types of features are allowed to control and participate in each tier. In the wastewater domain these tiers typically correspond to basins / wastewater treatment plants (sewer collection system) and to the subbasins within each sewer collection system (sewershed area).

This graphics shows a partitioned representation of sewer subneteworks. The sewershed subnetwork starts at a cleanout and goes to a pump. The Sewer collection system starts at the pump and goes to the treatment plant.
Example tier contents in a wastewater utility network

Each tier allows you to define the default behavior of tracing one of these areas by specifying a trace configuration. In a wastewater system this is typically set to exclude proposed features, exclude areas of the network that are only active during a wet weather event, or stop at any closed device (gate, stop log, etc.). In the example below you can see how a raising (open) and lowering (closed) a stop log in a manhole affects the flow of gravity mains within a subnetwork

This graphic shows a small sewer network with two different configurations to show how network attributes can affect flow. In the configuration on the left a stop log has been lowered in the top part of the network, resulting in flow from the manhole taking a central route through the raised stop log to get to the treatment plant. In the configuration on the right, a stop log has been lowered in the central part of the network, resulting in flow from the manhole taking the top route of the network through the raised stop log to get to the treatment plant.
Condition barriers and their effects on flow in a sewer collection system

Subnetworks

Up until this point we’ve been referring to these connected areas of your network as systems or tiers within the utility network. Unsurprisingly, the utility network has its own special language for describing these systems. Each specific area managed by a controller represents a subset of your entire utility network, so the utility network refers to this as a subnetwork. By extension, the device or devices that act as the controllers (sources and sinks) for this subnetwork are referred to as subnetwork controllers. Finally, the collection of rules on each tier that define how a subnetwork behaves are known as the tier’s subnetwork definition.

This graphic uses polygon to represent the extents of subnetworks in a sewer network. There is a box containing a cleanout and pump that represents the sewershed subnetwork. The sewershed subnetwork is contained in a larger box that also contains a manhole and treatment plant representing the sewer collection system.
Subnetworks and subnetwork controllers in a wastewater utility network

Given the two definitions we discussed for sewer subnetworks, sewer collection system and sewershed area, this raises an interesting question: If a feature belongs to a sewershed area, doesn’t it also belong to a sewer collection system?

Yes, and this is especially true if your subnetworks correspond to the basins and subbasins of your network. Because everything that belongs to the subbasin also belongs to the parent basin, it would make sense that the utility network would need to support the ability for features to participate in multiple subnetworks. So how does the utility network achieve this? What constraints does it place on membership in multiple subnetworks? And most importantly what is the language used to describe these ideas?

Partitioned vs Hierarchical Network

The utility network does allow a feature to belong to multiple subnetworks, but only allows a feature to belong to a single subnetwork per-tier (unless it is acting as a barrier between subnetworks).

As an example: a cleanout can be located upstream of both a lift station and a water treatment plant, but if there are multiple lift stations downstream of the cleanout then it will only be considered part of the subnetwork of the nearest lift station.

This graphic shows how subnetworks are represented in a hierarchical subnetwork using arrows. The sewershed area extends from the cleanout to the pump while the sewer collection system extends from the cleanout to the treatment plant.
Example of hierarchical sewer subnetworks and subnetwork controllers

But what if you want your features to belong to multiple tiers? This is handled through the configuration of the tier definition for the domain network. In a partitioned network a feature can only belong to a single tier, and in a hierarchical network a feature can belong to multiple tiers. In the case of the sewer model the domain is configured to be hierarchical because it is important to know the sewer collection system for a feature, even if it belongs to a sewershed area.

This graphic has two charts comparing the structure of a partitioned network and a hierarchical network. The graphic on the left represents a partitioned network where each sewershed is represented as a rectangle and points to a circle that says sewer collection system. The graphic on the right represents a hierarchical network where each sewershed is represented as a circle contained in a larger circle that says sewer collection system.
Comparison of partitioned versus hierarchical subnetworks

When running traces in the utility network you can select which tier of the utility network you wish to analyze. This is an important parameter to consider in a hierarchical network since it can be the difference between analyzing the contents of a small lift station or the contents of an entire city!

This graphic shows a map in ArcGIS Pro with an open dialog for an upstream trace in the sewershed tier. The map has lines that are color coded for each sewershed with point symbols indicating the location of the treatment plant and pumps. There is a green dot representing the starting location of the trace and all the features between the starting location and the pump are selected.
Downstream trace to the nearest subbasin subnetwork controller
This graphic shows a map in ArcGIS Pro with an open dialog for an upstream trace in the sewer collection area tier. The map has lines that are color coded for each sewershed with point symbols indicating the location of the treatment plant and pumps. There is a green dot representing the starting location of the trace and all the features between the starting location and the treatment plant are selected.
Downstream trace to the nearest basin subnetwork controller

Conclusion

Now that you’ve made it through this article, you should have a good understanding of the key concepts and terminology of the utility network. If you want to continue your journey at a high level, I recommend you read the related articles found below. If you’re ready to dig into the detail at a more technical level, I recommend you check out the Learn ArcGIS Utility Network for Water Utilities learning series.

About the author

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

Connect:

Next Article

ArcGIS Solutions at the Esri User Conference 2024

Read this article