Electric Networks - Basic Configuration
Update: Comments are now locked on this thread. If you have questions, please ask in them in the ArcGIS Utility Network Questions community.
If you’ve used the Migrate To Utility Network tool to migrate your electric data into a utility network, you’re likely asking yourself “what configuration do I need to perform on this utility network to make it behave like an electric distribution network?”
These networks model the path that electricity takes from a medium voltage circuit breaker located in a substation to the low voltage customers in the network. Analysis workflows for these datasets range from looking at the load on the circuit breaker or transformer, to ensuring protective equipment is properly sized to handle potential faults in the system.
In this article we will show you how you can take a model produced using the Migration toolset and extend it to support some of these basic workflows.
Note: Before making configuration changes to your network, you should ensure you have addressed all topology errors discovered because you cannot trace in areas of your network that contain errors. Fixing topology errors after you’ve enabled your network topology or deployed your utility network will limit your ability to use tools like Apply Error Resolutions to automatically correct errors.
Connectivity Tracing
The first, and most basic kind of trace in the utility network is a connected trace. To perform a connected trace, you add a starting point on a network feature to the map, then run a connected trace. This style of trace will return all the features that are traversable from the given location based on the configuration provided for the trace. A connected trace without any additional configuration is likely to return your entire dataset, as you can see below.
While this is a convenient test to identify disconnected features, a more realistic trace would consider a device’s status (open/closed), electrical phasing, and whether a feature is in service or proposed. This can be simulated by manually adding barriers to your trace to represent these conditions, however, the recommended way to do this is to define condition barriers for your trace.
If you use the Migrate To Utility Network to create your network, you will see that every feature has an enabled field. If you migrated data from a geometric network this field is populated with a value indicating whether it should act as a barrier. In the example below we perform a trace using data from a geometric network and treat all the disabled features (open devices) as barriers.
You can see that unlike the initial trace, this trace returns all the features that are electrically connected to the feature associated with the starting point. Evaluating these condition barriers during a trace allows us to discover the extent of the circuit from the starting location.
While it’s perfectly acceptable to use the enabled field as a condition barrier, you may not be used to maintaining an enabled field and want to use a different field to maintain your switchable device status. This is discussed in the next section.
Device Status
To include attributes from your features in tracing or analysis, create a network attribute so the utility network can reference them. Let’s walk through an example of creating a Device Status network attribute that can be used to manage tracing.
The first step is to identify the field from our data that we want to use. In this case we will be using the NormalOperatingStatus field in our device class. This is a short integer field with a domain assigned to it that indicates whether the device is open (1) or closed (0).
Now that we’ve identified the field, data type, and domain we want to use, we can create the network attribute. First, we add a network attribute to the utility network that matches the data type of our field. Because this field will be used in almost all of our traces, we want to store it in-line, so it performs better
Read the online help topic on network attributes for more information about their use and effect on the behavior of your utility network.
Once the network attribute has been added to the utility network, the next step is to select which fields to associate with the attribute. We aren’t required to associate a network attribute with each class in our network, but each network attribute can only be associated with a single field from each class. If we have multiple status fields, we can only select a single field to associate with this network attribute.
Once we’ve associated this field with our network attribute, we can then use it to define a condition barrier for our traces.
Any time a user modifies a field associated with a network attribute the feature will generate a dirty area that must be validated to update the network with the new value. We can see an example of this below where we are tracing through a closed fuse (1) and after setting the device status of the fuse to open and after validating the edit the trace then stops at the newly opened fuse (2).
This strategy works well when you have a single status field, but what about when you maintain a different status field for each phase? We will discuss this in our next section.
Multiple Status Fields
In the previous section you saw how you can use a single field to model the open/closed position of a device. However, if you have fields that allow each phase of a device to have a separate status, you will need to consider one of several solutions.
It is common for electrical models to use three separate fields to manage the open/closed status of a device. Each of these fields corresponds to a different phase of electricity (A, B, or C), and this model allows the network to model the status of each phase of a device separately.
When using the Migrate To Utility Network tool, a device must be treated as gang operated. This means that the device is either considered to be open or closed, it cannot have a mixed status. If you need the ability to model devices with a mixed status you will either need to model them as separate devices or you will need to migrate your data into the Electric Utility Network Foundation.
There are several ways to make this work using the Migrate To Utility Network tool. The easiest way is to continue using the enabled field (or create a single device status field) to control tracing and populate this field using your existing status values. To do this you need to know a few things:
- What fields do you use to represent the status of each phase of a device?
- What values represent open and closed?
- What field do you use to represent the phasing of a device in your network?
- What values in the phase field are applicable to each status field?
Using this information, you can use the Select By Attributes tool to identify all the equipment that should be open or closed.
Let’s look at an example of this below.
- What fields do you use to represent the status of each phase of a device?
Status
Field Name
A Phase Status
POSA
B Phase Status
POSB
C Phase Status
POSC
- What values represent open and closed?
Status
Value
Open
0
Closed
1
- What field do you use to represent the phasing of a device in your network?
PhasingCode
- What values in the phase field are applicable to each status field?
Phase
Value
A
4
B
2
C
1
AB
6
AC
5
BC
3
ABC
7
With this information we can write three queries:
Query
Expression
Devices that should be Open (Enabled=False)
ENABLED=1 AND
(((POSA=0 AND PHASINGCODE=4)
OR (POSB=0 AND PHASINGCODE=2)
OR (POSC=0 AND PHASINGCODE=1))
OR
(((POSA=0 OR POSB=0) AND PHASINGCODE=6)
OR ((POSA=0 OR POSC=0) AND PHASINGCODE=5)
OR ((POSB=0 OR POSC=0) AND PHASINGCODE=3))
OR
((POSA=0 OR POSB=0 OR POSC=0) AND PHASINGCODE=7))
Devices that should be Closed (Enabled=True)
ENABLED=0 AND
(((POSA=1 AND PHASINGCODE=4)
OR (POSB=1 AND PHASINGCODE=2)
OR (POSC=1 AND PHASINGCODE=1))
OR
(((POSA=1 OR POSB=1) AND PHASINGCODE=6)
OR ((POSA=1 OR POSC=1) AND PHASINGCODE=5)
OR ((POSB=1 OR POSC=1) AND PHASINGCODE=3))
OR
((POSA=1 OR POSB=1 OR POSC=1) AND PHASINGCODE=7))
A query to identify equipment with a mixed status
(PHASINGCODE=6 AND ((POSA=0 AND POSB=1) OR (POSA=1 AND POSB=0)))
OR (PHASINGCODE=5 AND ((POSA=0 AND POSC=1) OR (POSA=1 AND POSC=0)))
OR (PHASINGCODE=3 AND ((POSB=0 AND POSC=1) OR (POSB=1 AND POSC=0)))
OR (PHASINGCODE=7 AND ((POSA=0 AND POSB=0 AND POSC=1) OR (POSA=0 AND POSB=1 AND POSC=0) OR (POSA=0 AND POSB=1 AND POSC=1) OR (POSA=1 AND POSB=0 AND POSC=0) OR (POSA=1 AND POSB=0 AND POSC=1)))
Let’s look at an example of applying this technique to our data.
First, run the query to identify features with a mixed status in your network. If this query identifies any features, then you will need to consider how you want to support devices with mixed status going forward. If acceptable, use a single status field and manage multiple fields accordingly. Otherwise, you will need to consider other options, like using the electric utility network foundation.
Next, select all the devices in the network that should be Open (Enabled=False).
Then, set the Enabled field on these features to be Disable/Open.
Note: If you have a large dataset you should consider disabling the network topology and any attribute rules on the device layer before applying these edits.
Once you apply the edits this will create dirty areas in your network that need to be validated. Before you validate your edits, repeat this process to identify any devices that should be Enabled/Closed. This is because the Enabled field is a network attribute, so changes to it must be validated using the Validate Network Topology tool. Once you’ve validated all the dirty areas in your network, or re-enabled your network topology, your traces will now respect this new value.
Now that we’ve talked through several techniques for modeling device status in an electric network, let’s look at how the utility network models circuits and why the utility network refers to them as subnetworks.
Electrical Phasing
Managing the energized phases is an important requirement for tracing and analysis for many electric customers. If you keep track of the phasing of every line and device in your system, then you should follow these steps to include your phase information in your network so you can use it during tracing and analysis.
To perform this configuration, you will need to identify the following information:
- What classes and fields contain phasing?
- Do you represent phasing using an integer value?
- What domain do you use to represent phasing?
With this information you can create and assign a network attribute used to track phasing in your network. The first thing you’ll need is a coded value domain to represent all the combinations of phases in your system. Because the utility network calculates and propagates phasing using bitwise operations, the field needs to be an integer if you want to use it to manage phase. If you don’t care about using phasing for quality assurance or analysis purposes, just for reporting purposes, you can represent it using a non-integer value. For both the basic and advanced articles we will be using an integer with a coded value domain designed for use with bitwise calculations, shown below, to represent phasing. You can learn more about how the utility network propagates attributes in the Attribute propagation and attribute substitution in subnetwork management article.
The next step is to make sure that your device, junction, and line class each has a single field that uses this domain to track phase. Once you’ve done this, you’re ready to configure your utility network to use this field.
First, you’ll add a network attribute to your network using the Add Network Attribute tool. Consider this rewrite: As with many utility network administration tools, it is necessary to disable your network topology before you can run the tool. When you mark the attribute as in-line you’ll need to make sure you pick the data type and domain you identified above.
Once you’ve added the network attribute to your utility network, you need to tell the utility network which classes and fields correspond to this network attribute. To do this use the Set Network Attribute for each class in your network that manages phase. This usually includes the Electric Device, Electric Junction, and Electric Line classes in the network.
With this completed, you will then be able to use this field when running traces using your network. The easiest way to use this attribute is to use it to act as a filter or barrier when you are tracing your network features. Below is an example that will return all the features that have an A phase on them.
Note: If you assign the phasing field at the field level for the corresponding network attribute of your classes, you will see a drop down instead of needing to type in a number manually.
This is a convenient reporting mechanism, however if we want the subnetwork to consider the phasing when determining what features are energized, we need to perform additional configuration. That topic is discussed in the advanced configurations article.
Create a subnetwork
Most electric distribution circuits originate at a circuit breaker or recloser located in a station. Everything downstream of this circuit breaker is part of the same circuit. In utility network terminology the circuit is a subnetwork, because it is a distinct subset of the network that is important for analytical purposes. The devices that act as sources/sinks for a subnetwork are known as subnetwork controllers. In the case of most electrical networks, the circuit breaker (or recloser) is a subnetwork controller, and most circuits have a single subnetwork controller. At a higher level, the distribution domain network is source-based. This means that the circuit breaker is the source of flow for the subnetwork, and it is upstream of all the features in the subnetwork.
We can determine the extent of a circuit by running a connected trace, with barriers for Disabled/Open features and circuit breakers. Below are the results of a trace with this configuration, originating at a circuit breaker:
Up until this point all the traces performed have been connectivity traces. That is because to perform an upstream, downstream, or isolation trace you must have subnetworks defined. There are two ways to create subnetwork controllers in the utility network. The first is to use the Modify Subnetwork Controller pane to select a feature and manually create a subnetwork.
Going back to our original example. Because we know that circuit breakers control our circuits, we should have checked the “Is Controller” option for that mapping in the Migrate To Utility Network tool. This will configure the resulting asset types in our utility network to act as subnetwork controllers. If that was not done, we will need to manually configure the circuit breaker asset type to be allowed to act as a subnetwork controller using the instructions on the Set a subnetwork controller page in the online help.
Once circuit breakers are allowed to be subnetwork controllers, we use the modify subnetwork controller tool to turn the circuit breaker into a subnetwork controller then validate the dirty area it creates. We can then run a subnetwork trace for that circuit, using the same condition barriers we’ve been using, and we will get the extents of the circuit.
Note: If you do not apply the condition barriers for Enabled/Device status to your trace you will not see the correct results. We will discuss why, and how to correct it in the Subnetwork Definition section.
We can also run upstream and downstream trace within that circuit, and if we apply our condition barriers the traces will succeed.
Now that you understand how to manually create subnetworks, the next step is to look at how you could import a collection of subnetwork controllers into the utility network. This is an important step for many electric networks as they may contain hundreds or thousands of circuits/subnetworks.
Importing Subnetworks
The second way to create subnetworks is to import a csv file containing information describing all the subnetworks in the system. Both approaches are valid, but for most electric customers it is relatively easy to produce a csv file defining all their subnetwork controllers. You can learn more about this process in the Import a subnetwork controller page of the online help. In this example we have created the following CSV file.
Once you’ve populated this CSV file, you use the Import Subnetwork Controllers tool to import the file into your network to enable the corresponding features as subnetwork controllers.
After importing our subnetwork controllers, we must validate the dirty areas on each of the controllers before they can be recognized as a source. Once you’ve done this, traces that rely on subnetwork controllers like upstream, downstream, and even isolation tracing may be performed
As we discussed previously, for our subnetwork traces to work we must still manually define condition barriers to ensure open switches stop our traces. In the next section we will learn how to use the Set Subnetwork Definition tool to make this the default behavior of all our subnetwork traces
Subnetwork Trace Configuration
Up until this point, every trace required that you specify a set of condition barriers as part of the trace configuration to ensure we get the correct results. Because we want these condition barriers to automatically be applied every time we run a trace, we can use the Set Subnetwork Definition tool to modify the definition of our subnetworks to include these condition barriers by default when performing subnetwork based traces. While we are modifying the subnetwork definition, we will discuss the importance of some of the other parameters in this tool that you may want to adjust.
The first step to modifying your subnetwork definition is to select the network, domain, and tier you want to modify. Once you’ve made these choices the tool will automatically populate with the current subnetwork definition for that tier.
The first thing we need to do is add our condition barriers to our subnetwork definition. This is done by populating the Condition Barriers parameter under the Subnetwork Trace Configuration section of the tool. Any changes made to the Subnetwork Trace Configuration section of the tool will affect the default trace configuration used by the utility network when analyzing this tier of the network.
By default, the Migrate To Utility Network tool adds a single condition barrier for disabled features.
In the previous example, we want to add another condition barrier to treat Open devices as barriers. If we have other network attributes configured that we want to use as barriers we could configure them here as well.
Another important option you should consider in this section of the tool is whether you want to include containers, content, and structures in your trace results. If you decide to model structures or containers inside your network, this will allow the subnetwork traces to quickly identify the features supporting or supported by the subnetwork.
This subnetwork trace configuration also allows you to define summaries for each subnetwork. These summaries allow you to calculate summary statistics during your traces, and if you define a summary attribute the results can be calculated and stored on your subnetwork line feature for reporting purposes. A simple example of this would be to calculate the total conductor length for a circuit, as shown below.
Each summary you calculate takes time during trace and update subnetwork, so be mindful of how much time is being spent calculating summaries versus the benefit they provide to your end users. Once you’ve adjusted your subnetwork trace configuration you can click run, however you may also want to adjust other sections of your subnetwork definition.
Valid Features and Objects
Another important section of the subnetwork definition is the Valid Features and Objects section. This determines which features are allowed to participate in subnetworks for this tier. When you add new asset types to your model it’s important to update your subnetwork definitions to account for them, otherwise you will get errors when you update your subnetworks that contain features with these new asset types.
You should also consider updating the Aggregated Lines for SubnetLine Feature Class parameter. This determines which geometries to consider when creating the subnetwork line class. By default, the utility network builder won’t include any asset types, meaning a subnetwork line won’t be generated when you update subnetworks. You should only select asset types for this parameter that represent medium and high-voltage lines. Do not select all your asset types for this parameter, as this has a significant negative impact on the drawing time of your subnetwork line layer.
Note: Features not included in the subnetwork line are still included in the summary statistics for the network, so if you want to calculate your conductor length consider using a Summary function in your trace configuration. This has the added benefit of allowing you to define a filter to calculate separate lengths for medium and low voltage conductor.
Update subnetwork policy
The last major section of the subnetwork definition is the update subnetwork policy. This gives you control over how subnetwork information is updated within your utility network. Making changes to these settings is not a simple decision for many customers, as it involves making tradeoffs between convenience and performance. We will give a brief overview of these decision points here and refer you to more thorough discussions where available.
The first, and easiest point to discuss is whether to update structure/domain network containers. If your subnetwork trace configuration includes structures/containers, you will see options here for whether to update them. This determines whether the subnetwork name, supported subnetwork name fields on your structures and containers will be updated when they contain or support a feature that belongs to a subnetwork. This allows you to use the select by attributes tool to identify features that support a subnetwork without running a trace. While this is convenient for reporting purposes, it also means that update subnetwork will take longer to run because there may be hundreds of thousands of additional features that need to be updated.
The next option to discuss is whether the tier should manage the IsDirty field, you can find a deep dive on state management on the Esri Community site. This field is used to indicate whether there have been edits validated in your utility network that have affected a particular subnetwork. This option is set to false by the utility network builder because it can have performance impacts.
If this property is enabled, then every time you validate edits, the utility network must perform one or more traces to identify which subnetworks are impacted. Because most electrical circuits contain only a few thousand features, this cost is usually relatively small compared to the benefits to quality assurance. However, you should consider leaving this property disabled if your subnetworks contain tens of thousands or hundreds of thousands of features.
Having this property enabled allows you to focus your quality assurance efforts on just the subnetworks that have been modified and allows you to easily identify which circuits have been clean and ready to be extracted to an external system like an OMS.
The most performant configuration is to leave this option disabled. The configuration that is most beneficial for quality assurance and integrations it to enable state management.
The last option to consider is which eventing mode to use for default and for named versions. This affects the performance of update subnetwork and whether the subnetwork field is populated during certain workflows. There is a deep dive on eventing modes on the Esri Community site. A greatly simplified version of the discussion follows.
When a subnetwork is updated without events it will run faster. This is because of several factors, but one reason is that attribute rules and editor tracking are not triggered. The largest drawback to this behavior is that when updating subnetwork in a named version, not all features are guaranteed to have their subnetwork name updated to match the subnetwork they belong to.
When a subnetwork is updated with events, the first update subnetwork operation that is run will take longer. Subsequent updates can also take longer to update if you have attribute rules configured and are updating large numbers of features. The benefit of updating subnetworks with eventing enabled is that when update subnetwork is run in a version you can guarantee that the subnetwork name feature is correctly populated for all the features belonging to that subnetwork.
Note: At ArcGIS Enterprise 11.4 and ArcGIS Pro 3.4, the performance cost of triggering attribute rules can be mitigated using the new Triggering Fields behavior of attribute rules.
The most performant configuration is to leave the eventing mode to update without events. The most useful configuration for quality assurance is to enable the eventing mode when in named versions and to ensure you have properly configured triggering fields on all your attribute rules.
Conclusion
Now that you’ve finished this article, you have learned the basics of how to configure tracing and network attributes to perform analysis using your electrical network. You also saw how you can create subnetworks that allow you to perform upstream, downstream, and isolation tracing. You also learned how you can adjust your subnetwork definition to take advantage of your network attributes. When you’re ready to learn some more advanced configurations, read the electrical networks advanced configuration article.
If you want to know more about using the utility network to manage electrical networks, please explore the Learn ArcGIS Utility Network for Electric Utilities series. This learning series includes tutorials and articles that demonstrate how to address the needs of the electric industry using the utility network.
Download and learn more about the Migration toolset and the Migrate to Utility Network tool on the Get started with the Migration toolset article. As always, if you have any questions or comments be sure to ask them in the Esri Community site!
