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.
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:
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:
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:
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.
The 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!