Edited 7/31/2023
GIS solutions differ widely between utilities. Utilities often leverage maps to support asset management through field inventory and asset location with easy-to-use map interfaces. Some may use GIS to augment their operational schematics to help engineers navigate to critical protective devices in the field. Others may use GIS to support routing engineering, design, and construction and to provide the source of that information to reduce costs and impact to local communities.
The common thread in all of these scenarios is that tracing is key to gaining an understanding of your assets as they are connected and operate in the field. The objective of this blog is to delve into the trace operation to gain a better understanding of the many parameters of the trace geoprocessing tool and to understand how tuning the trace parameters can return very specific results.
The ability to return specific assets based upon the spatial layout and representation of the equipment as it’s connected in a system is called a network trace. Simply put, the ability to traverse assets based upon system connectivity is one of the most frequently used spatial analytics for utilities. It can tell us where the closest protective device is so that crews may conduct maintenance during system failure. It can show how we are servicing our customers or how we can optimize our equipment to provide service in the most cost-efficient manner. To understand the capabilities of the trace mechanism, let’s explore the following capabilities of the tracing framework:
Starting Locations
The simplest way to represent a trace is to start with a couple of devices connecting to a line. In this case, we start with a fuse on the left side connected to a low voltage line which is connected to a customer meter on the right side. The map is bracketed by the Trace Locations panel on the left, and the Trace geoprocessing tool on the right.
To traverse this line and points we start by setting a start point (Green) on the device to the left. Starting points don’t have directionality, but instead, provide a location from which the trace will traverse in all available directions.
Trace capabilities are a function of the Trace Locations Pane and the Trace geoprocessing tool which can be found in the Utility Network tab on the ribbon or within the Utility Network Geoprocessing Toolbox. There are eight basic trace types that define the basic algorithm used to perform the trace analysis. Check out the utility network trace types for more information and a primer on each one. The Trace Locations Pane enables you to configure a trace-based upon established Starting Points and Barriers. While the Trace tools provide a common interface for all the trace configurations.
Using the trace geoprocessing tool, the traversal is returned as a selected set of features. The starting point of the trace may be placed on a point, on the edge of a line, or even on a nonspatial junction or edge object that has connectivity with the network features (more details on nonspatial junctions and edge objects can be found here). To facilitate this initial trace, a simple connected trace is used to return all the elements that are connected to the starting point. The starting point is not represented as a graphic, but as an actual feature that’s stored in the UN_Temp_Starting_Points feature class in the project’s default file geodatabase.
Note: Trace locations can be created in one of three ways. Using the Trace Locations pane you can use the Add Features command to create a new feature in the map (which can be coincident with utility network features), you can use the Add Selected tool to create a trace location from a preselected feature or nonspatial object, or by specifying a user-defined feature class or table to serve as wth starting point or barrier.
After placing our starting point, we selected the Connected trace from the trace gallery and ran the trace using default settings.
Now that we have executed our first trace, let’s start including some constraints into the trace using barriers. The simplest barriers are feature barriers. These are created in the map using the same panel that was used to place the starting point. In the below example, we removed the start point graphic to see the point of origin to help visualize the results of the trace. Looking at the trace below, the fuse feature on the left side of the trace was returned but because the barrier is set on the line that is contiguous from the fuse to meter, it was not selected from the result of the trace.
Looking at the parameters under the Barrier drop down on the trace geoprocessing tool, we can see an option that lets us include barrier features. This is where the trace behavior gets interesting. Executing the same trace with the included barrier features actually returns a portion of the line to the meter point (which is not returned in the trace selection). However, in configuring this trace, we have another parameter that provides us with a method to gain additional information as part of a trace. The Aggregated Geometry Result Type generates new multipart feature classes for the trace results to include all point, line, and polygon features returned (Note: By default, these are created in the same file geodatabase as the starting points and barriers mentioned earlier but can be saved to any appropriate location for feature classes). What’s interesting about the Aggregated Geometry output is that it allows us to return partial features up to the location of the barrier. So while the trace selection returns the whole line on which the barrier is placed, the aggregated line generated is only a fraction of the line up to the barrier location.
Additional parameters in the tool interface enable additional precision to control the various output results in the trace configuration. You have the ability to expand the behavior of the trace process to include containers, the content of any containers, or any structural elements associated. More details regarding these options can be found in the documentation located here.
Connectivity and Traversability
Before moving directly into the trace tool’s parameters, it’s important to understand two properties of a trace, connectivity, and traversability. Connectivity describes the state where two or more features share a connectivity association or are geometrically coincident at an endpoint or midspan vertex and a connectivity rule exists to support the relationship. The previous example of a simple trace without a barrier demonstrated how the points and lines had connectivity and traversability. When we introduced a barrier, those same features still had connectivity, however, traversability was blocked by the feature barrier which led to different result sets between the two traces. Traversability is used to describe state for connected features that also have a path between them that satisfies the trace configuration. The graphic below shows us the difference between connectivity and traversability in a little more detail.
Prior to the release of the ArcGIS Utility Network; traversability depended upon features having coincident vector points. That meant that for features to be traced, points had to be connected directly to the end vertex of the lines. In the past, network weights were used to apply both significance and flow directionality. In the utility network, we designate special properties to features in the utility network to define traversability across the network.
Let’s start first with a Network Tier; the Tier enables specific business properties and drivers to be applied to elements within that designated Tier.
Examples of Network Tiers can be seen by looking at an electric utility. Some electric companies have equipment that moves electrical load from central generation stations to local distribution substations. This transmission equipment is likely to have significantly different wire, facilities, and properties than the distribution assets that move load from the substation to your home. In a utility network, these two tiers (transmission and distribution) would have different line and device properties and most likely have different properties that would be analyzed during the course of business.
One of the properties of the network tier is the ability to assign Network Categories to elements of the network. So Network Categories are system tags that enable you to designate devices with special properties of the Network Tier. There are three system-provided Network Categories: Subnetwork controller, Subnetwork tap, and Attribute substitution. Subnetwork controller (which allows you to designate device configurations so that they can establish feeder or circuit properties that we describe as the Subnetwork). Subnetwork tap designates a device or a junction as having the ability to divert flow and apply properties to that pull-off such as phase or flow volume. So when the conductor with ABC phasing encounters a Subnetwork Tap at a midspan vertex, that tap can designate that phase B can be pulled off the main conductor. The trace recognizes the pull-off wire because the point with the Subnetwork tap category sits midspan of the mainline and the new wire is the designated phase value. Attribute substitution can also be applied to features with a Subnetwork tap designation which enables a substitution value to be inserted as a result of the trace. Other Network Category tags can be used to establish special properties to devices or junctions as traces are executed. Some examples of these tags could be Protective to establish a tag for special protective devices on the systems, or network ties to establish those normally disconnected points in the system where your assets connect with a neighboring utility. Network Categories are especially helpful in designating certain network features as barriers in the course of a trace.
Network Attributes are fields in utility network feature layers that have been designated or assigned as having special properties. This assignment enables those fields to directly participate in the network index.
Network Attributes and Categories can be used in the trace parameters to create conditions that result in a network barrier to traversability or they can be calculated in a function that is output with the results of a trace (in the accompanying message). System-provided Network Attributes include the Asset Group and Asset Type fields along with Is subnetwork controller. The user-defined network attributes are often used to represent device characteristics that are modeled as an operational state (connected or disconnected), status (in service, retired), value (units consumed or regulated), or to establish the property or behavior of the element (diameter, or weights).
One last thing to cover before we dive into trace properties and parameters found on the tool itself are the specific points of connection designated on operational devices or junctions. These Terminals are used to model assets with greater detail and to help to establish flow direction based upon the properties of the device or junction. For example, a pump device could be configured with terminals to establish the high-pressure connection to the pump, to limit the ability for pipes that could be connected to that high-pressure terminal, and to establish the direction of flow through that pump. The traversability through terminals is established using preconfigured terminal paths in the properties of the junction or device it’s to which its assigned. Appropriate connectivity to lines is defined using the Modify Terminal Connections Tool. An example of terminal configurations is shown below.
Condition Barriers
The Condition Barriers enable a user to create barriers that stop at a traversability barrier when the conditions set by a Network Category or Network Attribute are satisfied.
Prior to setting up this trace parameter, we added two tap features from the Operational Junction layer at midspan vertices. Before we can trace, we need to validate my network to clean the dirty areas created and update the network index with the new line and point configurations. In the Traversibility section of the Trace tool, we have established a Condition Barrier using a Category as equal to Subnetwork Tap (my new Tap features have the Subnetwork Tap tag appended to them). Prior to running the trace, we added the Aggregated Geometries Result Types option as an additional output to show how the line is traced to the first tap configuration.
With this example, we can see how Condition Barriers can use Network Categories to create a traversability barrier for the trace output. Let’s next use a Network Attribute (phasesub) that exists on the Tap features as a traversability barrier. Executing the same trace again shows that the line traversal stops at the second tap using this configuration.
The Function Barriers use network attributes and function operators to establish barriers. To run the trace below, we will take our line feature then split it into a few smaller line segments, we can then re-validate the network topology to the network index. Now, using a Function Barrier, let’s use an Add function which will sum the targeted Network Attribute (Shape_Length) as it traces the line until a value of 19 feet (the total line length is about 30 feet). Looking at the Shape_Length of the Aggregated Line calculation we see that the rounded total length is of the trace result is 18 feet because the barrier was created at 19 feet down the line.
Count functions can be used in a similar fashion as well. For example, we might be interested in setting a barrier after counting a number of features. Using the Count function and the phasesub network attribute the function creates a barrier after it reaches the fourth junction point down from the start point where a barrier is set. The Aggregated Geometry feature marks the sum distance up to that fourth point.
Let’s go back to our Add function and see what happens when we add a few additional lines to our features. Tracing from the starting point at the fuse, the function is set to create a function 25 feet down the line. Because there is an alternative path at the first line junction, the trace continues in both directions to set the barrier after traversing 25 feet.
Now that we have walked through all the traversability parameters, let’s expand the trace to include pole structures attached to connection points. In the below dataset we have created a few additional features. We have a transformer at the location of the low voltage line in place of the original starting point and connected to the low side terminal of the transformer and a new medium voltage line is connected on the high side transformer terminal with a circuit breaker on the high side of the medium voltage line which is configured as a network controller. We have also added 14 poles with structurally associated connection points. With these updates, we now have a full subnetwork with medium voltage and low voltage lines, devices, junctions, and structures. Since the subnetwork definition has been configured to include Structures, using the Find Subnetwork tool, we can trace the entire subnetwork to return all the network features.
Output
What if we wanted to trace the subnetwork but only return a certain type of pole (wood)? Output Asset Types allows me to filter out elements of the subnetwork by their asset type to return the specific pole configurations. In the below example we have configured the trace to return only Structure Junctions of the Pole Asset Group and Wood Asset Type. As you can see, the Concrete and Steel poles were not returned.
Functions
Up to this point, we have returned selection sets or aggregated geometries from the trace. Functions in the Trace tool also give us the ability to return functions in the message box from the trace parameter. In the below example, we have configured a Function to return the number of line spans traversed by counting the occurrence of Shape_Length values and then returned the average span distance using the same network attribute. In this instance, we used a starting point and a connected trace, so the entire dataset was selected, but the message box returns the results of my Function request.
Because we have defined a network controller and a subnetwork, we have the ability to leverage upstream and downstream traces.
To add some context, we added fuses at the line intersections; more on that to follow. With the upstream trace, the result begins with the starting point and traverses upstream to the network controller. The trace framework actually executes two traces to provide us this result. First, it travels outward from the starting point out in all directions until the network controller is discovered(our Circuit Breaker). Once located, the second trace returns the result set from the starting point to the controller.
Another type of trace that uses two iterations to bring back the result set is the Isolation Trace. In addition to knowing the location of the network controller, the Isolation Trace requires a Filter Barrier to identify the valve or switch upstream of the starting point that would most efficiently isolate the trouble for repairs to begin. Filter Barriers allow traversibility during the initial trace to discover the network controller before acting as a barrier feature on the second pass. In this example, the fuses located at the line intersections have a Network Category value of Protective. When the trace is run, the closest upstream protective device is returned and would represent that element in a disconnected state until repairs are made.
The final trace that we want to cover is the Shortest Path trace. It’s a bit different from the other trace configurations covered in this blog thus far because it requires two Starting Points as well as a network attribute (in this case Shape_Length) to determine the shortest path from one location to another.
To run this trace, we have added more line and point features to create a loop. The result of this trace returns the left path alternative route as a shorter path between the two starting points as opposed to the right path due to its use of the network attribute to sum the length of each option.
Conclusion
As we transition from traditional information management to enterprise systems, there are a number of workflows that might require some reconsideration. There is no doubt that GIS solutions for utilities can mean different things to different users, but our need to support asset management through field inventory and asset location in easy-to-use map interfaces remains a broad requirement for all. We have the opportunity to reconsider some of the best practices to augment our operational information with enriched network data to help engineers be more responsive in the field. The ability to leverage network traces in the same manner that we learned to configure table-based queries will enable engineering, design, and construction to be more responsive, reduce costs, and have a more sustainable impact on local communities.
We hope this blog gave you the opportunity to explore trace configurations a little further and to enable you to improve your network-based spatial analytic capabilities for your customers, communities, and business. If you have any questions or ideas, please join the Esri Community for the ArcGIS Utility Network.
Commenting is no longer enabled for this article