The Utility Network is the on the horizon. Duane Holt from Intermountain Rural Electric Association (IREA) has had a chance to use the beta of the Utility Network. He will share his experience and give his positives and negatives of this new technology. John Coleman from SSP Innovations, an Esri partner, will demonstrate the tools they have been building to answer the questions and concerns IREA and other utilities have about the Utility Network. This will include a few demonstrations covering each of the topics that IREA experienced during the Utility Network jumpstart.
2. Introductions
Duane Holt | Intermountain Rural Electric Association
• GIS Director
– 23 years with IREA
– 30 years mapping utilities
– MSGIS – University of Denver 2010
– GISP for the last 7 years
• First Utility Network Jumpstart User
John Coleman| SSP Innovations
• Software Consultant
– 4 years developing on ArcGIS platform
3. Intermountain REA
Electric Coop serving Central Colorado
152,595 Meters
9,750 mi. Dist.
5,000 sq. mi.
Urban – Rural
Mtns – Plains
4. Current Status
AMI vendor selection (and 1 yr. rollout)
CIS upgrades / enhancements (mobile)
Pole and Joint Use inventory reconcile
Data Reviewer
Portal
6. Current Status
ArcGIS Enterprise (Portal for ArcGIS)
System Architecture
Business Architecture
Solution Architecture
Data Architecture
Security
Applications
Network Infrastructure (AWS Cloud)
Oracle vs. SQL Server
7. Future steps
Beta
Manually redraw a few feeders
Further functionality testing
Conversion Strategy
Integration design
OMS
CIS / Asset Management
Milsoft
10. Data Migration Planning
TransformerBank – OH (ABC 46397)
TransformerUnit – A GE_1234
TransformerUnit – B GE_5678
TransformerUnit – C CO_934
Feature Class Point - Subtype
Object Class Record
Object Class Record
Object Class Record
11. Data Migration Planning
DEVICE (Electric Domain; Distribution Tier; FDR2037 Subnetwork)
ASSET GROUP
ASSET
TYPE BANK_ID SERIAL_NO PHASE KVA - - -
Transformer Bank Overhead 46397 ABC 75 - - -
Transformer Overhead 46397 GE_1234 A 25 - - -
Transformer Overhead 46397 GE_5678 B 25 - - -
Transformer Overhead 46397 CO_7JX8 C 25 - - -
Same Transformer in the Utility Network
12. Data Migration Planning
DEVICE (Electric Domain; Distribution Tier; FDR2037 Subnetwork)
ASSET GROUP
ASSET
TYPE BANK_ID SERIAL_NO PHASE KVA - - -
Transformer Bank Overhead 46397 ABC 75 - - -
Transformer Overhead 46397 GE_1234 A 25 - - -
Transformer Overhead 46397 GE_5678 B 25 - - -
Transformer Overhead 46397 CO_7JX8 C 25 - - -
Transformer - Device
LINE (Electric Domain; Distribution Tier; FDR2037 Subnetwork)
ASSET GROUP
ASSET
TYPE SIZE MATERIAL PHASE LENGTH - - -
Neutral Overhead 4/0 ACSR 228 - - -
Primary Overhead 477 ACSR A 228 - - -
Primary Overhead 477 ACSR B 228 - - -
Primary Overhead 477 ACSR C 228 - - -
OH Conductor - Line
13. Data Migration Planning
Field counts – at least 215 fields
Record counts:
Devices – 994,354
Lines – 1,113,309
Structure Network – 565,421
Remember:
Fewer tables, relates, and joins
Versioning directly in the tables
14. Utility Network - Likes
The ease of inter-relating multiple voltage levels –
Tiers
Structures are network aware
Combination of geo-coincident and associated
connectivity
Not having to rebuild network for schema changes
15. Utility Network - Concerns
Creating features is tedious
Lack of visual connectivity for associations
Tracing is very click intensive
16. Answering the concerns
Focus on the user
• All-in-one toolbar
Increase productivity
• 'One-click Trace' tools
• 'Association Tools' that allow visualizing and managing
associations
Intermountain REA is an Electric Coop serving central Colorado. We serve 152,000 meters from Urban to Rural and Mountains to Plains, basically all types of geography in our system.
The current projects the GIS department is working on include our AMI vendor selection and fast paced rollout, CIS upgrades including the addition of a Mobile Work Force system, and Reconciling Pole and Joint use inventory of 3 separate projects and 4 different sources of data. Specific to the Utility Network, we are working on implementing Data Reviewer and Portal.
Data Reviewer, we are building up the rules and cleaning up the reported errors for things like Orphaned relationships, Geometry errors, proper subtypes and general attribute values. We are trying to build a clean consistent base of data to start our migration from.
ArcGIS Portal is required for the Utility Network. We don’t have that in place right now. Next week we will be sitting down with Esri to go over all the architecture required to implement ArcGIS Enterprise. This will be looked at as if it is a new GIS implementation. It’s our opportunity to build the GIS to fit the future needs of the company as well as the future requirements of technology. This rollout should be completed this fall. Some of the more technical decisions we will be making will be in regard to security and firewall protocols, GIS served from AWS, and whether we stick with Oracle or migrate to SQL Server.
As we complete what we are currently working on, we will move toward other steps to prepare for the ne GIS and Utility Network. We will get Beta loaded up again and will begin very thorough testing. We have committed to Esri that we will perform thorough testing and provide frequent scheduled feedback. I have one person who will spend most of her time learning, testing, and becoming IREA’s Utility Network expert. We will draw feeders from scratch as if we didn’t have any data in GIS yet and we will convert a few feeders form the current network, all in an attempt to understand how we want to model our networks in the future. We will spend a lot of time designing and testing integrations and working with those vendors to help them know how we need to integrate the new models.
In addition to gaining that expertise with the Utility Network, we will also be developing the rest of the IREA staff in preparation for the new GIS methodologies. Training GIS staff on Pro and publishing, training business users on Portal and AGOL, and generally getting our hands on the new ways of do the same job they do today with those new methodologies. IREA uses Schneider Electric’s Designer software. We know that in it’s current form, Designer will not be available to the Utility Network. So we are looking at that change on the horizon as well. As expected, there are many options that are starting to appear. The GIS department will assist the Design group in evaluating these options and finding the product with the best value and business fit for IREA.
At IREA, we have spent a little bit of time understanding how our data will migrate. We currently use the MultiSpeak model and we have stuck pretty close to this standard over the years. If you recall, this model has different feature classes for each device and line type location which is then broken down into multiple subtype and includes relationships for the individual components at that location, Banks vs. Units.
That results in a data tree of a Feature Class with related Object Class records underneath. In the case of an OH transformer, we have a bank numbered 46397 and related to that we have 3 object class records that have manufacturer and serial number. 4 records, 2 tables (not counting the A & D tables for editing and you can only symbolize on the 1 feature class record.
The same transformer in the Utility Network would look like this. Under one device table in the Distribution Tier and Feeder 2037 subnetwork you would have two asset groups, Banks and individual transformers. They would be related data wise with an field we add for Bank_ID. In the network they are related with a containment association. We would still have 4 records but all in one table and much easier to symbolize on the units. No more relationship classes or complicated joins to work with this data.
Lines would be similar. What may be concerning about this is the number of fields that would be needed to accommodate all the data for all the device types you currently have and then the fact that all devices would be in the same table. I think of this format similar to data warehousing. We are transforming from GIS data collection and editing to GIS data dissemination and analysis, moving from a write intensive system to a read intensive system. This flatter table format is quicker at reading because there are fewer joins.
For IREA, our current network devices would migrate to 215 fields in the new Utility Network table. Our record counts in the Devices table would be a million records while our lines table would have 1.1 million records and our structure network would result in a half million records. While those numbers sound large, they are actually quite manageable when there are no joins or relates to worry about. I will note though, these table will grow fairly quickly because versioning will also be stored in these same tables. But this is only a concern for physical storage space as the queries won’t slow down.
Want to make it easier on the easier.
Not as many context sensitive items.
Containment view
3-phase secondary tapped off of 3-phase primary
For each phase: arrestors -> fuse -> transformer