17 min read3,760 words

Subnetwork Management & Controller Configuration

A utility network’s subnetworks are what turn a connected graph into an operational picture. The graph says a valve is attached to a main; the subnetwork says that main belongs to the Elm Street pressure zone, is fed by the Ridge pump station, and carries a hydraulic grade propagated from that source. Every consumer that asks an operational question — which circuit is this on, which zone loses pressure, which feeder do we switch — is reading a subnetwork, not the raw topology established in topology and tracing workflows.

The failure this page addresses is a specific and unusually quiet one. A subnetwork name is stamped onto features by an update process, not computed on demand. When the update has not run since the last edit, or when it ran but could not reach part of the network, the affected features keep the name they were last given. They do not report an error and they do not report an empty value; they report a circuit or a zone that was correct last week. Downstream, a load transfer is planned against the wrong feeder, a pressure-zone report counts the wrong mains, and an isolation trace bounded by subnetwork membership excludes a span that is genuinely connected.

What an Update Subnetwork run actually does, stage by stage A subnetwork update begins from the controllers a tier declares. It walks outward from each controller across traversable edges, stops at barriers, writes the subnetwork name onto every feature it reached, recalculates the propagated attributes those features carry, and finally clears the dirty areas that made the update necessary. A feature the walk never reached keeps whatever subnetwork name it last held, which is why an orphaned span reports a stale circuit rather than no circuit at all. CONTROLLERS sources and sinks declared per tier TRAVERSE outward across traversable edges STAMP subnetwork name onto reached features PROPAGATE phase, pressure zone accumulated attributes CLEAN dirty areas cleared tier marked current orphaned span NEVER REACHED keeps its previous subnetwork name — a stale circuit, not a blank one The stamp is a side effect of the walk; nothing the walk missed is corrected.

Prerequisite Checklist

Core Data Model: Controllers, Tiers and Propagated Attributes

A subnetwork controller is a marker on a feature that says “flow originates here, on this terminal, for this tier.” It carries a name, and that name becomes the subnetwork name every feature the walk reaches is stamped with. Placing a controller is therefore not an annotation; it is a declaration that changes the membership of everything downstream of it.

A tier groups subnetworks of the same kind and decides how they may relate. A hierarchical tier expects strict nesting, so a subnetwork found to loop back on itself is an error worth reporting. A partitioned tier expects peers, so an interconnection between two subnetworks is normal and it is unintended merging that is the error. The distinction shapes every validation rule the tier applies.

Hierarchical against partitioned tiers, and what each one assumes about the network A hierarchical tier assumes a strict parent-child arrangement in which every subnetwork below a controller belongs to exactly one subnetwork above it, which is how electric distribution behaves: a service belongs to one transformer, which belongs to one feeder. A partitioned tier assumes peers that may interconnect without nesting, which is how water pressure zones behave: two zones can be tied together through a normally-closed valve without either containing the other. Choosing the wrong one is not a preference error; the update algorithm and the validation rules differ. Property Hierarchical tier Partitioned tier Typical use electric distribution water pressure zones Membership one parent subnetwork peers, no nesting Interconnection through the parent only tie devices between peers Multiple controllers usually one source several, deliberately Common failure loops report as errors zones silently merge Pick the tier type from the physics, then let the validation rules follow it.

Propagated attributes are values pushed outward from the controller along the walk. Electric phase is the canonical example: the controller declares A, B and C, and each device the walk crosses either passes the phase through, drops one, or substitutes another. Water systems propagate pressure zone and, where the model supports it, hydraulic grade. The important property is that propagation is recomputed by the same update that stamps the name — so a stale subnetwork also means stale phase, and a phase-based analysis inherits the staleness without any signal that it has.

Two further pieces matter in practice. Subnetwork line features, where the model maintains them, are a cached geometry of each subnetwork’s extent — useful for maps and for spatial joins, and another artefact that goes stale between updates. And the subnetworks table records, per subnetwork, when it was last updated and whether it is currently dirty, which is the one place automation can read to decide whether a trace result can be trusted.

Step-by-Step Implementation

  1. Choose the tier type before placing any controller. Model electric distribution as hierarchical and water pressure zones as partitioned unless the physics says otherwise. Changing tier type later invalidates every subnetwork in it.
  2. Place controllers on genuine sources. A controller on a convenient junction rather than on the physical source produces a subnetwork whose extent is right and whose direction is wrong, which is worse than an obvious error because traces still return plausible results.
  3. Name subnetworks from the operating vocabulary. Controllers named for the circuit or zone the operators use — RIDGE-PZ-3, not SUBNET_0047 — is what makes a stamped attribute readable in a dispatch console without a lookup.
  4. Define propagated attributes and their substitutions. Declare what each device class does to the propagated value: a three-phase switch passes all three, a fused cutout may drop one, a regulator resets pressure zone. Undeclared behaviour defaults to pass-through, which quietly propagates a value through a device that physically blocks it.
  5. Update the subnetwork and read the result, not the return code. Run arcpy.un.UpdateSubnetwork for the tier, then query the subnetworks table for the last-updated timestamp and the dirty flag. A run that completes while leaving the tier dirty has not finished the job.
  6. Validate membership against expectation. For each controller, compare the count of stamped features against the previous run. A subnetwork that gained or lost a large share of its features overnight is either a real switching change or a controller defect, and the automation should say which it believes it is.

Diagnostic Protocol

Work these in order; the first two account for most reported defects.

  1. Confirm the tier was updated after the last edit. Read the last-updated timestamp from the subnetworks table and compare it against the most recent edit in the extent. A stale update is the single most common cause of a wrong subnetwork name.
  2. Confirm the controller still exists and is enabled. A controller removed during a retirement, or disabled during maintenance, leaves its whole subnetwork unstamped on the next update while the old names persist on the features.
  3. Look for a truncated walk. Compare the stamped extent against the physical extent. A walk that stops part-way points at a barrier in an unexpected state or at a connectivity break, which the network fragmentation and gap resolution workflow is built to find.
  4. Check for competing controllers. Two controllers reaching the same span means two subnetworks have merged. In a partitioned tier that may be a legitimate interconnection; in a hierarchical tier it is an error and the tie device between them is usually the culprit.
  5. Verify propagated attributes separately from membership. A feature can carry the right subnetwork name and the wrong phase, because propagation and stamping fail independently when a device’s substitution rule is missing.
  6. Re-read after a full update, not an incremental one. An incremental update covers only the dirty extent; a subnetwork whose controller sits outside that extent may not have been walked at all.
Reading a wrong subnetwork name back to its cause The first question is whether the tier was updated after the edit that changed the network. An out-of-date subnetwork is the most common cause of a wrong name and the cheapest to rule out. If the update is current, the split is between a controller problem and a traversability problem: a controller that was removed, disabled or never assigned leaves its whole subnetwork unstamped, while a barrier in an unexpected state — an open device the model believes is closed — truncates the walk part-way and leaves the far end holding its previous name. A feature reports the wrong subnetwork name update is stale Was the tier updated after the edit? no Run Update Subnetwork, then re-read partially Check the dirty-area extent the update covered update is current Controller, or traversability? controller Controller removed, disabled, or never assigned traversability A barrier truncated the walk — device state is wrong both present Two controllers claim the same span — subnetworks merged A stale name and a missing name are different faults; the first is far more common.

Performance & Scale Considerations

A subnetwork update is a graph walk over the whole tier, and its cost scales with the number of features reached rather than with the size of the edit that triggered it. Three practices keep that cost predictable.

Update per tier, not per network. Tiers are independent, so updating only the tier whose features changed avoids re-walking commodities that were never touched. On a combined estate this is often an order-of-magnitude saving for no loss of correctness.

Schedule the update against the edit rhythm. A subnetwork updated after every edit spends most of its time walking; one updated nightly is stale all day. The workable pattern is an immediate update in the editor’s own version, so the editor sees a correct result, and a scheduled update on the default version after the post window closes.

Isolate batch updates in a version. An update holds locks across the tier, and running one on the default version during field-edit hours produces exactly the contention that makes people avoid running it at all. Run it in a named version and post, following the same isolation discipline as batch topology processing with Python.

Watch the subnetwork line features. Where they are maintained, regenerating them is often more expensive than the walk itself. Regenerate on a slower cadence than the stamp, and mark them as derived so no analysis treats them as authoritative membership.

Compliance Notes

Subnetwork membership is the attribute most regulatory reporting is grouped by, which makes its currency an audit question rather than a housekeeping one.

  • Reliability reporting aggregates outages by circuit or zone. A subnetwork stamped before a reconfiguration attributes an interruption to the wrong feeder, and the resulting index is wrong in a filing rather than in a map.
  • Pressure-zone compliance under drinking-water rules depends on knowing which mains belong to which zone at a given moment. Persist the subnetwork name with the version moment it was stamped at, so a later reviewer can reproduce the grouping.
  • Switching records should carry the subnetwork names before and after the operation. That pair is the evidence that a load transfer moved what it was authorised to move.
  • Required audit metadata per update: tier name, controller set, last-updated timestamp, feature counts per subnetwork, dirty-area extent covered, and the arcpy version that ran it.

Controller Placement Patterns by Commodity

Where a controller goes is a modelling decision with operational consequences, and the right answer differs by commodity because the physical sources differ.

Electric distribution places the controller at the substation circuit breaker, on the terminal that feeds the circuit. That is the device operators think of as the origin of the feeder, the device whose operation de-energises it, and the point protection engineering already treats as the boundary. Placing it further out — at the first pole, say — produces a subnetwork that excludes the getaway cable and reports the feeder as shorter than it is.

Water distribution places it at the pump station discharge or at the outlet of the regulator that defines the pressure zone. The subtlety is that a zone frequently has more than one source, and each is a controller: a partitioned tier expects that, and modelling only the largest source makes the others invisible to every zone analysis.

Gas distribution places it at the regulator station outlet for each pressure class. Because a gas system steps pressure down through several classes, one physical station commonly carries controllers for two tiers, and getting the terminal right is what keeps the high-pressure and distribution subnetworks from merging.

The shared rule is that a controller marks a physical source, not a convenient graph vertex. Every departure from that rule produces a subnetwork whose extent looks reasonable and whose direction, propagated attributes and isolation boundaries are wrong in ways that only surface during an event.

Keeping Subnetworks Current Under Continuous Editing

An estate with active field editing never has a moment when nothing is dirty, so “update when the network is clean” is not a workable policy. What works is deciding, per consumer, what staleness is tolerable and publishing that.

Interactive editing needs an immediate answer, and it gets one from updating the tier inside the editor’s own version, where the walk is bounded by the edits in that version and completes in seconds. Operational consumers — dispatch, outage management, the trace services — need the default version’s subnetworks to be current within minutes of a post, which argues for triggering the update from the post rather than from a clock. Analytical consumers can tolerate overnight staleness provided they know it: a report that stamps its own subnetwork as-of time is honest, and one that does not is a trap.

The measurement that makes this manageable is subnetwork age: for each tier, the interval between the newest posted edit affecting it and the last completed update. Track it, alarm on it, and publish it beside the trace services. An estate that can state its subnetwork age has turned an invisible correctness problem into an operational metric, which is the only form in which it ever gets fixed.

What Breaks Downstream When Membership Is Wrong

It is worth being concrete about who consumes a subnetwork name, because the list is longer than most estates realise and every entry inherits the same defect.

Outage management groups predicted and reported outages by circuit. A feature stamped with last month’s feeder attributes an interruption to the wrong circuit, and no amount of care in the outage system corrects it.

Load and hydraulic modelling builds its network from subnetwork membership, so a main assigned to the wrong pressure zone appears in the wrong model run and its demand is applied against the wrong source.

Switching and clearance depend on the subnetwork bounding what is de-energised. A stale membership can place a span inside a clearance that does not actually cover it, which is the failure with a safety consequence rather than a reporting one.

Rate and reliability filings aggregate customers by circuit or zone. Membership that was correct when the report ran and wrong when the event happened produces figures nobody can reconcile afterwards.

Field applications show a crew which circuit they are standing on. When the map disagrees with the tag on the pole, the crew stops trusting the map — and that loss of trust outlasts the defect that caused it by years.

What Breaks Downstream When Membership Is Wrong

It is worth being concrete about who consumes a subnetwork name, because the list is longer than most estates realise and every entry inherits the same defect.

Outage management groups predicted and reported outages by circuit. A feature stamped with last month’s feeder attributes an interruption to the wrong circuit, and no amount of care in the outage system corrects it.

Load and hydraulic modelling builds its network from subnetwork membership, so a main assigned to the wrong pressure zone appears in the wrong model run and its demand is applied against the wrong source.

Switching and clearance depend on the subnetwork bounding what is de-energised. A stale membership can place a span inside a clearance that does not actually cover it, which is the failure with a safety consequence rather than a reporting one.

Rate and reliability filings aggregate customers by circuit or zone. Membership that was correct when the report ran and wrong when the event happened produces figures nobody can reconcile afterwards.

Field applications show a crew which circuit they are standing on. When the map disagrees with the tag on the pole, the crew stops trusting the map — and that loss of trust outlasts the defect that caused it by years.

The common thread is that none of these systems can detect the problem themselves. Each one receives a subnetwork name that is well formed, in domain, and consistent with every other value around it. Only a comparison against the controllers that produced it, or against the field, distinguishes a current stamp from one that was correct a month ago — which is why subnetwork currency belongs in the monitoring layer rather than in each consumer’s assumptions.

What Breaks Downstream When Membership Is Wrong

It is worth being concrete about who consumes a subnetwork name, because the list is longer than most estates realise and every entry inherits the same defect.

Outage management groups predicted and reported outages by circuit. A feature stamped with last month’s feeder attributes an interruption to the wrong circuit, and no amount of care in the outage system corrects it.

Load and hydraulic modelling builds its network from subnetwork membership, so a main assigned to the wrong pressure zone appears in the wrong model run and its demand is applied against the wrong source.

Switching and clearance depend on the subnetwork bounding what is de-energised. A stale membership can place a span inside a clearance that does not actually cover it, which is the failure with a safety consequence rather than a reporting one.

Rate and reliability filings aggregate customers by circuit or zone. Membership that was correct when the report ran and wrong when the event happened produces figures nobody can reconcile afterwards.

Field applications show a crew which circuit they are standing on. When the map disagrees with the tag on the pole, the crew stops trusting the map — and that loss of trust outlasts the defect that caused it by years.

The common thread is that none of these systems can detect the problem themselves. Each one receives a subnetwork name that is well formed, in domain, and consistent with every other value around it. Only a comparison against the controllers that produced it, or against the field, distinguishes a current stamp from one that was correct a month ago — which is why subnetwork currency belongs in the monitoring layer rather than in each consumer’s assumptions.

What Breaks Downstream When Membership Is Wrong

It is worth being concrete about who consumes a subnetwork name, because the list is longer than most estates realise and every entry inherits the same defect.

Outage management groups predicted and reported outages by circuit. A feature stamped with last month’s feeder attributes an interruption to the wrong circuit, and no amount of care in the outage system corrects it.

Load and hydraulic modelling builds its network from subnetwork membership, so a main assigned to the wrong pressure zone appears in the wrong model run and its demand is applied against the wrong source.

Switching and clearance depend on the subnetwork bounding what is de-energised. A stale membership can place a span inside a clearance that does not actually cover it, which is the failure with a safety consequence rather than a reporting one.

Rate and reliability filings aggregate customers by circuit or zone. Membership that was correct when the report ran and wrong when the event happened produces figures nobody can reconcile afterwards.

Field applications show a crew which circuit they are standing on. When the map disagrees with the tag on the pole, the crew stops trusting the map — and that loss of trust outlasts the defect that caused it by years.

The common thread is that none of these systems can detect the problem themselves. Each one receives a subnetwork name that is well formed, in domain, and consistent with every other value around it. Only a comparison against the controllers that produced it, or against the field, distinguishes a current stamp from one that was correct a month ago — which is why subnetwork currency belongs in the monitoring layer rather than in each consumer’s assumptions.

In this section