Subnetworks

A subnetwork represents a topological subset in a tier where all participating features have traversability to the same subnetwork controllers. A subset is a collection of connected lines, devices, and junctions. Subnetworks drive tracing and network diagram events and provide techniques to visualize your network: rendering, labeling, and map generation (for example, circuit and pressure zone maps). The maintenance of subnetwork information is optimized by the ability to export subnetwork information to external systems for further modeling and analysis.

A subnetwork is created by setting one or more network features as subnetwork controllers. The name of the subnetwork is defined when a terminal is set to be a subnetwork controller. Each subnetwork in a tier must have a subnetwork name that is unique across the entire utility network. This is to ensure the subnetwork name is unique in cases in which a trace spans subnetworks in multiple tiers or across more than one domain network. The subnetwork name provided is updated for every feature or object participating in a subnetwork when the subnetwork is updated. Updating the subnetwork name for network features is what completes the process of creating a subnetwork: a group of assets with traversability to the same subnetwork controller or controllers.

See Concepts and operations to review key topics for managing subnetworks.

Subnetwork management

Subnetworks are marked as dirty when created by adding a subnetwork controller and are also marked as dirty when changes are made and validated to update the network topology. Updating a subnetwork from the Find Subnetworks pane or through the Update Subnetwork geoprocessing tool takes the edits made in the subnetwork and updates the subnetwork with relevant information. When updating a subnetwork, if validate consistency failures or subnetwork errors are discovered, the update operation fails and the subnetwork is marked as invalid.

Learn more about how subnetwork management tasks impact the subnetwork status

Information about a subnetwork is stored in the subnetworks table. This table stores information about the subnetwork controllers, the tier to which a subnetwork belongs, editor tracking details, and whether a subnetwork is clean, dirty, or invalid.

The following is a summary of related subnetwork management tasks:

• Create a subnetwork
  • Set a subnetwork controller
  • Validate network topology
  • Run update subnetwork
• Update a subnetwork
• Modify a subnetwork
• Identify isolated features
• Remove a subnetwork controller
• Delete a subnetwork
• Export subnetwork information

Learn more about the subnetwork life cycle

Hierarchical and partitioned tier definition

The tier definition is a property that's defined when you add a domain network to the utility network. A tier definition denotes the organization of the tiers relative to the rest of the network. In a domain network or tier group, two or more tiers can form a collection of partitioned, successive tiers or a hierarchy of nested tiers. In a utility network, all tiers in a domain network or tier group share the same tier definition. A utility network can have multiple domain networks with different tier definitions.

To learn more, see Tiers.

Topology type

Subnetworks support two topology types for modeling different systems: mesh and radial. The topology type of a subnetwork is set at the tier level and defined when a tier is created. All subnetworks in a tier share the same topology type.

Note:

In a domain network with a hierarchical tier definition, only the mesh topology type is supported. The topology type of subnetworks in a partitioned network can be either mesh or radial.

The following topology types are available when adding a tier:

• Radial—Consists of one or more subnetwork controllers
• Mesh—Consists of one or more subnetwork controllers

Note:

The topology type currently does not provide a difference in behavior for tracing or subnetwork management. The functionality is under development and will be applicable in a future release.

Each subnetwork controller in a subnetwork has a unique Subnetwork Controller Name but must share the same Subnetwork Name.

Subnetwork definition

At the time of configuration, the administrator of a utility network sets a subnetwork definition for each tier in a domain network. The subnetwork definition controls various properties for all subnetworks in the specified tier and is used when performing subnetwork-based traces and updating subnetworks.

To learn more, see Set or modify the subnetwork definition.

The following table describes the components of a subnetwork definition:

Component	Description
Support for disjoint subnetworks	Defines whether two or more subnetworks with the same name can be traversed to one another. This option is only available for tiers in domain networks with a partitioned tier definition. Tiers in a domain network with a hierarchical tier definition always have this property set to true to support disjoint subnetworks.
Valid subnetwork controllers	Defines specific asset groups and asset types in the Device and Junction Object classes that can have their terminals set as subnetwork controllers. Only terminals belonging to valid subnetwork controllers can be used to create or modify controllers for a specified tier.
Valid features	Defines specific asset groups and asset types for network features to participate in a utility network. For example, a distribution tier allows medium- and low-voltage lines but not high-voltage lines. These are specified in the subnetwork definition for a tier and inspected when a subnetwork is updated. Valid Devices Valid Lines Valid Junctions Valid Junction Objects Valid Edge Objects If connected or associated features with invalid asset types are discovered when a subnetwork is updated, errors are generated, the status is set to Invalid, and the subnetwork is not updated.
Aggregated lines for the SubnetLine feature class	Defines a subset of lines from the Valid Lines parameter to aggregate together to represent a subnetwork in the SubnetLine feature class.
Subnetwork diagram template	A diagram template is used as the template for the automatically generated subnetwork diagrams. This component is optional. These diagrams are generated and updated each time the subnetwork is updated. When a subnetwork is deleted, the associated subnetwork system diagram is also deleted.
Subnetwork trace configuration	Subnetwork trace configurations are optional and can be set during the configuration stage of a utility network. Subnetwork events (updating, exporting, and tracing) use the subnetwork trace configuration to determine the network features that are considered during the event and updated, exported, or traced and returned. The subnetwork trace configuration for a tier can be modified using the tools associated with each of these operations. (Some restrictions apply; review each tool for the available trace parameters.) The configuration options are as follows: Include Containers—Specifies whether containers will be included. Include Content—Specifies whether content of containers will be included. Include Structures—Specifies whether structures will be included. Include Barrier Features—Specifies whether barriers will be included. Validate Locatability—Specifies whether an error will be returned if unlocatable junction or edge objects are encountered. Summaries—Calculates and stores function information about a subnetwork in the SubnetLine feature class. Condition Barriers—Defines a feature or object that will stop an operation based on network attributes and categories. Function Barriers—Defines a feature or object that will stop an operation based on a function. Apply Traversability To—Defines the traversability scope to enforce. Apply traversability to only junctions, only edges, or both junctions and edges. Propagators—Uses propagated network attributes to control what network features are considered. A Substitution function is available. This parameter is only available through Python. To learn more about subnetwork trace configurations, see Subnetwork trace configuration.
Update subnetwork policy	The parameters associated with the update subnetwork policy define which network features are updated and how attribute edits made during the update subnetwork operation are performed in the geodatabase. Options to set for Update subnetwork policy are as follows: Manage IsDirty—Specifies whether the Is dirty attribute in the Subnetworks table is managed by the update subnetwork operation. This also impacts the consistency of network diagrams and the methods used to remove deleted controllers from the Subnetworks table. When this option is enabled, the IsDirty attribute is managed by the update subnetwork operation and updated in the Subnetworks table and SubnetLine feature class. Note: If the tier is configured to not manage the Is dirty attribute, the subnetwork will always appear as Dirty whether an update subnetwork operation succeeds or fails. When this option is not enabled, 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. 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. 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 and named versions as well as when working in a single-user deployment. When using this edit mode in an enterprise deployment, geodatabase contracts are not honored during update subnetwork. This means that events do not trigger updates to editor tracking, attribute rules, or related objects when features are updated. This also means that changes made to features without events do not write geodatabase history for later review. This approach is taken to optimize the performance of update subnetwork. When using this edit mode in the default version or a single-user deployment, the subnetwork name and propagated values are updated for all features and objects in the subnetwork. When using this edit mode in named versions, the subnetwork name and propagated values are updated only for features edited by the user in the version. With Eventing—This option enables users to trigger geodatabase behavior when updating subnetworks in the default and named version as well as when working in a single-user deployment. With this edit mode, cursor updates are used to update the subnetwork name and propagated values for all features traversed by the operation. Using With Eventing respects all geodatabase contracts. This means that attribute rules fire and have their validation status reset, editor tracking is updated, related objects are updated when applicable, and changes are recorded as actual edits in the history of the geodatabase. This edit mode should be considered for users who require attribute rules to fire during the update subnetwork operation. Caution: This option may adversely impact performance and should not be used with larger subnetworks when a large number of attribute rules or related objects, such as feature-linked annotation classes, are present in 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.