You are here

Esri Utility Network - Simple and Scalable Network Data Model

Network Data Model

As your company gears up to adopt Esri's Utility Network (UN) you may be feeling excited about the new technology, but perhaps also a bit apprehensive about the new network data model. Particularly when in the back of your mind you may have the following two nagging questions:

  • How is the data organized within the Utility Network?
  • What will happen with my current data as I migrate from the Geometric Network to the Utility Network?

Esri and its partners are, of course, aware of the need for data migration and prepared to help you in the process. We at SSP believe that the more you know about the Utility Network yourself, the better prepared you will also be for this effort.

So, as you wonder what is going to happen to your data, let us first start by understanding how data is organized within the Utility Network.

Esri Utility Network: A Simple and Scalable Network Data Model

As already discussed in other articles in this series (particularly the introduction to the Utility Network Model) Esri offers a simple, yet effective and highly scalable network data model with its new Utility Network.

UNEA - EA Reinventing GIS - Model Diagram - Network Data Model

When compared to the Geometric Network, which in many implementations may consists of a couple dozen feature classes, the Utility Network supports:

  1. Just two types of networks: a single Structure Network to model the supporting infrastructure, and zero or many Domain Networks to model the assets delivering the commodity.
  2. The Structure Network implements only three feature classes, one for each geometry: Junction (point), Line (line), and Boundary (polygon).
  3. Each and every Domain Network has only five feature classes. Three of them for point geometry: Device, Junction, and Assembly; the other two for lines: Line and SubnetLine. (NOTE: The SubnetLine is a feature class for internal use by the Utility Network to implement and manage Subnetworks. It plays no role during network data modeling. So, in what follows we do not concern ourselves with the SubnetLine feature class.)

By limiting the number of available feature classes, and by abandoning relationship classes (relying instead on the concept of Associations), the Utility Network model is clearly simplified.  

Looking "under the hood," the core schema of the feature classes, itself, is also simplified by minimizing required attribution. The bare minimum of the schema is described below.

Bare Bones Feature Class Schema

(NOTE: I will take the liberty of comparing some aspects of the Utility Network with respect to the Geometric Network to highlight similarities and differences.)

The schema for the seven distinct feature classes in the Utility Network (we have excluded the SubnetLine) can be represented in a UML diagram, showing the following default attribution:

UNEA - EA Simple and Scalable - UN UML Diagram 2 - Network Data Model

(NOTE: Esri does not use the above diagram to implement the Utility Network feature classes. Rather, this is a simple diagram to display common vs. specific default attribution, in grey, and the potential custom attribution, in yellow, within the seven distinct feature classes of the Utility Network.)

The diagram shows a parent Feature Class with default attributes common to all Utility Network feature classes. Two children, StructureNetworkFC and DomainNetworkFC, inherit all the common attributes from the parent class, and extend the attribution based on the two categories. Each category can be endowed with any number of custom attributes (yellow), which are then inherited by the corresponding children. Specific default attribution further differentiates the individual feature classes (blue). In what follows we describe the default attributes, and explain the versatility implicit in the custom attributes.

Default Attributes

OBJECTID

Strictly for internal use by the application, the OBJECTID uniquely identifies each feature in a feature class within the GIS. (Similar to the Geometric Network.)

SHAPE

The SHAPE field reflects the geometry of the feature. It is also for internal use. The Line and Structure Line feature classes also have an additional SHAPE.STLength() field. The Structure Boundary feature class adds a SHAPE.STArea() field to the geometry description. (Similar to the Geometric Network.)

GLOBALID

Like the OBJECTID, the GLOBALID values are managed internally by ArcGIS. They uniquely identify each feature across the whole Enterprise Solution. (Similar to the Geometric Network.)

CREATIONDATE, CREATOR, LASTUPDATE, UPDATEDBY

These four default fields are also internally managed by the application, which automatically tracks who makes edits to the features and when. (Contrary to the Geometric Network, there is no need for additional code to auto-update these fields.)

ASSETGROUP

This field, driven by a configurable coded value domain (subtype field), provides the major classification among the features within each feature class. For example, in an Electric Distribution Domain Network we can find Transformer, Switch, Service Delivery Point, Capacitor, and others as the major asset classification for its Device feature class. While Pole, Vault, and Pad would differentiate among features of the Structure Junction. (Not in the Geometric Network.)

ASSETTYPE

Minor classification within an ASSETGROUP is provided by the different types available in the group's ASSETTYPE coded value domain (another subtype field). For instance, the Fuse ASSETGROUP may differentiate among Current Limiting, Expulsion, and other fuse types. (Similar to Feature Class Subtypes in the Geometric Network.)

CONTAINMENTSTATUS

By default, this field takes its value from a ContainmentStatus coded value domain used to indicate whether the feature participates in a containment association and, if so, whether it plays the role of container, contents, or both. It also may inform whether it is visible in a container view. (Not in the Geometric Network.)

SUBNETWORKNAME

Field to indicate "participation" in a subnetwork. (Click here for more information about subnetworks.) Natively, ArcGIS Pro will store in this attribute the feeder/circuit ID of the corresponding subnetwork, and it will update the value to respond to local configuration changes in the network. (Not in the Geometric Network.)

ISCONNECTED

Field in the Device, Line and Junction feature classes of a Domain Network to indicate whether the feature is connected to the network. (Not in the Geometric Network.)

FROMDEVICETERMINAL, TODEVICETERMINAL

Field in the Line feature class of a Domain Network to establish default from/to connectivity via terminals. However, connectivity rules can be configured in Utility Network to accommodate specific from/to associations to better model real connections. For instance, an Electric distribution model may configure such a rule to impose that Secondary Lines can only connect from the low side terminal of Service Transformers. (Not in the Geometric Network.)

TERMINALCONFIGURATION

Field in the Device feature class optionally associated to a terminal configuration (i.e., a description of how many terminals a particular device of a given ASSETGROUP and ASSETTYPE has, and how these terminals provide connectivity for the device to the rest of the network).

TIERNAME, TIERRANK

Field in the Device feature class of a Domain Network to indicate their Domain Network Tier participation. (Click here for more information about tiers.) (Not in the Geometric Network.)

SUBNETWORKCONTROLLERCATEGORY

Field in the Device feature class of a Domain Network to indicate whether the particular device acts as a source, or a sink of the commodity, or neither. For instance, in an Electric Domain Network, a Device feature of the Switch ASSETGROUP and CircuitBreaker ASSETTYPE within a substation is commonly modelled as a distribution circuit source. (Not in the Geometric Network.)

SUBNETWORKCONTROLLERNAME

Field in the Device feature class of a Domain Network whose value reflects in which subnetwork the asset participates. As with SUBNETWORKNAME, ArcGIS Pro internally manages this field to store the value of the feeder/circuit ID, and its updates as the network topology changes through edits. (Not in Geometric Network.)

Custom Attributes

Any number of custom attributes can be added to any of the seven distinct feature classes. The custom attribution allows you to model the details of all your assets, whether structural or domain-like. Custom attributes are versatile. Here are a few properties they have:

  1. They can represent any data type.
  2. Their values could be derived from coded value domains.
  3. Their values could be used within Utility Network connectivity validation rules. (Ex.: The diameter of pipes and connecting fittings.)
  4. Custom attributes can be chosen to influence the results of traces. (Ex.: Downstream trace on 7.2KV, B-phase, and stopping at open devices.)

Custom attribution, together with rules imposed by their values give each Utility Network implementation their specific identity. In an abstract sense, a gas valve in the Utility Network with default attribution is just a point Device feature of such and such asset group and type, with a given terminal configuration, etc. Via custom attributes, however, a Gas Utility may extend the gas valve model as a Device with size, a kind of material, an inspection date, depth beneath the street surface, an asset number, etc. And also, such that it can only connect to the network through fittings, of the same material, and whatever other rules.

At this point I hope to have answered the first question: "How is the data in the Utility Network organized?" As a reduced set of feature classes, with minimal default attribution, and openly customizable by asset group, asset type, and any number of custom attributes.

Migrating to the Utility Network from the Geometric Network

What about the second question: "What will happen with my current data as I migrate from the Geometric Network to the Utility Network?"

The simplicity and versatile scalability of the Utility Network data model is what allows you to migrate your current Geometric Network model into the Utility Network. Esri and partners are developing tools to facilitate this process. In particular, SSP has already developed migration tools to start working with the Beta release of the Utility Network. One such tool was run on sample data (SSPTown), and demonstrated during GeoConX 2016. Production client data has also been migrated by SSP to support some of the Utility Network Jumpstart sessions we offer to our clients.

SSP's migration tools are fully configurable, and we work with you to devise a mapping between your current Geometric Network feature classes and any of the seven distinct Utility Network feature classes. For instance, transformer banks will map to the Assembly feature class with and ASSETGROUP of, say TransformerBank, and ASSETTYPE based on your Subtype: Pad Mounted, Overhead, etc. We will extend Assembly with custom attribution such as KVA, Phasing, and any other number of attributes that you may want to preserve during migration.

Similarly, we will map poles into StructureJunctions of ASSETGROUP SupportStructure and ASSETTYPE of Wood, Cement, Tower, etc., with custom attributes such as height, class, PoleID, and others.

We will work together to replace your FuseBankToFuseUnit relationship class with Containment Association rules between the FuseBank Assembly and the Fuse Device; where now your fuse feature truly represents a locatable asset that participates in the flow of your commodity. (See Appendix for further explanation of these concepts.)

Thus, you are not losing your data. You are keeping as much of it as you need, as we migrate it together.

Practical Implementation

A cautionary note before we conclude: In this article, we have focused on describing the seven distinct feature classes of the {Network} and their attribution. However, let it be clear that in all practical implementations of the network data model, there will be three structure feature classes and "Nx4" domain feature classes for you to configure, where N corresponds to the number of domains chosen by the utility to represent their networks.

For instance, a gas and water utility may choose to have two domains: one for each commodity. As a result, the Utility Network model in this case would be implemented by a total of 11 configurable feature classes. (NOTE: this is way less than any common Geometric Network implementation.)

Also, if the utility implements several domains, let us keep in mind that the default attribution in the four domain features in each domain is the same, while the custom attribution may be different in order to represent the particulars of each domain.

Summary of the Utility Network Data Model Details

The Utility Network data model is simple and scalable. It offers two types of networks: Structure and Domain (simplicity). By default, you are given one, and only one Structure Network. Then you may create as many Domain Networks as you need (scalability). Overall there are only seven distinct feature classes exposed to the modeler, with a schema of anywhere between ten and sixteen default attributes (simplicity). In particular, with ASSETGROUP and ASSETTYPE, and with the capability to endow any feature class with any number of custom attributes the model is extremely versatile (scalability).

In closing, Utility Network gives you, the modeler, absolute control of the way in which you organize any and all the assets distributed throughout your service area (simple scalability).

APPENDIX: A Closer Look at ASSETGROUP

The major classification into arbitrarily many asset groups in the Utility Network represents a drastic departure in data modeling with respect to the Geometric Network. For instance, let us consider a three-phase overhead transformer, its protecting fuses, and the supporting pole, and let us see what it would be needed to model this ensemble in either of those two networks.

If following the ArcGIS Electric Distribution Data Model for the Esri Geometric Network, we would need:

  1. One TransformerBank feature class to represent the location of the ensemble, with some overall electric attribution.
  2. Snapping properties with electric lines, and geometric coincidence to ensure connectivity. However, no explicit knowledge of how the devices are connected to the network!!!
  3. One TransformerUnit object class to represent asset properties of individual transformer equipment at that location.
  4. One relationship class associating TransformerUnit with TransformerBank to represents the transformer devices contained within the ensemble.
  5. (Optionally) One FuseUnit object class to represents the assets serving as protection devices. (NOTE: Many electric utilities do not currently model protection fuses in their GIS. this lack of information may require special attention if exporting the GIS network to a DMS.)
  6. (Optionally) One relationship class associating FuseUnit with TransformerBank to represents the protection to the ensemble.
  7. One SupportStructure feature class with a set of subtypes, and asset-like attributes to represent the location of the supporting pole and its asset properties.
  8. (Perhaps) One relationship class relating TransformerBank with SupportStructure when it is necessary to explicitly represent the "attachment" of the ensemble.

If modeling with the Utility Network, we have:

  1. One Device feature class with Transformer and Fuse ASSETGROUPs; each feature representing the actual assets at their individual locations!!!
  2. One Junction feature class with ASSETGROUP of Connector to establish topological connectivity among the assets, and with the electric line(s).
  3. Connectivity Association Rules to implement the topological connectivity. The actual transformer and fuse assets do participate in the flow of electricity, and the way they connect to other network elements can be explicitly modeled.
  4. (Optionally) One Assembly feature class with TransformerBank ASSETGROUP to contain the assets in the ensemble. No electric or snapping properties are needed in describing the bank.
  5. (Optionally) Containment Association Rules that allow the TransformerBank to contain the assets.
  6. One Structure Junction feature class with SupportStructure ASSETGROUP to represent the pole as a located asset.
  7. (Optionally) Attachment Association Rule to represent the attachment of the assets to the pole. If using the (optional) TransformerBank, then the assembly is attached to the pole; otherwise, individual assets could be attached to the structure, if needed.

This example shows that the Utility Network simplifies the model by minimizing the number of feature classes, and eliminating relationship classes all together. The relationships are established, instead, as Association Rules; which are implemented by a simpler and more efficient mechanism than the relations.

Also, it is noteworthy that the Utility Network features represent the assets themselves at their own particular location; instead of objects that need to be related to geometric features for participation in the network, as in the Geometric Network. And that Utility Network devices, and lines features represent assets themselves participating in the flow of the commodity, since it is the assets (in some cases with the help of Connectors) what interconnects throughout the network.

Finally, the TransformerBank is not a necessity in UN, but rather a convenience. Contrary to the Geometric Network, Utility Network Assemblies are "liberated" of their connectivity requirement, and concentrate on providing an embedded representation of the inner connected assets, as well as the medium to attach ensembles of assets to the Structure Network objects.

Author Information

  • Joaquin Madrid

    Joaquin Madrid

    Joaquin Madrid comes to SSP from having worked in the GIS and Smart Grid fields for the last 12 years, and specializes in Electric Utilities systems integration. In this role, Joaquin manages the technical direction during design and implementation of integration projects. Joaquin's execution of projects involving GIS, DMS, WMS, AMS, AMI, CIS, and OMS gives him a clear understanding of the role of GIS within the Electric Utility Enterprise Solution.

    See all items created by this author >

    Connect with me on:

  • Konstantin Korchakov

    Konstantin Korchakov

    Konstantin Korchakov works as a software consultant for a Utility & Telecommunications GIS consulting company SSP Innovations in Centennial, Colorado.  Konstantin has 5 years of experience, specializing in system and software design and support. Konstantin provided GIS services for utility companies at many stages of their needs, such as land management, field surveying, mapping and construction projects support.

    See all items created by this author >

    Connect with me on:

Add new comment