ArcGIS Utility Network

Water Subnetworks

One of the most exciting and powerful features that the utility network provides to water customers is the ability to manage, validate, and analyze their water systems and pressure zones using the out of the box functionality called subnetworks. The data model and subnetworks described in this article are based off the Water Distribution Utility Network Foundation solution, so if you want to follow along you can download the solution and test it out yourself. Because only a small number of utilities in the community are managing this information in GIS, we have put together a series of blogs that will show you how you can create subnetworks, manage subnetwork errors, and perform quality assurance on the correctness of your water systems and pressure zones.

This first blog focuses on answering the questions: what are subnetworks and how do you create them?

What is a Subnetwork

Most networks can be broken down into different areas based on the equipment that is supplying or regulating services. Each of these areas is referred to as a subnetwork, and every feature that is responsible for managing a subnetwork is called a subnetwork controller. We use these generic terms to describe data in the utility network because the utility network is used to model many types of networks and each network has its own definitions for the different types of subnetworks it managed. Each type of resource managed by a utility network is called a domain; the definitions for the types of subnetworks that each domain manages are called tiers.

With all the definitions out of the way let’s look at the tiers associated with the water domain in the Utility Network. The tiers associated with the model are: Water System, Water Pressure, District Metered Area, Water Isolation, and Cathodic Protection. This article is focused on modeling systems and pressure zones, but the techniques described here also apply to cathodic protection, district metered areas, and isolation zones.

The following diagram shows how these tiers are organized using a hierarchy where each isolation zone is contained within a pressure zone, and each pressure zone is contained within a water system. We will be revisiting this structure in later articles when we examine what happens when we have a pressure zone that belongs to multiple systems or no system at all!

For those of you who aren’t familiar with how water models are constructed, here is a brief definition of what these tiers do:

Water System – A water system is an area that all shares the same water sources. Each system often has more than one water source, with a water treatment plant often being supplemented by groundwater from multiple wells.
Water Pressure – A water pressure subnetwork, often referred to as a pressure zone, is a section of the water system that is designed to operate at a specific pressure level. This pressurization is maintained by pumps, gravity, or even by taking water from a higher pressure zone and regulating it to be a lower pressure. This pressure makes sure that when you open the tap, water comes out.
Water Isolation – A water isolation subnetwork, or isolation area, is a predetermined area of the network with a known set of valves that can be isolated for maintenance or emergency purposes. Part of designing a reliable system is ensuring that every customer is part of an isolation zone that each zone is a reasonable size and has multiple paths to a given water source.

With the definitions out of the way, let’s walk through a few examples of how to create subnetwork controllers in a sample dataset so we have a fully connected water system with several pressure zones.

Creating a Subnetwork Controller

First, let’s talk about how to create a subnetwork controller. To create a subnetwork controller, you need at least six pieces of information

Tier Name – This is the tier that the new subnetwork will belong to.
Terminal – This is the terminal that the subnetwork will originate from. In most cases you will want to identify and use the downstream terminal on the device.
Subnetwork Controller – This is the device that will act as the source for the subnetwork.
Subnetwork Controller Name – This is a unique identifier for the device.
Subnetwork Name – This is the name of the subnetwork it controls. If a subnetwork has multiple controllers, then they should all have the same subnetwork name, but different subnetwork controller names.
Line(s) – Which line(s) are connected to the terminal associated with this subnetwork

Even if you’re not familiar with the utility network model, you should be able to quickly identify all of these pieces of information, except for the terminal. Every subnetwork controller is required to have at least two terminals, one of which is considered to be upstream. The terminals on a subnetwork controller allows the system to identify upstream/downstream flow and in turn ensures that the subnetwork flows in the correct direction.

Once you’ve identified these six items, you’ll want to look at the lines connected to each of your controllers and figure out which terminal on the device they are connected to. This is a straightforward process for things like wells and water treatment plants, but it may be more difficult for devices like pumps and pressure reducing valves if you don’t have clearly defined boundaries for your pressure zones.

Topology Errors

The first thing we need to check before we create this system is to make sure that the topology for the system is valid. You can still create a water system if you have errors in your data, but you won’t be able to trace or update it until all the errors in the system have been resolved. This is why I recommend utilities adopt a zero-tolerance policy for dirty areas and errors in their database! The quickest way to check the number of errors in your utility network is to right click the utility network layer in your map, select properties, then look at your network properties.

If you see zero errors and zero dirty areas, then you’re in a perfect place to start creating subnetworks! If you have dirty areas, but no errors, then you need to use the validate topology tool to resolve those outstanding issues. If you have errors in your topology then you’ll need to resolve them. Check out my previous blog post for a guide to resolving the most common topology errors for water networks if you need a reminder on how to do this.

Once we have validated all our dirty areas and resolved all our errors, we’re ready to start making subnetworks!

Creating a Water System

The three main water sources in the water utility network model are bulk system meters, treatment plants, and wells. For our example we will be using a water treatment plant that is connected to several storage towers.

So, looking at the above image I can answer the five questions for my subnetwork controller:

Tier Name: Water System
Terminal: Port Two (Port One is the upstream terminal, so we must choose Port Two)
Subnetwork Controller: This is the water treatment plan on the left-hand side of my map
Subnetwork Controller Name: Supply-1
Subnetwork Name: Naperville Distribution
Line(s): There is only one line connected to this treatment plant, and it is already connected to the correct terminal.

Using this information, we can use the Modify Controller tool to create a new subnetwork controller. The dialog will default to using “Port One”, so make sure you select “Port Two” before populating any of the other fields. Go to the Utility Network Data tab on the ribbon and click the Modify Controller tool to open the Modify Subnetwork Pane.

Activate the select feature tool and click the device we identified as the subnetwork controller to create or delete the subnetwork controller record for that device. Input the values for the subnetwork controller into the form then review your choices before clicking apply.

It’s important that this information is correctly entered when you create the controller, since if you need to update it, you have to delete and recreate the subnetwork. Once you’re satisfied with your results, click Apply to create the new subnetwork. If you look carefully, you’ll see that this actually creates a dirty area on the map we need to validate to make the topology aware that there’s a new controller in the network then save your edits. You should consider placing these tools on your Quick Access toolbar, as you can see in the screenshot below, so you can validate and save your edits no matter which tab of the ribbon you are currently looking at.

Once you’ve validated and saved your edits, you can now see the new subnetwork in the Find Subnetwork pane. If you don’t already have the pane open, you can open it by going to the Utility Network data tab on the ribbon and clicking the Find Subnetwork command. Make sure you click the Find Subnetwork command and not the Find Diagram command.

You can initialize the new water system by right clicking the subnetwork in the find subnetwork pane and selecting Update Subnetwork. If the update option is greyed out, then you either have unsaved edits or the subnetwork is already up to date.

The process of updating a subnetwork does several important things. First, it validates the contents of your subnetwork against the configuration in your model. If it finds a problem with you network it will create an error feature with a unique code and description, similar to the validate topology tool.

Creating a Water Pressure Zone

We will now repeat the procedure from the previous step to create the two pressure zones near this water treatment plant. Using the following table you can see that we have four subnetwork controllers controlling the two pressure zones in this area. When creating these controllers make sure you select the downstream terminal for each controller before populating the subnetwork controller or subnetwork name field.

Tier	Terminal	Subnetwork Name	Controller
Water Pressure	Port Two	5000	Tower-1
Water Pressure	Port Two	5000	Tank-1
Water Pressure	Port Two	5000	Tank-2
Water Pressure	Low Pressure Out	5001	PRV-1

The image below shows these controllers, with arrows showing the direction that each of these devices are supplying pressure to.

Once we’ve created these subnetworks, we can look at the subnet line layer to confirm the name and extent of each subnet line. In this case I’ve color coded the water system and pressure zone lines to make them easier to distinguish. Because we’re looking at the subnet line, only see a subset of the lines are represented, even though all the features participate in the network.

Next Steps

Now that you’ve seen how to create water systems and pressure zones using the Water Distribution Utility Network Foundation you should start developing a plan for subnetwork management. Ask yourself the following questions:

What are the names of the systems in my data?
- Where are the water sources for each system?
- What are the names of the stations / wells associated with each system?
Where are the pressure zones in my data?
- How is the pressure regulated in each of these zones?
- What are the names of the equipment associated with each zone?

With this information you should be able to start creating your own water subnetworks! Stay tuned for our next article in this series where we will be showing you the kinds of errors you can encounter when creating subnetworks.