GIS in the Utility Network

Esri Utility Network – Reinventing Your GIS in the Utility Network

August 6, 2017 — Joaquin Madrid, Ph.D.

A Paradigm Shift with GIS in the Utility Network

Esri’s Utility Network represents a completely new paradigm in the modeling and implementation of your network-driven GIS. Abandoning Geometric Coincidence, GIS in the Utility Network embraces Topological Connectivity as the sole criterion to model interconnections among the equipment in your physical network, and between equipment and infrastructure. Furthermore, these topological relationships are implemented by the single, powerful concept of Associations. And because the Utility Network is implicitly embedded into the ArcGIS platform, your network maintains accurate geographic localization, and conveys information about the spatial distribution of your assets and their relationship with their surroundings.

As your company gears up to adopt the Utility Network, we recommend that you give your current GIS data a hard look. Take this opportunity to re-examine the role GIS plays within your organization at large, re-invent your GIS, and — why not? — re-invent yourself.

Re-Examine Integrations

In the past decade, we all have witnessed how software applications — supporting the different business units in your utility — have been integrating with each other to provide a common enterprise solution. Within this landscape, GIS continues to play a fundamental role as the system of record for the geographic distribution of your assets and their interconnections. Via integrations, GIS exposes the network to the other systems, each consuming the set of attributes relevant to its own functionality.

The variety of integrations in which your GIS participates has revealed its strengths, as well as its weaknesses. The role of your GIS in the Utility Network has been challenged, as the intrinsic functionality of the integrated systems surpasses the capabilities that you originally customized within your GIS. A few common examples follow:

  • Asset Management — Monitoring your equipment lifecycle, once a cumbersome task customized into your GIS, is handled in a more efficient and effective way by Asset Management.
  • Distribution Management — GIS delegates calculations based on the real-time state of the network to Distribution Management.
  • Outage Management — Blackouts, and the switching orders for service restoration, are best analyzed and executed via Outage Management.
  • Customer Information — Is there any longer a need to maintain consumer data in your GIS? Your customer information system not only takes care of billing; it also interacts with your work management system (WMS) to handle new services, the termination of existing services, etc.
  • Work Management — And when planning the design and execution of work orders… leave the job of estimation, cost reporting, and activity workflows to the Work Management.

Does this mean that GIS is losing relevance when compared to the other players in the utility? Not at all. GIS is, and will continue to be, the central focus of the company, as it tells you where your capital investment is located, in relation to its geographic surrounding. The challenge you face by integrating GIS with the other systems in your utility is to understand the true value — and the precise contribution of — the GIS to the overall Enterprise Solution.

Systems integration challenges you to re-examine your GIS. And what better opportunity for reviewing your GIS than when the GIS software itself is being re-invented?

Re-examining Data in the Utility Network

As indicated above, your GIS in the Utility Network will continue to be the central repository describing the geographic distribution of your assets, as well as their interconnectivity. Therefore, internally within your organization, you will continue to expose the network to enterprise and field applications. And via online technologies, you will continue (or “finally” start) sharing your network with third parties and your customers.

From this functional perspective, you will want to review the network in terms of its mapping capabilities, editing and validation, traceability, database maintenance, and other procedures. But, from the point of view of a System of Record… what should you do?

You need to decide what data you store in your network, and evaluate its relevance within the GIS, and among the integrating systems.

Preparing Data for the Utility Network

As explained in a previous blog, Esri’s new Utility Network gives you, the modeler, a simple and scalable model with which to implement any type of network commonly used by utilities.

The simplicity of the Utility Network model allows Esri to offer the same core functionality to any utility, whether electric, gas, water, sewer, or telecom. With seven configurable feature classes and a few internal-use classes, any utility can model the geographic distribution of their assets, their interconnections, and their relationships with the environment. As an example of this simplicity, the Utility Network offers a single Device Feature Class that, when properly configured, allows you to implement any device you need: an electric transformer, a gas pressure pump, a fire hydrant, a fiber optic splice point … you name them.

The seven feature classes are scalable, allowing you to organize your data with great detail. The Utility Network can model any type of asset via the ASSETGROUP and ASSETTYPE default attributes, as well as any number of custom attributes. Back to the example, let us say that your domain of operation is Electric Distribution. Then, with the Device Feature Class you can model transformers, switches, capacitors, etc., by configuring the ASSETGROUP. For a given group, say Fuse, the ASSETTYPE allows you to differentiate between current limiting, expulsion, and others. And, with the custom attributes of your choice you may add any level of detail to your features.

In essence, GIS in the Utility Network offers a very versatile model that gives you absolute control on how to implement your network. Then, the next question is, how should you organize your data within the Utility Network?

Verbatim Migration

If your utility already relies on Esri’s ArcGIS 10.2, you may decide to migrate your data from Geometric Network to Utility Network verbatim; i.e., you would do this in a way that the migrated data looks very much like the original one. And you could do this in the manner explained below.

However, please be aware that neither Esri nor SSP recommend that you migrate your data in this “one-to-one” fashion. Instead, when ready to migrate to the Utility Network we will assist you in the process:

  • identifying attributes of interest,
  • establishing association among features, and
  • setting validation rules to ensure data integrity, etc.

Skye has already discussed many of these details. Also, SSP has already implemented migration algorithms that result in a robust topological network that can take advantage of the full capabilities of your GIS in the Utility Network. The resulting network resembles your current Geometric Network model, but surpasses it in many ways; particularly representing a more realistic way in which your assets are interrelated.

Nevertheless, understanding the simplistic way in which to achieve verbatim migration will help you become better familiarized with the way data is organized within the Utility Network, by drawing some parallelism. So… Let us illustrate this migration method.

Verbatim Migration – Details

You start by mapping infrastructure feature classes and objects to the Structure Network, while equipment maps to one or many Domain Networks. You would then map your current classes to the ASSETGROUP, and their subtypes to ASSETTYPE domains. Finally, you may bring all the remaining attributes of each Class (Feature or Object) as custom attributes of the corresponding Utility Network Feature Classes.

As an example, let us suppose that your current GIS implements the ArcGIS Electric Utility Physical Model. In particular, your devices are organized as shown in the diagram below:

UNEA - EA Reinventing GIS - All Device UML Diagram - GIS in the Utility Network

As you migrate your data to the Utility Network you could map all your classes that derive from ElectricDevice into ASSETGROUP values of the Device Feature Class of a Domain Network. In other words, you would create a coded value domain, say ElectricDevice, with the following configuration:

UNEA - EA Reinventing GIS - All Device ASSETGROUP Domain - GIS in the Utility Network

And assign the domain to the ASSETGROUP attribute. This way, all your switches (for example) will be imported as Device features with ASSETGROUP set to 4.

For further granularity, you already differentiate devices from a given feature class using subtypes. Back to the ArcGIS Model, the diagram below shows how the Switch Feature Class differentiates among four subtypes.

UNEA - EA Reinventing GIS - Switch UML Diagram - GIS in the Utility Network

Thus, you would create another coded value domain, say SwitchType, with the configuration:

UNEA - EA Reinventing GIS - All Device ASSETTYPE Domain - GIS in the Utility Network

And assign the domain to the ASSETTYPE of the Switch ASSETGROUP. This way, all your current Overhead Load Break switches will be mapped to Device features with ASSETGROUP = 4, and ASSETTYPE = 1.

And… what about the rest of the properties of your individual switch assets; some of which may be stored in related SwitchUnit objects? No problem. You extend the Device Feature Class with as many custom attributes as you want to bring with you from your current GIS implementation. In the ArcGIS Model example, particularly with respect to switches, you end up extending the Device Feature Class with attributes such as:

  • OperatingVoltage – from ElectricDevice Abstract Class
  • NominalVoltage – from ElectricDevice Abstract Class
  • PhaseDesignation – from ElectricDevice Abstract Class
  • ConstructionStatus – from ElectricDevice Abstract Class
  • WorkOrderID – from ElectricDevice Abstract Class
  • InstallationDate – from ElectricDevice Abstract Class
  • Comments – from ElectricDevice Abstract Class
  • GangOperated – from Switch Feature Class
  • ManuallyOperated – from Switch Feature Class
  • MaxContinuousCurrent – from Switch Feature Class
  • MaxOperatingVoltage – from Switch Feature Class
  • NormalPosition_[A,B,C] – from Switch Feature Class
  • PresentPosition_[A,B,C] – from Switch Feature Class
  • TieSwitchIndicator – from Switch Feature Class
  • SCADAControlID – from Switch Feature Class
  • SCADAMonitorID – from Switch Feature Class
  • PreferredCircuitSource – from Switch Feature Class
  • LableText – from Switch Feature Class
  • SupportStructureObjectID – from Switch Feature Class
  • HFrameObjectID – from Switch Feature Class
  • SwitchingFacilityObjectID – from Switch Feature Class
  • UndergroundStructureObjectID – from Switch Feature Class
  • Manufacturer – from SwitchUnit Object Class
  • SerialNumber – from SwitchUnit Object Class

Yes, migrating to the Utility Network is a breeze, because the Utility Network has been designed simple and scalable, with a high degree of versatility.

Yet, and as indicated at the beginning of this section, you should not aim at migrating your data in this simplistic way, but rather in a manner that takes advantage and exploits all of the new Utility Network capabilities. Verbatim migration is just a simple exercise to show you the versatility of the new model; hoping to reduce any anxiety associated to adopting the Utility Network.


Esri’s technology is shifting paradigms by replacing the Geometric Network with the Utility Network. During this time of change, we encourage you to re-examine the role that your GIS plays within your enterprise solution; particularly as a system of record being integrated with other systems.

Much of the value of your GIS resides on the data that it contains. As you contemplate the task of upgrading from Geometric Network to Utility Network, we show you that the difficulty is not in the migration of your current data. The challenge you face is to find a satisfactory answer to the question “what data is actually meaningful in my GIS, as a system of record integrated within the enterprise solution?”

At a minimum, and only for illustrative purposes, the simplicity, scalability and versatility of the Utility Network model allows you to implement what I call a verbatim migration: your data will look fairly the same in Utility Network as it did in Geometric Network. But … do you really need all the data you currently support in your GIS? Why would you want to make the new model simply reflect the old one? Wouldn’t you rather modify the model so that it takes advantage of the new capabilities of the Utility Network? Shouldn’t we all, instead, revise what your GIS offers and what is missing in it, and redefine the way your network is implemented?

SSP will help you go through this introspective examination, and together we will reinvent your GIS, so that it remains strongly positioned at the heart of your Enterprise.

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

Joaquin Madrid, Ph.D.

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, Read more


  • Joaquin,
    Great explanation of mapping the current data to UN and good food for thought in taking the time to design for the future. I had one question. In the current models (multispeak), there are banks (feature classes) and units (object classes). For example, an overhead transformer bank can have three separate units (cans) hanging on the pole.

    Under the UN, would you recommend:
    A. 4 records – 1 with an asset group TransformerBank and 3 with an asset group TransformerUnit
    B. 3 records – 3 with and asset group of Transformer and extra fields that tie all 3 together such as Transformer Location Number

    We currently have transformers numbered by location and then the units will have physical serial numbers. I am also thinking in regard to MultiSpeak and how Engineering Analysis packages would need to see the data.


    • Joaquin Madrid says:

      Dear Duane,

      Glad you found the article of interest. This would be our recommendation:

      (But, first, keep in mind that we do not recommend verbatim migration. And second, the recommendation below is valid, and independent of the trivial migration.)

      1. Add one coded-value domain, say Banks, with at least the TransformerBank entry. (You may want to add to it CapacitorBank, SwitchBank, etc.)

      2. Another domain, Units, would have Transformer (or TransformerUnit, if you rather stick with the legacy nomenclature); as well as Capacitor, Switch, etc…

      3. Assign the Bank domain to the ASSETGROUP of your ASSEMBLY feature class. and the Units to your DEVICE feature class.

      4. Additionally, you may want to create a domain to differentiate among specific transformer banks (another for alternative capacitor banks, etc), and another one for different types transformer unit (also for capacitor units, etc). These domains would be available for assignment of ASSETTYPE.

      Now then… When building your transformer substation, you add

      1. A feature from your ASSEMBLY feature class, with ASSETGROUP TransformerBank; and optionally of the Overhead ASSETTYPE.

      2. Three features from your DEVICE feature class, with ASSETGROUP Transformer[Unit]; and optionally of the 15KVA ASSETTYPE.

      3. Using Connectivity Association you “hook up the wires” to the DEVICEs.

      4. Using Containment Association you “place” your DEVICEs “within” your bank.

      I hope this answers your question satisfactorily. I have discussed a similar example in an Appendix to a previous blog article, which may further clarify these concepts.

      Please, let us know what you think about this solution, and whether you would like further discussions on these, or any other topics.

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>