We’ve now covered many of the core components that make up the Utility Network and now it’s time to talk a bit more about how we compile all of this information together into an efficient and meaningful network. Before we jump in, here’s my standard disclaimer with some good prerequisite reading:
- Esri Utility Network – Data Model 101: covers the basic components of a domain network (device, line, junction, assembly)
- Esri Utility Network – Introducing the Structure Network: reviewed the new concept of adding structure junctions, lines, and boundaries into the network as well as introduced containment associations and structural attachment associations
- Esri Utility Network – Modeling Device Terminals: discussed how network devices support terminals to model real life connection points on a device and introduced connectivity associations
To allow the data components covered in our previous posts to be joined together into a true network, we will create a collection of rules. The rules control which types of features may be connected or associated with other types of features.
As noted in the data model 101 post, we can have multiple domain networks within one utility network. The rules may even reference Classes/AssetGroups/AssetTypes in other domain networks that will allow us to establish connectivity between domain networks.
Similar to the geometric network today, you can imagine how we would establish connectivity rules between geometrically coincident feature types (now AssetGroups/AssetTypes). But don’t miss the italicized text above. The rules also define the allowable connectivity associations (point to point connectivity), the containment associations (a transformer bank can contain transformer devices), and the structural attachment associations (a transformer bank can be attached to a pole).
All of this information will be compiled into the new network making it extremely fast to retrieve the data and corresponding rules. As a reminder, this now includes retrieving structures associated with any network trace via the structure network as previously discussed!
Before continuing, let’s ask a very basic question. Why do we need a network in the first place?
Traversing connectivity through the map and/or Esri relationship classes is relatively slow. It may not be slow for simple operations or a limited set of data, but when you begin to traverse large circuits or systems, using the map geometry or relationships will bog down the system and the user experience. The solution? Create a logical network.
A logical network uses straight tables to establish connectivity. At the simplest level, the logical network maintains tables of nodes and edges (corresponding to map features) along with connectivity between them (i.e. node A connects to line B and line B connects to node A and node C). This allows network traversal without any map geometry or relationship classes which makes the logical network extremely FAST!
The geometric network that we know and mostly love, has always maintained a logical network behind the scenes which allowed us to perform tracing and connectivity analysis. The new utility network also contains a logical network for the same purpose which is now called the Network Topology.
Based on the rules mentioned above, the network topology stores connectivity, containment, and attachment information used by the utility network to facilitate fast network traversal and analytic operations for the domain network(s) and the structure network.
It differs from today’s logical network in several ways including support for containment and attachment associations and several other optimized aspects (both in data components/storage and functionality which we’ll cover further in a future post). For now, rest assured that Esri took the lessons learned from today’s network and used them to drive the design of the Network Topology. It’s a lean, mean connected machine!
This leads right into the second topic I want to cover in this post which is directly based on the Network Topology: Tiers and Subnetworks
Tiers within your domain network (note: structure networks do not support tiers) provide you the ability to further distinguish business-oriented levels within a domain network. A single domain network can therefore have multiple tiers.
You will generally think about tiers as collections of connected features that represent subnetworks (defined further below). Let’s first look further at tiers through some examples.
On the electric side, tiers have generally been discussed surrounding voltage levels. Depending on the data you maintain, you may have a high voltage tier (transmission voltages), medium voltage tier (primary voltages), and low voltage tier (secondary voltages).
On the gas side we are seeing tiers organized by gathering (wellhead to compressor), transmission (compressor to town border station), and distribution (town border station to customer/meter).
Each tier will have many defined subnetworks. Each subnetwork within a tier will have either a defined source (circuit breaker, transformer, town border station, well, etc.) that will act as the origin of the commodity that flows through the subnetwork or a defined sink (a sewer/gravity-driven network will utilize a sink) that will act as the destination of the commodity that flows through the subnetwork.
A subnetwork is generically defined as a connected sub-portion of the network. These will be circuits in electric and pressure systems and/or isolation zones within gas or water. Each subnetwork will be associated with one or more source/sink devices which provides support for linear or mesh networks (where multiple sources/sinks are connected to the same subnetwork). So as you think about the tiers you will manage in the utility network, a good starting point is your circuits/systems/zones that you manage in the geometric network today.
The configuration of a domain tier will include which domain network line types, defined at the AssetGroup/AssetType level, can be included in the tier. This will prevent the case of a low voltage (secondary) line being placed within a high voltage (transmission) subnetwork. Data errors such as these will be discovered and documented as line errors when the subnetwork tools are run within the utility network. This design was key to Esri as they seek to ensure valid data is added to the new networks.
Each subnetwork within a tier will be defined by a subnetwork name and the tier name along with an aggregated (single feature) geometry that will be stored in the domain network SubnetLine feature class as we discussed in the Data Model 101 post. The subnetwork name (circuit/system name) will be automatically saved onto all features participating in the subnetwork providing true end-to-end network management.
We can’t quite talk about the detailed functionality of the Utility Network in our blog quite yet, but in recent exciting news, we have been cleared to demonstrate the Utility Network at the GeoConX conference next week! So please stop by our booth to check out how the new out-of-the-box tools manage everything we’ve been blogging about for the past several months – connectivity, containment, circuits, tracing, and more!
While visiting, confirm your commitment to the SSP/Esri road map to Utility Network and enter to win a free trip to Keystone, CO this winter! You can’t beat that offer! We look forward to seeing you in Phoenix next week!!