Smart Grid (ArcGIS) (8-50)
Structure of a utility network
A utility network allows you to model how all the components of a utility system are connected, intelligently handle dense collections of utility features, and perform hierarchical tracing analysis of a network. The following is a structural overview of how a utility network is organized:
A preconfigured set of feature classes is created for you when you create a utility network. First, three feature classes are created to model the structural features that support the various types of utility features. These feature classes are collectively called the structure network.
A utility network contains one or more domain networks, one of which is always named structure and referred to as the structure network. These consist of standardized classes created during operations to create and add a domain network that is configured to model each of the systems operated by a utility.
In a domain network, all the features are first organized into tier groups and tiers. Tiers model the hierarchy of how the network delivers a resource such as natural gas, electricity, or water. A tier typically represents a pressure or voltage level. For example, an electric distribution system can be divided into sub-transmission, medium-voltage, and low-voltage levels, and some type of analysis should be performed in only one of these hierarchical levels. A tier can also represent parts of the network that can be isolated from one another, such as a valve isolation zone in a pressure-based system. Tiers are useful because they allow you to constrain the valid feature types for each tier, and they also define the range of network tracing analysis.
The flow of resources in a utility is controlled by devices such as valves and switches. The extent of resource delivery at a given time is called a subnetwork, and this corresponds to a pressure zone for gas and water utilities or circuits for electric utilities. With a utility network, subnetworks are discovered on demand by starting at the subnetwork controller of the delivered resource and tracing through the network until closed valves, open electric switches, or consumption points are reached.
All of the features in subnetworks are grouped into five feature classes and two tables in a domain network. These contain the features for subnetlines, devices, device assemblies, lines, and junctions where parts of the network connect.
When adding features, you have enhanced capabilities for defining how utility features are connected. While snapping features or line ends to the same location will automatically connect features, you can also specify that devices separated on the map be logically connected. This type of connectivity is especially useful for dense areas of your utility maps.
Many key utility devices are enclosed in cabinets, vaults, or yards or grouped into banks. With a utility network, you can group these internal features into container features so that the container can be shown on the map without the clutter of all the internal features.
Internal features can be viewed on-demand on a map or in a diagram view.
A rich type classification system is built into a utility network to help represent every type of utility feature. This is done using the ASSETGROUP and ASSETTYPE fields to provide a classification in the domain network classes with the use of subtypes and attribute domain assignment at the subtype level. Utility network operations—such as specifying network connectivity rules, symbolizing features, tracing, and many more—are configured on network feature classes using this classification system. This allows a utility network to define a fine-grained classification using a compact number of feature classes.
Some utility network features enable terminals to be modeled. Terminals can be defined on a device feature class or junction object table when it is important to track the different ports (such as high-side and low-side of service). Terminals provide more accurate tracing because you can control the valid paths for a resource. You can also define which terminal on a feature is the subnetwork controller. Terminals are also necessary for many external analytic software packages.
Engineers at a utility often prefer a schematic view of a utility system to augment the map view.
Schematic capabilities are built into the utility network and are called diagrams. You have considerable flexibility in configuring which utility features are depicted in a diagram as well as selecting algorithms for generating the diagram.
Utilities need to know which devices are attached to structures such as poles and vaults. A utility network allows you to define structural attachments so that you can generate inventory lists for areas and subnetworks, locate field assets by structure identifiers, and attach multiple types of utility features from different services (such as electric and telecommunication) to a common structure (such as a pole). You will define rules for the domain network features that can be attached to structural features. These structural attachments can be viewed on-demand on the map or in the diagram view.
Structure network
When a utility network is created, a common domain network named the structure network is included to be shared across different domain networks. Utilities commonly carry more than one type of resource on a common set of structures. For example, a pole may support electric lines, telecommunication wires, and cable lines. Similarly, a duct bank may carry many types of utility resources.
Sharing a structured network among multiple domain networks eliminates redundancy and allows you to better track joint usage on poles and ducts.
A structured network does not have any resources (such as water or electricity) flowing through it; however, the structured network can contain other features that are part of the resource-delivering network. For example, a vault (which is a structure) can contain valves and regulators (part of the active network).
The illustration above shows conceptually how a transformer is attached to a pole, as well as a connection point on the electric distribution line.
One key purpose of a structured network is to support a type of association called structural attachments. Structural attachments provide an efficient method to create a list of structures that are supporting a section or subnetwork. This satisfies a utility's need to rapidly identify which structure, such as a pole, is associated with a device that may be experiencing an outage. Features in the structure network can also act as containers for other network features. For example, a substation can contain other features such as junction boxes, devices, wires, and conductors. This allows a dense collection of features to be represented by a single feature.
Classes in a structured network
The structured network consists of three feature classes and two tables: StructureJunction, StructureLine, StructureBoundary, StructureJunctionObject, and StructureEdgeObject. These classes are created with system-provided attribute domains assigned to system fields for use by the utility network and require additional configuration for use.
The three feature classes are more fully described as follows:
The two tables are described as follows:
Domain networks
When you create a utility network, a structured network is automatically created with predefined feature classes and tables. The next step in configuring a utility network is to add one or more domain networks for each type of utility service that your organization serves.
Each utility network can contain one or more domain networks. You might create multiple domain networks for different levels of the same utility resource, such as distribution and transmission levels of gas, water, or electricity. Or you might add domain networks if your organization has multiple types of services, such as natural gas and electricity.
Each of these domain networks will share the same structure network so that you can find the devices and lines in your domain networks that are supported by common structures.
Domain networks contain the network features through which your delivered resource flows.
There are five types of features in a domain network:
Classes in a domain network
Each domain network consists of five feature classes and two tables that are created when you add a domain network: Device, Line, Junction, Assembly, SubnetLine, JunctionObject, and EdgeObject. These classes are created with system-provided attribute domains assigned to system fields for use by the utility network and require additional configuration for use.
The five feature classes are described as follows:
The two tables are described as follows:
A utility network consists of one or more domain networks and a structure network. The following diagram shows the classes in a utility network for a municipal utility that serves both gas and water to its customers:
Domain network class naming
The names given to classes are standard across all domain networks. To distinguish them, each class name is prefixed with the name of the domain network. The classes included in a domain network are listed in the following table. Additionally, an alias name is given to all the domain network classes. This alias is set when a domain network is added. For example, a GasDevice feature class could have a default alias name of Gas device. This alias can be changed.
Subnetwork analysis
All utilities manage the gathering or generation of a resource, convey it through an intermediate system of pipes or wires, and distribute that resource to the points of consumption. The following are examples:
Resource flows
A utility resource is delivered from a source or set of sources or collected at a sink or set of sinks. A source is the origin of the resource delivered and a sink is the destination of the gathered resource. This is configured when you add a domain network.
For a gravity-fed water collecting system, sinks of water are reservoirs and tanks. For an electric system, sources of electricity are power-generating stations and substations. For a gas system, sources of natural gas are compressor stations and regulating stations.
From each source or to each sink, the utility resource flows by pressure, gravity, or voltage until it is either impeded by an operating device such as a valve or switch, or until it reaches the point of consumption.
Sources and sinks are modeled using device features that have been set as subnetwork controllers. For a gravity-fed water collecting system, a tank or reservoir is a typical sink feature. In an electric distribution system, a circuit breaker is a typical source feature. In a gas distribution system, a town-border station is a typical source feature. These flow systems either have a set of valid source feature types or a set of valid sink feature types, but not both. Either the flow is delivered by pressure or voltage (from source features) or gathered by gravity (to sink features).
Resource flow modeling
The entire utility network is subdivided into a set of zones or circuits in which that resource can flow. The flow of resources is dynamically delimited by valves and switches. The extent through which the resource can flow changes whenever a switch or valve device is changed from an open to a closed setting or vice versa.
A utility network models zones and circuits with subnetworks. A subnetwork is a set of connected features that are distributed with the utility resource from one or a few sources or to one or a few sinks. A utility system can have hundreds or thousands of subnetworks. The sources and sinks used to define the extent of a subnetwork are called subnetwork controllers.
Each subnetwork resides within a tier within a domain network and has a unique name. The name for a subnetwork is defined in the subnetwork controller, and the name of the subnetwork can be propagated to every line and device that can be traversed within the subnetwork.
A special attribute on Line, Device, and Junction feature classes is the IsConnected attribute. This attribute is used to identify features that are not traversable from any subnetwork controller. This lets you locate equipment that is either intentionally isolated in your domain network or not correctly edited.
Subnetworks are important to a utility because they give operations personnel situational awareness of the utility system's present configuration. At a glance of the map, staff can understand how gas, water, or electricity is being delivered. This information is vital when recovering from outages, optimizing the delivery of the resource, or determining which structural assets are attached to a subnetwork.
Changes to subnetworks
Recommended by LinkedIn
Because the extent of a subnetwork changes whenever an operating device is opened or closed, subnetworks are derived on demand. You can update the subnetworks in your utility network at any time. When you do, a network trace method is executed starting at the subnetwork controllers. The output of this tracing method is used to update the Subnetworks table, attributes on features, and generate features within the SubnetLine feature class. This feature class contains multipart line features, representing all the connected lines for each subnetwork. These subnetwork lines can then be drawn with distinct colors to easily identify the extent of zones and circuits.
Network hierarchies with tiers
You can use tiers to organize a natural hierarchy in a domain network. Tiers typically represent ranges of pressure, voltage, or another characteristic of the network.
Network organization
Utility systems are organized into networks for the delivery of a utility resource.
An electric utility is typically organized into tiers such as transmission (high voltages), distribution (medium voltages), and secondary (low voltages). An electric feature can only be in one tier or another. This is modeled using a partitioned tier definition.
Gas and water utilities have tiers for the gathering of gas or water, the transmission of gas or water over long distances, and the distribution of gas or water to the consumer. Tier groups are used in the domain network to model the different sectors of a network. For example, in a gas domain network, a tier group of Distribution includes different tiers for system, pressure, and isolation. A feature such as a device can be in two distinct tiers in a tier group. This is modeled using a hierarchical tier definition.
Tier hierarchies can be modeled in one of two ways: through distinct domain networks or through tiers in a domain network. The graphic above shows a typical organization of the hierarchies in an electric utility that illustrates these two options.
First, the electric transmission level is modeled as a distinct domain network. This is done because electric transmission is handled by a different department at the electric utility from electric distribution. There is usually a regulatory requirement for the separation of operation between the transmission and distribution levels of electric power. Because of this requirement, two distinct domain networks for transmission and distribution is the best solution.
Second, the hierarchy within the electric distribution domain network is achieved with two tiers as shown above. The medium voltage tier starts at the low-side terminal of the outbound circuit breaker of the substation. Each circuit within a tier then traverses all the lines and devices until the high-side terminal of distribution transformers, which convert electric power to low voltages. The low voltage tier begins either at the low side of a distribution transformer or at the low side of a network protector in the case of a spot or grid electrical network. This is the best solution for modeling network hierarchy in a domain network that is managed by one department or division.
Tiers
A domain network can have one or several tiers. For example, the electric transmission domain network shown above has only one tier, the high voltage tier.
A tier is a subgrouping of a domain network that represents the logical hierarchy of subnetworks. When you define a tier, you do so by specifying subnetwork control devices, which delimit the subnetworks to that tier. In the above example, a medium voltage tier in an electric distribution domain network would have a subnetwork source feature type of circuit breaker. A low voltage tier would have subnetwork source feature types of distribution transformer or network protectors. These subnetwork control devices are used to define subnetworks in each tier level.
Each tier has a rank number in the hierarchy of tiers. Rank 1 is the high level. In the example above, the medium voltage tier has rank 1 and the low voltage tier has rank 2. Sometimes, different tiers may share the same rank. For example, a gas domain network may have pressure tiers and valve isolation tiers with the same rank because isolation subnetworks can be nested inside pressure subnetworks.
Tier topology modeling
Tiers in a domain network can have either a hierarchal tier definition or a partitioned tier definition.
Tiers in an electric utility typically follow a partitioned tier definition. This means that there is a progression of tiers (based on declining voltage levels) that are exclusive to each other. A medium voltage subnetwork is distinct from a low voltage subnetwork and does not share features.
Tiers in a gas utility can have a hierarchical tier definition. This means that features in a domain network can belong to subnetworks in two different tiers. For example, a gas utility typically defines a pressure tier and valve isolation tiers with nested subnetworks. A single pressure subnetwork can have several valve isolation subnetworks.
Each tier also has a topology type. This is set at the tier level and pertains to all subnetworks within a tier. Radial is the typical configuration of a medium voltage electric tier. Some gas and water tiers also have radial topology. Mesh is a common topology type of gas and water subnetworks. This is also a topology type of spot or mesh network in low voltage electric tiers. Dense urban centers have a mesh network with redundant sources for high reliability.
Both topology types are shown in the illustration above.
Tier A has a radial topology type. There is one source (at the far left) for the subnetwork labeled A1.
Tier B has three sources at the left and has a topology type of radial. Subnetwork B1 has one source and a radial topology. Subnetwork B2 has two sources and no loops, hence a radial topology.
Tier C has a mesh topology. The subnetwork labeled C1 has three sources and several loops. This tier has a mesh topology.
Terminals
With a utility network, you can model features to a high degree of realism with terminals on devices and junction objects. Features in the field have defined locations or ports from which resources, such as electricity and water, flow in and out. A utility network allows you to optionally model these ports with terminals.
For example, an electric distribution transformer (shown above) has five ports, two on the high side named H1 and H2 and three on the low side named x1, x2, and x3. You can model this transformer in one of two ways: with a simple two-terminal configuration or a detailed five-terminal configuration. The five-terminal configuration corresponds more closely to the ports on the physical transformer and is preferable if you want to achieve a high-fidelity representation.
Connection points with terminals
A key use of terminals is to define the origin of a subnetwork. For example, in an electrical system, a subnetwork typically begins at the load side of a breaker in a substation. Some external analysis software, such as electric voltage drop analysis, relies on a complete definition of devices that includes terminal definitions.
Not all features require the definition of terminals. If a feature has two terminals that are equal and interchangeable, such as the two sides of a switch or valve, you do not need to define terminals.
The situations where you should define terminals are as follows:
Terminals are not features and do not appear on the map. They exist as logical connection locations on a device or junction object that allow you to control how other features can connect, and the valid paths through which a network commodity can travel. Certain network rule types can be defined at the terminal level.
Connectivity
When you connect features with terminals to the endpoints of lines, edge objects, junctions, and other devices or junction objects (with or without terminals), you specify which terminal connects which feature.
For example, in an electric system, you connect the high-side terminal of a distribution transformer to a line with medium voltage, and the low-side terminal to a line with low voltage. This behavior is enforced using network rules.
Terminal configurations
Terminals are configured on a feature by assigning a terminal configuration. A terminal configuration is added to a utility network and assigned to specific asset groups and asset types in the Device feature class or JunctionObject table.
A terminal configuration has a directionality setting that dictates which way a resource flows through it. It has a set number of terminals, each with a name. Terminal configurations with three or more terminals have valid paths defined to constrain how the resources flow through the paths between pairs of terminals. To learn more, see Terminal management.
Junction and edge objects
Junction and edge objects are nonspatial network objects used to model and work with a large number of real-world features that share a common geographical space, for example, the strands inside of a fiber cable or conductors in an underground duct. This allows organizations to model their network in more detail without the need to create features with shapes for every asset.
Junction and edge objects are unique among tables, in that they support connectivity with other features and can act as a container (such as a switch box that contains multiple ports). Associations are used to model connectivity, containment, and structural attachment between junction objects, edge objects, and other features in the network.
The structure and domain networks that comprise the utility network include two additional tables to model nonspatial objects.
One of the primary capabilities that expose the power of the utility network is the ability to model assets as they appear on the ground with a high degree of realism. Rows in both the JunctionObject and EdgeObject attribute tables participate in the network topology in the same way as spatial features to enable analytic capabilities such as tracing and diagrams.
In industries such as electric, gas, or water, junction and edge objects can be used to model underground structures such as the conduits, ducts, and inner ducts that represent the hierarchy of underground structures necessary to maintain cables and pipes. Asset modeling is not limited to the simple representation of devices, cables, pipes, and so on; it also includes how they can be used for analysis.
Consider the example of telecom cables and the individual strands of fiber that exist in each cable. Telecom cables can contain thousands of fiber strands that transport data through the network. With assets such as these, it is necessary to model each individual strand, since each customer service may only use one or two. These non-spatial objects allow additional levels of granularity to be modeled effectively in this scenario. Representing thousands of fiber strands as spatial features could prove to be problematic, as you would have to work with stacked geometry, which would negate the value of spatial representation.
When modeling network features that contain multiple levels of granularity, such as in an underground electric or telecom network, you have to consider that large hierarchies of equipment exist at both the substation (for example, rack, device, slot, card, and port) and cable level (for example, cable, buffer tube, and strand). Only the highest-level asset in the hierarchy must be represented as a feature with a shape, while all the other assets can be represented in a tabular format as either a junction or edge object associated with the spatial feature. In the previously mentioned example, the telecom cable could be modeled as a line feature and serve as a container for the fiber strand content represented as edge objects. The line feature is used to display a spatial location for the fiber strands to the user.
Locatability
Associations with spatial features are used to determine the location of, and visually represent, nonspatial objects on a map. For example, a port modeled as a nonspatial junction object can be associated with a switch device as content in a containment association. Nonspatial objects are added to the network topology when the network topology is enabled or through an association with a spatial feature in the association hierarchy during validation. If the association is deleted or does not exist when the network topology is enabled, this can create a scenario in which the port is unlocatable.
The capability of nonspatial objects is important because spatial features provide a mechanism to create dirty areas and validate edits made to nonspatial objects so they can be updated in the network topology. Junction and edge objects are locatable when they are contained by or structurally attached to a feature within their containment or attachment hierarchy.
In figure 1 below, edge object C and junction object D are locatable through containment associations with spatial features, line A and point B, respectively. Similarly, in figure 2, junction object B is locatable through a structural attachment association with point feature A.
It is important to note that junction-junction connectivity associations cannot be used to determine the locatability of a junction object or edge object. Figure 3 shows that even though junction object B is associated with point feature A through a junction-junction connectivity association, it is considered unlocatable without another containment or structural attachment association to another feature or locatable object.
An edge object may also be located when associated with a junction at its endpoints or in situations where the edge object is associated with a locatable junction object through a junction-edge or junction-edge midspan connectivity association.
For an example, see the scenarios below:
No dirty areas are created as a result of edits made to an object that is not locatable. As a result, these edits are not reflected in the network topology. Geometry and network attribute edits made to unlocatable objects require you to disable and enable the network topology to reflect the changes.
The Trace and Set Subnetwork Definition tools provide a Validate Locatability option to identify objects traversed during a trace that are not locatable through a containment, attachment, or connectivity association in their association hierarchy. When unlocatable objects are discovered, the tools return an error that includes the class name and global ID of the objects for inspection.