Utility Network Data Models are just a starting point

LarryYoung · ‎08-15-2018

Hi All,

We've been getting a lot of feedback and comments on the Esri data models for the utility network. There's even a discussion here in GeoNet asking questions about missing fields within the UPDM 2018 model.

I can't stress enough that the data models being released by Esri with the utility network (so far Electric, Gas, and Water models have been released) are meant to be starting points and not end all models. We fully expect and encourage business partners and end users to take our models and make changes based on the individual needs of the organization. We've gotten too many reports of users, distributors, and partners thinking they had to follow our data models to the letter and could not change them. This is not the case. The data models Esri puts out are meant to be modified and extended as needed. Feel free to add additional fields, subtypes, rules, etc. based on the needs of your organization. Going forward you will see data models released by our partners that take the original Esri produced models and extend them to meet the more advanced workflows the partner solution addresses.

Another area where you will see partner involvement is with data models that Esri does not plan on providing a starting point for. The core software has the ability to create data models from scratch and partners (as well as some end users) will take this capability to create models for things such as district heating, stream networks, rail, etc.

As you begin to look at, research, and perform proof of concept studies with the utility network, keep in mind that you can and should change the data models to meet your needs.

Thanks,

Larry Young

Esri Product Managemen

DavidHoy · ‎08-15-2018

Larry, thanks for this post, it will help reinforce the concept of using the baseline packages as starters.

One of the difficult parts in changing the models provided within the starters is where the need is to remove or rename AssetGroups/Subtypes. It is easy to add them.

The interrelationships with underlying association and attribute rules means that the ability to remove/rename a subtype is disabled once a UN has been created in the Enterprise GeoDB.

The path to achieve this is to do these schema changes in the fgdb within the package prior to staging/creating the UN in the Ent GeoDB (or adding a domain package).

The tricky part is that the person doing the configuration needs to also check if the AssetGroup being deleted/renamed is referenced in any of the association/attribute rules. To do this, the B_xxx tables within the fgdb need to be examined and manually edited to remove "orphans". Not the simplest task.

If this is not done, once the UN is created from the package, there will be inconsistencies - I do not not yet know how serious these consequences are. Are they detected and reported? Can these be repaired in the"built" UN?

SamiSnunu · ‎08-16-2018

I second your comment @David Hoy on:

The tricky part is that the person doing the configuration needs to also check if the AssetGroup being deleted/renamed is referenced in any of the association/attribute rules. To do this, the B_xxx tables within the fgdb need to be examined and manually edited to remove "orphans". Not the simplest task.
If this is not done, once the UN is created from the package, there will be inconsistencies - I do not not yet know how serious these consequences are. Are they detected and reported? Can these be repaired in the"built" UN?

This tricky part is actually time consuming task especially for fixing missing rules, and is not a simple task, once you Enable Network Topology, you'll see the surprises in the Point/Line/Polygon Errors added to the Map, open their attribute tables, prepare your coffee, and start digging into the crowd..The Rules tools available are Import Rules(into the UN), Export Rules, Add Rule, Delete Rule.

AnthonyRyanEQL · ‎08-16-2018

I third David Hoy's comments too

Also add, How do we bring in additional functionality from later releases of the base model (eg. when V3 or V4 of electrical distribution model brings function A, B , X & Z)?

I shouldn't have to go through the setup of base model X, go through the whole process of rename/remove/add fields, rules, etc. all over again, deploy to another Enterprise geodatabase, migrate data, reconfigure datasource & potentially republish services

LarryYoung · ‎08-17-2018

Thanks to all for the comments. No disagreement on the general sentiment. Making sure any changes you make (changing the name of an Asset Group/subtype, for instance) are rippled through all subnetwork definitions, rules, etc. is key. We continue to look at tools we may be able to add to help with this process. Hopefully more to come on that subject.

As far as updating a model after it has been loaded from an asset package, this can definitely be accomplished through the core tools. The help topic on configuring a utility network is a good place to start in locating and understanding the different geoprocessing tools that are available to update a model:

Configure a utility network—ArcGIS Pro | ArcGIS Desktop

Enguerranddes_Vaux1 · ‎08-19-2018

Hi Anthony,

to quote the documentation :

The Apply Asset Package applies the domain network(s), related layers, related tables, and properties of a utility network to an existing utility network dataset.
This tool is additive. When run against a configured utility network, only the additions will be applied. Existing properties are not removed or changed.

So if you apply the asset package v4 on a utility network configured with the asset package v3, only the new functionality will be add to your network, you don't need to redo everything

AnthonyRyanEQL · ‎08-20-2018

Enguerrand,

Thanks for the information. I didn't see that. We just have to be careful not to come up with field names & domain values that could be conceived by Esri in the future to ensure they can migrated across in any future updates we decide to implement.

I was hoping for some form of guidance documentation similar to GE's SmallWorld Electric Office datamodel where they mention any new fields should be prefixed and domains values start from a certain number (eg. starting from 1000).

RichardDumont · ‎08-21-2018

I totally agree with this. I always have to remember AssetTypes have to be unique per feature class, it would make sense to have "Customer" values start at 1000 or some value, we can do this ourselves of course but it would be good to know it is supported. Even IBM Maximo has customer codes/values for things to make sure things are not walked on, I remember making custom/customer error messaged that had to have a specific prefix and others. I would even suggest that anything not in the "template version you are working on" be prefixed.

We currently have a custom tool to build a DM spread sheet, easier to work with a customer in Excel. We keep track of all the changes. Own next step / plan is to develop something to process the B_ tables for discrepancies and track them. Good documentation is always helpful when things change later! And we all know they will.

VishApte · ‎01-10-2019

Adding on to David Hoy's comments, I am finding it is not trivial to simply rename existing asset group names, asset type names, domain names etc. We in Australia/NZ follow different naming conventions in Electric Dist and Transmission industry. Anything above 66kV is considered "Transmission" voltage, anything between 1kV and 66kV is called "High Voltage" and anything below is considered "Low Voltage" as opposed to North American terminology of High, Medium and Low voltages. Also, we use "Feeders" and "Sub feeders" and not "Circuits".

I am trying to reset Electric Distribution and Transmission Asset Package to ANZ standards and it has been a bit of work. I wonder if there is any way to do this quicker rather than going through every A_, B_ and C_ table and domains in the Asset Package.

Cheers,

Vish

PaulLeBlanc1 · ‎01-10-2019

Vish,

We are currently prototyping a global "Configuration" table in the asset package that would allow you to rename Asset Groups, Network Attributes, etc in 1 table. You'd make a few changes in this table and during application, the new names would be loaded.

For example:

Table	Item	Current Name	New Name
ElectricDevice	Subtype	High Voltage	Transmission
ElectricLine	Subtype	Circuit	Feeder