Esri Utility Network - Data Model 101

As detailed by Ryan Potts last month, the Esri Utility Network was one of the hottest topics at the Esri UC this year. We've been participating in the Alpha program for this new and exciting product and while we can't disclose any details about the software (the Beta will be out for customers late this year), we have been cleared to start educating our customers on the data model.

Understanding the data model will be foundational in beginning to use the new software (at Beta or beyond) and in understanding how your current geometric networks will eventually be migrated into the utility network. To guide you through this important topic, this will be the first installment in a new series detailing all the key areas of the utility network data model. Please feel free to ask questions via the comments or via contacting us directly. If you stick with us through this series, you should have the required skills to understand the utility network as soon as it's released into Beta.

In this post, I'll start with an overview of domain networks within the new data model.

The above diagram is one you will want to get familiar with as it contains all the key terms we will use to discuss the utility network. First off, recognize that the new network still runs in an Esri geodatabase and is still made up of feature classes. However, this is also the first area of significant difference. Whereas the geometric networks we utilize for electric, gas, and water all contain different feature classes (i.e. pole vs. conductor vs. switch), the utility network will contain a distinct set of feature classes for each domain where the domains are defined as electric, gas, water, etc. Electric could also be broken down further into a distribution electric domain network and transmission electric domain network or they could be modeled as different tiers within the same domain network (stay tuned, tiers will be covered next month). Don't confuse the utility network domain networks with field domains which are our traditional field picklists in the GDB.

These distinct feature classes include the Device, Line, Junction, Assembly, and SubnetLine. If you manage more than one network in your geodatabase today, you will actually create multiple different domain networks within the same utility network. For example, our good friends over at Memphis Light Gas & Water will end up having at least three domain networks - electric, gas, and water - created within their single utility network. Two key benefits to this approach are that you will be able to enable tracing across different domain networks (ex. electricity feeding a water pump) AND that multiple domain networks will share a single structure network (covered in more detail next month).

To hammer the domain network concept home, if I create a gas domain network named "GasNet" then I will end up with five feature classes including:

• GasNetAssembly
• GasNetDevice
• GasNetJunction
• GasNetLine
• GasNetSubnetLine

So where will all of your feature classes from your geometric network go?

Generally speaking they will be mapped into a combination of the Assembly, Device, Junction, and Line feature classes. Each of these feature classes is then further subdivided by two key fields: AssetGroup andAssetType. The AssetGroup utilizes the Esri subtype behind the scenes and will generally be used to map your current geometric network feature classes. For example the SwitchBank and TransformerBank point feature classes in the geometric network today will both be mapped into the Assembly feature class and will have their AssetGroup (subtype) set to SwitchBank and TransformerBank respectively.

The next question is where all of your current geometric network subtypes go now that subtype is being used to track the AssetGroup. The answer is that you will now define these as AssetTypes. So my TransformerBank AssetGroup will be further broken down into AssetTypes of SinglePhaseOH, SinglePhaseUG, ThreePhaseOH, ThreePhaseUG, and so on. My WaterMain AssetGroup may be broken down into AssetTypes by material such as BareSteel, CastIron, Plastic, etc.

The next question you are likely to ask is why are all of these geometric network feature classes being consolidated into a single utility network feature class?

There are a couple of key reasons. First, by tightly controlling the list of feature classes that participate in the utility network, Esri can optimize the way that the logical network (the network topology) is created and cached. This speeds up network operations and provides for consistency at the macro level for different customers and different domain networks. And second, the visualization of the network will benefit because there will be less calls to the database (i.e. by condensing multiple tables into four tables, we need less distinct queries executing against the geodatabase to render the feature data).

This design does have some important implications for you to understand. You will not be able to add additional feature classes to the network. You will, however, be able to add additional AssetGroups and AssetTypes to the existing feature classes within the network allowing you to map your existing classes into the utility network. It will be the same data just organized slightly differently. Further you will be able to create individual feature (map) layers within your map document for each AssetGroup (i.e. individual layers for transformer vs. switch, etc.) just as you do now. So the end result is pretty close to how you view your geometric network today.

To start thinking about your model, here are some guidelines around moving to utility network (UN) from your geometric network (GN):

Line

Description: Contains all linear elements of the network regardless of type, size, etc.

Migration Thoughts: You will map all of your simple and complex edges from the GN into this class and will subdivide them by AssetGroup and AssetType. Therefore both services and mains will be mapped to Line in gas/water and both primary and secondary will be mapped to Line in electric.

Assembly

Description: Generally used for container/aggregation features that represent multiple devices/assets at a single location (ex. TransformerBank may represent 3 transformer devices or a RegulatorStation may represent multiple regulators).

Migration Thoughts: You have the option to map your bank classes from the GN into this feature class. If no bank is present in the GN, then the source GN point class will likely be mapped directly to the Devicefeature class and not the Assembly. Assemblies in the UN will not be connected directly to lines but will contain other Devices that ARE connected to lines. Please note that this is not necessarily our final recommendation as we are still reviewing different migration patterns for banked GN features but will give you some thoughts on how it could work.

Device

Description: Will be used to model the devices that maintain connectivity to the lines in the network. There are different modeling options within the UN for the Device class. It could be mapped to the GN bank features and you could continue to model the individual devices as related (non-spatial) units but the general recommended approach is to move the units into this class so that distinct connectivity can be modeled to each individual device. 

Migration Thoughts: For water and gas this will often be mapped directly to the point features within the GN except in the case of reg stations or other devices where related unit/asset records could be promoted to device features. For electric, your unit records should most likely be promoted to features within this feature class associated with the bank feature that is migrated into the Assembly class. We'll talk more about how we'll achieve this concept of promotion in future posts.

Junction

Description: This class is used for more generic point-based connectivity. It will always include a ConnectionPoint AssetGroup but should also contain other non-device points where connectivity needs to be established.

Migration Thoughts: In electric you will likely map any joints, splices, dead ends, or open points (non-switches) to this class. For gas and water, you will use this for non-operable connection points such as couplings, elbows, caps, tee's, etc. (think of GN non-controllable fittings).

SubnetLine

Description: This class will be used to model a single linear feature per each sub-network in the future UN. For electric this will generally be circuits (at various voltage levels) and for water and gas this will be pressure systems, isolation zones, etc. These will be derived line features from the UN and not something you will migrate into. To be extra clear, this class will be completely system maintained. Users will never edit this data. The features in this class will be solely maintained by the application.

----

To wrap up this month's post, I am hopeful that this information gets you to start thinking about the utility network and how your data will be mapped into it in the future. We will continue to review each area of the network in the coming months with the goal of giving you all the intel you will need to jump right in when time comes. Once again, if you have thoughts or questions, fire away!