Pressure Networks - Basic Configuration
- Network Categories
- Create a Subnetwork Controller
- Network Attributes
- Set Subnetwork definition
- Trace configuration
- Conclusion
If you’ve used the Migrate To Utility Network tool to migrate your gas or water data into a utility network, you’re likely asking yourself: What configuration typically do I need to perform on this utility network to make it behave like a pressurized network? These systems are typically used to move liquids or gases through pressurized pipe networks. Analysis workflows for these datasets often involve determining how to isolate portions of the network, analyzing the maximum capacity of the pipe network, and how well the network supports the intended area.
In this article we will show you how you can take a model produced by the Migrate To Utility Network tool and extend it to support some of these basic workflows. The examples in this article show a water dataset, but the concepts and techniques apply to any pressurized network.
Network Categories
One of the most important network analysis business requirements for water and gas customers is the ability to perform an isolation trace on their network data to identify customers impacted by an outage, regardless of whether it’s planned or unplanned. The geometric network was able to perform an approximation of an isolation trace using its connectivity model. Using a utility network, we can recreate this behavior by using a connectivity trace that is configured to stop when it encounters a valve.
Below you can see an area of the network we want to isolate to repair a fitting on the main below. The area we need to isolate is indicated on the map with a green circle.
By starting a trace at the location we want to isolate (the green circle) and running a connectivity trace that stops at system valves you can reproduce the same result as seen with the geometric network. You can do this by adding a condition barrier to the trace that tells the trace when it should stop the analysis. Fortunately, the migration tool creates network categories for each asset group that can be used when configuring traces.
However, an isolation trace should consider many valves (emergency, bypass, etc), not only system valves. While you could configure our trace to reference all the different asset group and asset type combinations, it would be quite cumbersome to list them. Fortunately, the utility network allows you to create and assign network categories to asset types in your model, to control tracing. In this way it can identify and interact with common types of equipment, without the need to remember all their codes.
To do this, you start by creating a new network category for isolating equipment called Isolation using the Add Network Category tool.
Once you’ve created the network category, then use the Set Network Category tool to assign it to all the asset types that are considered operable devices during an isolation trace.
Once this network category has been assigned to the different types of isolation equipment, you can now run the trace and reference the single network category instead of the individual asset types.
Now that you’ve got the isolation trace working like it did in the geometric network, let's look at how we can take it a step further and take advantage of new features included in the utility network.
Create a Subnetwork Controller
It makes sense that when data is migrated from a geometric network to a utility network that this same behavior is present, with all the same limitations. In the geometric network isolation traces often relied on the basic network connectivity trace, meaning they didn’t have any knowledge of network sources. As a result, the isolation trace wouldn’t be able to recognize features downstream of the isolated area as also being isolated. You can see an example of this below.
The utility network solves this problem by allowing the definition of sources and sinks in networks, referred to as subnetwork controllers in the utility network. A subnetwork controller is responsible for a subset of the entire utility network known as a subnetwork. If you identified layers in your utility network as subnetwork controllers during your migration, or if your geometric network contained sources or sinks, then you will have the configuration in place to turn features in those layers into subnetwork controllers.
If you didn’t define any asset types as controllers during mapping when you ran the Migrate To Utility Network tool, you will either need to rerun the tool with the option selected or manually configure at least one asset type as a subnetwork controller using the instructions outlined in the Set a subnetwork controller page in the online help.
In the case of this dataset, you can create the water treatment plant as a subnetwork controller for the entire water distribution system. To do this you can use the Modify Subnetwork Controller pane to set the downstream terminal of the treatment plant as a subnetwork controller for a new subnetwork called the Naperville Distribution System and name this subnetwork controller the Firemens Treatment Plant.
After clicking apply you can see that a dirty area Is created for the treatment plant that we need to validate to ensure the network is aware this new subnetwork controller exists.
After validating the new controller, you can now take advantage of all the trace types in the utility network that require a subnetwork controller. This includes subnetwork, subnetwork controller, upstream, downstream, and isolation traces. By selecting the subnetwork you created in the Trace tool and clicking run, you can see all the features that are connected to this treatment plant, which should be the entire network.
Returning to our original example, you can now produce the correct result to return isolated areas downstream of the isolated area by taking advantage of the directionality of flow the controller provides. First, select an isolation trace and tell it to use the sources of the Water System tier in the network.
Second, configure the trace to isolate the area using the isolation category you configured earlier. If you were to try and use a condition barrier, as above, you will get an error communicating the need to specify at least one filter barrier (see graphic below). This is because isolation traces use filter barriers to identify the features that are isolated, while condition barriers are used to identify the features that define the extent of the trace (e.g. the subnetwork trace).
By using the isolation category as a filter barrier the trace first identifies the subnetwork controller(s) for the water system and then filters the results to include the features downstream of the filter barriers. By default, the tool will only select the features that isolate the area (e.g. the filter barriers).
To see all the pipes and customers that are isolated you can choose the Include Isolated Features parameter on the trace.
This now gives you the correct result, isolating the immediate area along with all the features downstream that can no longer access a source.
Network Attributes
If you migrated your data from a geometric network and look at your subnetwork trace dialog you will notice that there is a condition barrier set up on the Enabled field. This means that features with an Enabled value of False will act as barriers to tracing.
If you were already relying on this field for tracing, then your traces will continue to behave as they did in the geometric network. However, if you were managing information like this in another field and would like to use that field to control tracing instead of, or in addition to, the Enabled field then you can configure the utility network to act this way with just a few steps.
Pressurized systems use valves to direct the flow in the network. The field that represents whether a valve is normally open or closed is often called Normal Position or Normal Status. You may even have a field called Current Position or Current Status, but this is typically used to represent the temporary status of the network according to field crews or a network operator. So how do you incorporate this information into network analysis? You make the attribute a network attribute.
The first step to doing this is to create a new network attribute that is managed by the utility network. To do this you must disable your network topology and run the Add Network Attribute tool. When you create the network attribute you must first select a data type. This is an important selection because any field in your data you want to use to populate this attribute must have the matching data type.
Note: It is currently not possible to create a network attribute for a string field, so if your status field is a text field you will need to either create a new integer field for managing status or you should consider just using the existing network attribute configured for the enabled field.
You will see there are also additional options in this form that control how this network attribute is stored in the system tables. Storing an attribute in-line is best for performance during tracing, but there is limited space for how many attributes can be stored in-line, so you should only choose this option if you will be using this attribute frequently and it is a Boolean, such as a yes/no value. In the case of our Normal Status field, we can take advantage of this behavior! Because this field in your table is nullable you need to ensure that you configure the network attribute to be nullable as well, otherwise you won’t be able to pick the field.
For more advanced workflows you may want to set up additional attributes such as Operable (whether a valve can be operated), Current Status (the status used by network operators), or even Pinchable (whether a pipe can be pinched). But for now, let’s skip over those attributes and focus on assigning the new network attribute using the Set Network Attribute tool.
Next open the Set Network Attribute tool to assign the new network attribute to the NormallyOpen field on your table.
Now that you’ve created a network attribute that allows the normal position of a valve to be considered when tracing, you’ll want to configure the network to use this attribute whenever you trace the subnetwork.
Set Subnetwork definition
To do this, open the Set Subnetwork Definition tool and select your utility network, domain network and tier. Next, scroll down to the subnetwork trace configuration section of the tool and select your network attribute in the condition barriers. In this example you will be replacing the Enabled field with the Normal Status field. Fortunately, both treat the value of 0 as a barrier (Disabled / Closed).
Note: If you assign a domain at the class level for your network attribute fields you will see a drop down with the values from the coded value domain instead of needing to manually type in the corresponding domain codes.
Once you’ve updated the subnetwork definition, any time you run a subnetwork trace in this tier, it will automatically include this condition barrier in the trace configuration. The Set Subnetwork Definition tool has many properties that control the behavior of the subnetwork. These parameters are discussed in greater detail in the advanced configuration article.
Trace configuration
We saw how changing our trace configuration made it easier for us to run subnetwork traces, but what if you have several different traces that we frequently run. By using the Add Trace Configuration tool, a trace configuration can be saved to the database so users in the desktop, web, and mobile can use the same trace you’ve just authored. To do this, open the Add Trace Configuration tool, configure your trace, name it, and run the tool to make it available to others. In our case, we will be creating three separate trace configurations, one to show valves to isolate an area and another one to show everything that is isolated.
If you wanted to, you could create additional trace configurations to select only the customers isolated by creating and assigning a network category for customers then adding an output condition to the trace for this network category.
Once you’ve created all your named trace configurations, you can quickly access them using the Named Configurations tab on the Trace pane. This is not only more convenient than launching the trace tool, but traces run through this tab are actually faster!
Conclusion
This covers the initial set of configurations that can be applied to a pressurized network, such as those found in the gas and water distribution industries, to help get you started with analysis. If there are other, more advanced configurations like pressure zones or cathodic protective structures that you want to know more about, let us know! If you have any questions about utility networks, be sure to ask them on the Esri Community site.
If you want to know more about using the utility network to manage pressurized networks, like gas and water systems, please explore the Learn ArcGIS Utility Network for Water Utilities and Learn ArcGIS Utility Network for Gas and Pipeline learning series. This learning series includes tutorials and articles that demonstrate how to address the needs of these industries using the utility network.
