Subnetworks are updated to ensure attributes, network features, and connectivity are current and valid in a network. Updating a subnetwork also exposes errors and inconsistences in a subnetwork, such as invalid features, disjointed or inconsistent subnetworks, incorrect numbers of subnetwork controllers, or dirty areas that have not been validated. The update subnetwork operation is run from the Update Subnetwork tool or Find Subnetworks pane to update subnetworks that are marked as dirty after edits have been made and validated.
Subnetworks are marked as dirty when they're created and when validating the network topology after features and objects in the subnetwork are edited. When a subnetwork is updated with no errors, it's marked as clean. When validate consistency failures or subnetwork errors are discovered during the update subnetwork operation, the operation fails and the subnetwork is marked as invalid. This is tracked by the Is dirty attribute in the Subnetworks table and displayed in the Status column for each subnetwork in the Find Subnetworks pane. See Subnetwork life cycle to learn more.
Subnetwork properties inspected and updated
When a subnetwork is updated, various properties and requirements are checked. There are also certain attributes that are updated for network features. Some of these properties are set in the subnetwork definition for the tier.
When a subnetwork is updated on the default version, the geometry, subnetwork name attribute, and the propagated fields of the SubnetLine feature class are updated. If run against a named version, these same updates are limited to features and objects that are edited within the version, by default. The edit mode can be changed to use eventing in the Set Subnetwork Definition geoprocessing tool for utility networks of version 4 or later.
Dive-in:
When updating a subnetwork in a named version, the subnetwork name attributes, Is connected attribute, and propagated values are only updated for network features modified in that version. This default behavior can be modified by changing the Edit Mode for Named Version parameter to use eventing in the tier's subnetwork definition.Learn more about the edit mode used by the Update Subnetwork tool
Errors can be generated from updating subnetworks. To learn more about errors specific to updating subnetworks, see Update subnetwork errors.
The following subsections include information about the properties that are inspected when a subnetwork is updated.
Valid features and objects
As specified in the subnetwork definition, certain asset groups and asset types for each class are defined as valid for each tier in a domain network. Features and objects that violate the subnetwork definition are discovered when updating the subnetwork by inspecting the attributes of traversable features in the subnetwork. If invalid network features are discovered when updating a subnetwork, an error is created and the subnetwork is marked as invalid.
When updating subnetworks, the valid devices property for the subnetwork definition is not evaluated for boundary features that connect multiple subnetworks. These are subnetwork controllers that define the boundary of two different subnetworks, for example, an open switch between two circuits or a closed valve between two zones.
The following valid features and objects are specified in the subnetwork definition of each tier:
- Valid Devices
- Valid Device Subnetwork Controllers
- Valid Lines
- Valid Junctions
- Valid Edge Objects
- Valid Junction Objects
- Valid Junction Object Subnetwork Controllers
Subnetwork name attribute
The Subnetwork name attribute is used to track which subnetwork network features belong to. The value populated in this attribute field is derived from the subnetwork name of features that are set as a subnetwork controller. Additionally, features in the domain network have Supported subnetwork name and Supporting subnetwork name attributes. These attributes help track the subnetwork that a container or structure feature supports and the subnetwork that supports a content feature, respectively.
When a feature participates in multiple subnetworks, the Subnetwork name, Supported subnetwork name, and Supporting subnetwork name attributes are concatenated with each subnetwork name. For example, a boundary feature that connects multiple subnetworks would be updated by concatenating the subnetwork names separated by two colons, for example, subnetwork1::subnetwork2.
Learn more about the subnetwork name attribute
The update subnetwork process ensures that the subnetwork name is consistent for subnetwork features. Errors are generated for inconsistencies. The following situations outline cases in which errors may be encountered:
Inconsistent subnetworks—When a subnetwork has multiple subnetwork controllers that are traversable and the Subnetwork Name attribute does not match, the subnetwork is considered inconsistent. For example, in a mesh network with five subnetwork controllers, four of the subnetwork sources have the correct subnetwork name, while the fifth has a different name. If inconsistent subnetworks are discovered when updating subnetworks, a warning is returned in the Update Subnetwork tool and errors are generated. The specific subnetwork names found to be inconsistent are returned and can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table. Additionally, errors are created for the subnetwork controllers that have inconsistent subnetwork names.
Disjoint subnetworks—For partitioned domain networks, subnetworks with controllers that have the same subnetwork name and are not traversable are considered disjoint subnetworks. When updating subnetworks, errors will be generated for disjoint subnetworks if the subnetwork definition does not allow for this. This setting is defined within the subnetwork definition for the tier. Check the network properties to review the Tiers subsection of the specific domain network.
If any of the neighboring subnetworks are found to be inconsistent, a warning is returned during the update process listing the conflicting subnetwork names. To determine how to resolve the warning, neighboring subnetworks mentioned can be inspected using the Modify Subnetwork Controller pane and the Subnetworks table. Once the neighboring subnetworks are edited, the update subnetwork operation can be run again.
To learn more, see Subnetworks.
Is connected attribute
Every feature in the line, device, and junction feature classes as well as every object in the domain network's junction object and edge object tables contains an Is connected attribute. This attribute helps identify isolated network features and objects by maintaining information about their connectivity to subnetwork controllers. When a feature is created, regardless of its connectivity, the Is connected attribute is set to unknown. This attribute is modified for network features depending on the operation being performed.
When a subnetwork is updated, the Is connected attribute is modified based on the connectivity of features to a subnetwork controller; this is based on the Tier or Subnetwork Name parameters specified in the Update Subnetwork geoprocessing tool.
To learn more, read about the Is connected attribute.
Is dirty attribute
The Is dirty attribute is used to track the status of a subnetwork in the Subnetworks table and SubnetLine feature class, and impacts the consistency of network diagrams. This status of Is dirty is managed primarily through the disable, enable, and validate network topology tools and the update subnetwork operation. To learn more, see Subnetwork life cycle.
The Manage IsDirty option is a component of the update subnetwork policy and is configured as part of the subnetwork definition for a tier. This option allows you to bypass management of the Is dirty attribute in the Subnetworks table and SubnetLine feature class. If the tier is configured to not manage the Is dirty attribute, the update subnetwork operation can be used in the default version to delete rows from the Subnetworks table in the default version where the Is deleted attribute is set to true.
Note:
When there are no subnetwork controllers defined for a tier, the Manage IsDirty option is disabled.
To learn more about subnetwork status and the Is dirty attribute, see Subnetwork status.
Summaries, propagation, and attribute substitution
Summaries that are configured in the subnetwork trace configuration of the subnetwork definition are updated during the update subnetwork process. When updating a subnetwork, the tool writes the results of the summaries into the SubnetLine feature class for the summary attributes. Also, if substitution or propagators are configured, they are considered when a subnetwork is updated.
Review the following for details: Summaries, Attribute propagation, and Attribute substitution.
Update subnetwork policy
When the update subnetwork process is run, there are several options that control what network features are updated and how the edits are performed in the geodatabase. These options are configured as part of the subnetwork definition for a tier in the Update subnetwork policy section, using the Set Subnetwork Definition tool.
Review your workflows and determine whether changes are needed to the default update subnetwork policy. The Update Structure Network Containers and Update Domain Network Containers options can be modified in the subnetwork definition to prevent issues in which the supported subnetwork name field may be overloaded for structure and domain network containers. This can be helpful in situations in which there is nested containment. If there is a workflow that requires geodatabase events to occur for the attribute edits made during the update subnetwork process, the subnetwork definition for the tier can be configured to use eventing for the edit mode for the default version.
Options to set for Update subnetwork policy are as follows:
- Manage IsDirty—Specifies whether the update subnetwork process will update the IsDirty attribute in the Subnetworks table and SubnetLine feature class. This also impacts the consistency of network diagrams and the methods used to remove deleted controllers from the Subnetworks table.
- Update Structure Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for structure network containers. This option is checked by default.
- Update Domain Network Containers—Specifies whether the update subnetwork process will update the supported subnetwork name attribute for domain network containers. This option is checked by default.
Edit Mode for Default Version and Edit Mode for Named Version—During the update subnetwork process, various attribute edits are made to subnetwork features. The Edit Mode determines how the attribute edits are performed. Two options are available to control this behavior: With Eventing and Without Eventing.
- Without Eventing—This is the default for both the default version and named versions. When using this option, edits are performed as direct writes. By performing these attribute edits as direct writes, you bypass any events at the geodatabase level that update feature-linked annotation, or the evaluation of an attribute rule set on the insert or update triggering event.
Note:
When using this option with the default version, all features and objects in the subnetwork are updated. In a named version, updates are limited to features and objects that are edited in the version as a performance consideration for versioned workflows.
- With Eventing—This option additionally triggers events at the geodatabase level to update items such as feature-linked annotation, editor tracking, or the evaluation of an attribute rule set on the insert or update triggering event. In both default and named versions, all features and objects in the subnetwork are updated.
Note:
This option may adversely impact performance depending on the number of attribute rules and annotation classes in use with your data.
The example below illustrates the impact of running update subnetwork in a named version on the RMT001 subnetwork following the creation of a line, while using the default Edit Mode for Named Version which is Without Eventing. Notice that the subnetwork name is updated for only the feature that was edited in the version.
This example illustrates the impact of running update subnetwork on the RMT001 subnetwork following the creation of a line, when the tool is run in the default version, or when the tool is run in a named version and the Edit Mode for Named Version is set to With Eventing. Notice that while only one feature is edited, all features in the subnetwork are updated with the subnetwork name.
Note:
Certain parameters require a minimum Utility Network Version. Refer to the Set Subnetwork Definition tool for more information.
- Without Eventing—This is the default for both the default version and named versions. When using this option, edits are performed as direct writes. By performing these attribute edits as direct writes, you bypass any events at the geodatabase level that update feature-linked annotation, or the evaluation of an attribute rule set on the insert or update triggering event.