You are here

Esri Utility Network -
Modeling Device Terminals

You may have noticed that we are increasing the frequency of our Esri Utility Network blog posts. This isn't an accident! After talking internally, we want to continue pushing out this critical content for you in advance of the beta release of the software. There are many topics to cover and we hope to hit them all in the coming weeks/months via shorter, targeted posts.

I'll start with my standard disclaimer. If you haven't read the first two posts in this series, please start there as this post will build upon that knowledge:

This month we are going to tackle a new area within the data model specific to our domain network devices called terminals.

Esri Utility Network Data Model

A terminal is defined as a logical connection point on a network device and the goal of using terminals is to allow for more realistic modeling of real world devices within the GIS. Currently in the geometric network (GN), our devices are all modeled as simple junction features. This implies a few things. First off any device is shown on the map at a single point location. And any attached lines (conductors, gas mains, etc.) are then placed geographically coincident to the point feature. Consider this very basic electric example:

Geometric Network Electric Example

Here we have a single transformer bank connected to the primary conductor (red line) as well as connected to three secondary conductors (blue lines). The transformer bank is geographically coincident with the primary line. It may or may not break the line - if it does not break the line it acts as a network vertex on the complex edge that is the primary conductor feature. The transformer bank is also geographically coincident with the secondary conductor line end points. This allows for us to model the flow of power from the primary, down through the transformer bank and into the secondary conductors.

We inherently understand that the flow of power goes through the transformer and that the secondary conductor, primary conductor, and transformer are not all directly spliced together even though it is modeled with all of that connectivity occurring at a single geographic location. BUT this doesn't quite model the real world where the high side bushing on the transformer is tapped off of the primary and the secondary is then connected to the low side via the secondary terminals:

Transformer Components

The utility network will now allow us to model those individual connections to the transformer via terminals. Terminals effectively allow for a device to be mapped to a collection of nodes and edges within the network topology (discussed further in a future post). In our example, the high side terminal would be connected to the low side terminal via the internal workings of the transformer. The terminals are not drawn explicitly on the map but will be managed via the utility network software in ArcGIS Pro.

It is, however, helpful to imagine the terminals as being drawn on the map to understand how they will work. If you remember the discussion around the domain network devices and assemblies from our first post, we talked about moving the related assets/unit object records in the GN to become device features in the utility network. If we combine that with the concept of terminals in our above GN example, we would promote three overhead transformer units (A, B, and C phases) to become devices and they would all model both high side and low side terminals, shown as the black dots in this mock up:

Utility Network Electric Example

Each secondary line would connect to the appropriate low side terminal on each transformer device. And each high side bushing/terminal would then connect to the tap location which is modeled as a network junction on the primary line. You will quickly note that there is no line connecting the high side terminal to the tap junction. And that leads us to talking about the third type of utility network association. As a reminder we talked about the first two types - containment associations and structural attachment associations - in the last post related to the structure network

Connectivity AssociationsThe third type of association is called a Connectivity Association and it is used to establish point to point connectivity without geometric coincidence. We can't cover the exact utility network tools that will manage connectivity associations just yet so instead we'll focus on the data model side of the discussion. A connectivity association effectively ties points together and when used in conjunction with terminals, we can specify the exact terminal that is being connected. Therefore to model the real world in our above example, we would add connectivity associations (shown as gray dotted lines) between the tap junction on the primary conductor and the high side terminals on our transformers. This then very accurately matches the real world. You could alternatively model the connectivity between the transformers and the tap with a network line feature (perhaps a "connector" asset group/type) if you wanted to see the lines on the map permanently but the lines are no longer required like they are in the GN today.

By design, this is a simplistic example. The cool part about terminals and connectivity associations is that they will allow you to model many more complex devices and or multiple device configurations in the utility network. Our example showed two terminals but you will be able to model as many terminals as desired per device type (asset group/asset type). For other examples, think of the variations on transformer configurations (multiple high side bushings, differing configurations of fuses and transformers, etc.), circuit breakers (source and load terminals), complex switches (bypass, tri-state, and t-blade switches), gas regulator stations (inlet and outlet connections), and many more uses. We will shoot to provide more detail on these options in the utility network in a future post.

There are a few other notes on terminals to be aware of. First off, know that some devices will be modeled with terminals but many may not utilize terminals at all. Terminals are NOT required. Terminals will add value when modeling devices that require this level of detail for analytic purposes and/or for devices where traversal is asymmetric (only goes one direction) such as a network protector or a check valve. So plan on using them in your model where they make sense. One other note is that network junctions do NOT support terminals. They will only exist on your network devices features based on configuration applied at the asset group/asset type level. Most importantly, know that the new utility network supports this level of modeling for your current or future analytic needs! And don't forget that there may be future analytic needs that will arise in the next 15 years that we can't even imagine today. The utility network will be prepared.


This concludes part three of the utility network series. We covered terminals and the basics of connectivity associations (more to come on this topic). Please ask questions if you have them and shoot us your comments. We are excited to see the significant readership level on this topic!

Author Information

  • Skye Perry

    Skye Perry

    Skye Perry is a Principal Consultant for SSP Innovations and has provided technical architecture, development, and management solutions for GIS-centered implementations since 2000. Skye's roots tie back to Convergent Group, Miner & Miner, and Enspiria Solutions where he has focused on implementing Esri GIS customizations and system integrations. Today Skye is still involved on a number of SSP's project implementations and supports technical marketing in addition to leading the company.

    See all items created by this author >

    Connect with me on:


Using the device/terminal concept is it possible to model 1N bank of customers without maintaining a intermediate related table of customers? In the current GN we model a bank of meters (ie at a apartment building) as one service point. Then we have a intermediate related table with the service point OID and customer account number; having one row for each physical meter at the meter bank. Then we have another table relating the customer account number to the customer information table.

I am wondering if the new Utility Network will allow me to forgoe the intermediary table by using the device/terminal concept and relate directly from the meter bank to the customer information table.

Darris, the intent of the terminals is not really to be used for multi service point dwellings. They are more for modeling devices where you need to manage a high and low side as well as internal connectivity. Another idea for your situation would be to use structures and containers.

What if you modeled a structure as a service location (could be a point or a polygons structure) and set that to contain each meter. You would end up having an individual meter feature per each meter in the field but you could set them to not be displayed on the map per a containment attribute (effectively stating that only the service location structure should be shown on the map by default). Then you could still model connectivity from the end point of your secondary to each individual meter by opening the container view of the service location and creating connectivity associations.

This would ideally give you the best of both worlds. Only seeing a single point, the service location, on the map for general mapping but able to open the service location to manage and view connectivity to the individual meters present at the location.

This is very cool, typically we have had to put connector lines in which don't exist in real life. Or we had to assemble/disassemble trans banks as the individual cans go in or out of being in a given bank. Also, digital inspection regiments in GIS become hard for non-GIS people when many inspections records are related to many cans within a single bank.
I'll tell you what worries me though, we implemented ArcFM sewer, water distribution and electric distribution models in 2000, we've also build a lot of tools over 16 years to interact with those models - none of which will work with this model structure. Also, the notion of converting all this data and their connectivity rules into the new model is - stressful to say the least.
I see the power of the new model, I don't know if I see a feasible path in terms of costs.

You are right - there are some challenges ahead. But it should all be put in the context of the ROI associated with the future UN-based GIS. This will be the network for the next 20 years and will provide many new advancements over that timeframe around integrations with ADMS and many other partner based tools. The idea is to have the UN at the center and to be able to implement various (multiple) partner solutions around the UN. The end game should deliver the ROI you'll need to make the shift.

Add new comment