Skip To Content


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, network diagram events, and provide techniques to visualize your network: rendering, labeling, and map generation (for example, circuit and pressure zone maps). You can quickly determine the subnetworks in which a feature participates when editing your assets. 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 device 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 unique subnetwork name, not only in the tier, but in the entire utility network. This is to ensure the subnetwork name is unique in cases where a trace spans subnetworks in multiple tiers across more than one domain network. The subnetwork name used when the subnetwork controller is added is updated for every feature participating in a subnetwork when the subnetwork is updated. Updating the subnetwork name for 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.

Information about subnetworks is stored in the subnetworks table. This table stores information about the subnetwork controllers, the tier to which a subnetwork belongs, and editor tracking details. Another piece of information stored in this table is whether a subnetwork is dirty. Subnetworks are marked as dirty when initially created by adding a subnetwork controller, and can also be determined by the validation of dirty areas. Updating a subnetwork using the Update Subnetwork tool takes the edits made in the subnetwork and updates the subnetwork with relevant information. For a full list of situations where a subnetwork is considered dirty, see Dirty subnetworks.

The following is a summary of related subnetwork management tasks:

Hierarchical and partitioned tier definition

The tier definition that is assigned to a domain network determines the organization of the tiers relative to the rest of the network. The definition options are as follows:

  • Partitioned—Supports systems that are sequential in nature, such as electrical and telecommunications utilities
  • Hierarchical—Allows you to model networks that are nested, such as gas and water networks

The tier definition of a domain network impacts how subnetwork-based traces are handled. For domain networks with partitioned tier definitions, subnetwork-based traces stop at subnetwork controllers. For domain networks with hierarchical tier definitions, subnetwork-based traces stop at subnetwork controllers that have a tier name that matches the tier specified in the trace.

To learn more, see Tiers and Trace utility networks.

Topology type

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

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

  • Mesh—In a tier with a mesh topology type, each subnetwork has multiple subnetwork controllers and the subnetwork can have loops. In a mesh subnetwork, if only one subnetwork controller is discovered during tracing or when updating or exporting the subnetwork, an error is returned. Resolving the error requires either modifying the paths in the network or adding an additional subnetwork controller.
  • Radial—In a tier with a radial topology type, each subnetwork can have one or more subnetwork controllers. If the subnetwork contains multiple subnetwork controllers, it's considered to be multifeed.

When multiple subnetwork controllers define a subnetwork for either topology type, the subnetwork controllers can be multiple upstream or downstream terminals on one device, or many upstream and downstream terminals from multiple devices.

Subnetwork definition

At the time of configuration, the administrator of a utility network sets a subnetwork definition for each tier in a domain network. A subnetwork definition controls various properties for every subnetwork in the specified tier and is used when updating subnetworks.

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

The following table describes the components of a subnetwork definition:


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 class 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 from the Device and Line classes

Defines specific asset groups and asset types for Device and Line feature classes to participate in a utility network. These are specified in the Valid Devices and Valid Lines parameters. For example, a distribution tier allows medium and low voltage lines but not high voltage lines.

If connected or associated features with invalid asset types are discovered when a subnetwork is updated, error features are generated 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 some of the subnetwork trace configurations to determine the features that are considered during the event and the features that are updated, exported, or traced and returned. A subnetwork trace configuration can be modified using the tools associated with each of these operations. Some restrictions apply; see each tool for the available trace parameters.

The configuration options are as follows:

  • Summaries—Calculates and stores information about a subnetwork in the SubnetLinefeature class.
  • Condition barrier—Defines a feature that will stop an operation based on network attributes and categories.
  • Function barrier—Defines a feature that will stop an operation based on a function.
  • Propagators—Uses propagated network attributes to control what features are considered. A Substitution function is available. This parameter is only available programmatically.

To learn more about subnetwork trace configurations, see Subnetwork trace configuration.