Modeling related data in a utility network
One of the unique features of the utility network is its ability to model connectivity using a combination of spatial and non-spatial objects. This capability has been used by many customers to create their digital twins because it allows them to include detailed information about network assets in the connectivity model. This article describes several of the most common techniques for modeling these assets, and the pros and cons associated with each technique.
You can find a presentation discussing the approaches taken by electric utilities in the Electric Utilities: Deep Dive presentation from the ArcGIS Solutions team. There are different patterns used to capture these details, and when customers are implementing their models, they often ask what is the best practice for capturing these details?
Start by looking at your requirements. Downstream systems expect more details to be stored in GIS to meet the evolving requirements of Operations and Engineering. Locations that contain equipment critical to operating the network are now being modeled at a higher level of detail to meet those requirements. Instead of modeling a station (pump, substation, etc.) as a single point on the map, all the major equipment required to analyze and operate the real-world network is stored in the GIS as separate features that are connected to the network model used by the digital twin.
This makes sense for these larger structures, but we can also take this approach down to any location where there are multiple pieces of equipment being represented by a single point on the map. If you have an apartment complex with a meter bank, do you need to draw every customer meter and pipe? Is it sufficient to continue to represent the meter bank as a point with all the customers related to it?
The truth is there is no single best practice, the answer depends on your requirements and on the type of information being modeled. What we will do in this article is explain the different approaches and provide the pros/cons of each approach so you can draw your own conclusions based on your specific situation. It is important to note that most projects use a hybrid approach in their implementation, choosing to implement different patterns based on the type of location.
Each of these approaches models every significant location of the network using a feature, typically a device. The difference is how the individual components of that location are modeled.
- Related records – The details of the location are stored in tables that are related to the device.
- Nonspatial content – The details of the location are represented as nonspatial objects that are contained within the device.
- Nonspatial connectivity – The details of the location are represented as nonspatial objects that are contained within the device, connected with each other, and connectivity passing through the device passes through all its content.
With the definitions out of the way, let’s look at the pros and cons of each approach, with examples.
Related records
The related records approach is the way that this challenge has traditionally been solved using GIS. The GIS would show a single point on the map, like a substation or a transformer, and the details about the equipment at that location would be shown as related records in the GIS or even captured in an asset management system.
Below you can see a picture of a Transformer (Electric Device) with a related Distribution Transformer Unit (Transformer Unit).
Pros
The benefit of continuing to model features this way is that it keeps the amount of data being stored in the network to a minimum, which means tracing and validating is faster, and it doesn’t impact the way you manage your network data. If you’re worried about how to extract these details for network analysis, there is even an option to include specific related records in your network exports. Additionally, because related records do not belong to the network you don’t need to worry about edits made to these features impacting the network topology.
Cons
However, this benefit is also a drawback. Because related records are not part of the network, they are not included in any of the network analysis or validation that the utility network performs. The network rules and restrictions you rely on to ensure the data is correct do not apply to related records, and must be enforced using other mechanisms like relationship rules, data reviewer checks, etc.
Additionally, exporting values from related records is slower than exporting network attributes because network attribute information is included in the trace results automatically but the information from related records must be queried from the tables.
Finally, because the related records are not part of the utility network there are not any system-maintained fields that describe their association status or subnetwork information. This information can be determined by looking at the related network features.
Pros | Cons |
Editing workflows are not impacted | Related records cannot be included in analysis |
Adds, deletes, and updates to related records do not create dirty areas | Related records are not part of the subnetwork |
Related records can be exported as related features | Exporting related records is slower than if they were content |
| Locating and analyzing units spatially requires additional work |
Nonspatial content
Modeling additional details using nonspatial content involves migrating all the important related records to nonspatial objects in the utility network (junction objects and edge objects) then turning the corresponding relationships into containment associations. This allows you to turn tabular records into nonspatial network objects that can then be included in analysis, exports, and participate as content of a subnetwork.
Below you can see a Medium Voltage Transformer (Electric Device) that contains an Overhead Single Phase Transformer (Electric Junction Object).
Pros
But what does it mean to participate as content of a subnetwork? Features that are discovered while tracing a subnetwork are part of the connectivity for that subnetwork. Features that have an association with one of the connected features can be included in that subnetwork as content, containers, and structures. This allows associated features to appear in the subnetwork when traced, can be included in calculations for that subnetwork, and can easily be exported with the subnetwork.
Nonspatial content is also validated and included in the network, so it benefits from all the rules and configuration of the utility network. The workflows and tools for creating and maintaining nonspatial objects as content are different that maintaining related records, but they are similar enough that they shouldn’t pose a significant additional editing burden.
Cons
The most obvious downside to using nonspatial objects instead of related records is that you are now including more features in your network. This means that tracing and validation will have more features to process, so the more features you manage in your network the longer these operations take.
You can mitigate the performance impact to trace by choosing whether you want content, attachments, and structures in a utility network to be included in your trace results using the Include Containers/Content/Structures option in the trace configuration.
Likewise, you can control this behavior in update subnetwork in two ways. First you can choose whether you want to include associated data in the trace, using the same options for the Subnetwork Trace Configuration. Then you can also choose whether you want update subnetwork to populate the subnetwork name field on these features using the Update Subnetwork Policy.
The next thing to be aware of is that changes to these nonspatial objects that affect the network must be validated. You need to consider the workflows you have for editing these nonspatial objects and be aware of their impacts. If you have field crews that are installing or replacing thousands of nonspatial objects every day, you’ll need to have a process in place to validate those edits.
Finally, because nonspatial content is not included in the connectivity of the network it cannot influence the results of the trace. You can’t stop a trace when a device contains a nonspatial object in a particular status (open/closed), only the features that are discovered through connectivity can affect the trace.
Pros | Cons |
Workflows are similar to maintaining related records | Adds, deletes, and certain updates create dirty areas |
Included in functions and analysis | Cannot affect traversability of trace |
Validated as network features | Validates require additional time to identify and validate content |
Easily exported as subnetwork features | Tracing and update subnetwork performance can be affected |
| Locating and analyzing units spatially requires additional work |
Nonspatial connectivity
The final method of representing these additional details is to use nonspatial objects that are part of the connectivity model. This is done when you need to control the tracing and analysis of the network using features that it isn’t practical to represent and maintain spatially. The most obvious example of this is communication networks, where a single cable can contain thousands of connections on either end of the cable. In these situations, the approach is the same as with nonspatial content, but you also create connections between the spatial and nonspatial objects that allows analysis for a continuous set of connectivity for the subnetwork through both spatial and nonspatial objects.
Pros
The main benefit of this approach is that the nonspatial objects can fully control the analysis of the network. This makes it possible to do more advanced, fine-grained calculations like determining demands on a particular wavelength of light or phase of electricity. In addition to this it means that nonspatial objects have their own state, allowing them to act as barriers to tracing or to model a mixture of in server, proposed, and abandoned equipment at the same location.
The other benefit of modeling these details as nonspatial objects is that because they do not have any geometry you do not need to worry about how they will be drawn on the map, or how you will manage the cartographic clarity of a location that contains thousands of objects at large scales. Content is part of the subnetwork
Cons
Even though you don’t need to worry about maintaining a spatial representation of this data, one of the largest challenges to maintain large nonspatial datasets is that you need to create processes or tools that make it easier to view and maintain the connectivity of these nonspatial objects. Creating and editing relatively simple collections of nonspatial objects, like three-phase switches, does require more work than maintaining them as related object but is still reasonable. Maintaining complex connectivity structure like entire stations, treatment plants, or fiber splice enclosures requires special tools and workflows.
Pros | Cons |
Included in tracing, functions, and analysis | Workflows are more complex than maintaining related records |
Validated as network features | Data is harder to understand from a simple web or mobile application |
Easily exported as subnetwork features | Adds, deletes, and certain updates create dirty areas |
| Validates require additional time to identify and validate content |
| Tracing and update subnetwork performance is affected |
| Locating and analyzing units spatially requires additional work |
Note: The performance impact of tracing non-spatial objects can be mitigated by enabling and using Cluster Keys on your network features. Once this is done the main performance impact of this approach is that more objects are included in every network and this increases the amount of time it takes to analyze or update them.
Conclusion
Now that you’ve read this article you are familiar with the three basic strategies for modeling related network data using a utility network. You are aware of the pros/cons of these strategies and know that you can use different strategies for different objects.
The following table summarizes some of the key pros/cons from the sections in this article:
Requirement | Related Records | Content | Connectivity |
Analyze with trace |
|
| Best |
Trace performance | Best |
|
|
Update subnetwork performance | Best |
|
|
Extract network information | Yes | Yes | Yes |
Network content validated | No | Yes | Yes |
Validate Network Topology performance | Best |
|
|
Editing experience | Best |
|
|
