8 min read1,766 words

Tier Definitions for Water Pressure Zones vs Electric Circuits

A tier is the least visible decision in a utility network model and one of the most expensive to revisit. It decides how subnetworks may relate to one another, which relationships the validation rules treat as defects, and what an update is entitled to assume while it walks. Choosing between a hierarchical and a partitioned tier is not a stylistic preference between two ways of drawing the same thing — the two produce different validation outcomes for the identical physical network. Model a water pressure zone hierarchically and every legitimate interconnection between zones reports as an error; model an electric feeder as partitioned and the loop detection that would have caught a genuine parallel path is switched off. This page compares the two against the questions that actually separate them, so the choice is made from the commodity’s physics before the first controller is placed, as the subnetwork management and controller configuration reference recommends.

Environment Prerequisites

  • ArcGIS Pro 3.2+ with a Standard or Advanced licence, since tier definitions are authored against the domain network and require utility network editing.
  • A domain network per commodity, already created. Tiers live inside a domain network, and a tier cannot span water and electric no matter how the estate is organised administratively.
  • The commodity’s operating diagram — the single-line diagram for electric, the pressure-zone schematic for water. The tier type is read off these, not off the data model.
  • A statement of how the network is operated, not only how it is built. Whether two sources ever run in parallel, whether zones are routinely tied, and whether loops are permitted in normal operation are operations questions, and they decide the answer.
  • A test geodatabase where a tier can be created, populated and discarded. Tier type cannot be changed in place on a populated tier, so the cheap place to be wrong is a copy.

Schema-Aware Selection Protocol — Score the Commodity Before You Author

  1. Ask whether a subnetwork can have several live sources at once. A water pressure zone fed by two pump stations is the standard case for partitioned. A distribution feeder fed by one breaker, with a second only during a transfer, is the standard case for hierarchical.
  2. Ask whether peers interconnect without nesting. Zones tied through a normally-closed valve are peers. A service that belongs to a transformer that belongs to a feeder is a nest.
  3. Decide what a loop means operationally. In electric distribution a closed loop is usually an error or a temporary parallel during switching; in a meshed water system it is the normal state. The tier type decides whether the validation agrees with you.
  4. Check whether membership is expected to change during operations. Water zones re-source as ties operate; electric feeders change membership only during switching. A tier whose membership is expected to move needs a comparison that tolerates it, which is easier to express in a partitioned tier.
  5. Confirm the propagated attributes fit the shape. Electric phase propagates cleanly down a hierarchy. Pressure zone propagates across a partition. An attribute that has to propagate across peers in a hierarchical tier is a signal the tier type is wrong.
The two tier shapes drawn side by side, and where each one puts its sources The hierarchical shape on the left has a single controller at the substation, and every subnetwork below it nests inside its parent: a service belongs to one transformer, which belongs to one feeder. The partitioned shape on the right has two pump stations feeding one pressure zone and a normally-closed tie to a neighbouring zone. Neither zone contains the other, both carry their own controller, and the tie is a legitimate interconnection rather than an error — which is exactly the case a hierarchical tier would reject. interconnection Substation controller Feeder Transformer Service Pump A controller Pump B controller Zone 3 two sources Zone 4 peer, not child Tie valve normally closed hierarchical — strict nesting partitioned — peers with ties controller subnetwork tie device The same update algorithm, two different definitions of a correct result.

The Comparison

Which tier type answers each design question correctly Five questions separate the two tier types in practice. Whether a subnetwork can have more than one source at once; whether two subnetworks may be interconnected without one containing the other; whether a loop is an error or a normal operating state; whether membership is expected to change during ordinary operations; and what the validation rules should treat as a defect. Answering these from the commodity, before any controller is placed, is what avoids a tier reorganisation later. Question Hierarchical Partitioned Several sources at once unusual — one source expected Peer interconnection through the parent only normal, through ties A loop is an error to report an operating state Membership during operations stable between switching changes as ties operate Validation flags loops, multiple parents unintended merges Answer all five from the physics before placing the first controller.

The table above is the short answer; three consequences are worth stating in full.

Validation reports the opposite things. A hierarchical tier reports a loop and a multiple-parent membership as errors, because both violate the nesting it assumes. A partitioned tier reports neither — its error is an unintended merge, two subnetworks that were not supposed to be joined arriving in the same stamped set. An estate that picked the wrong tier type spends its time either explaining away errors that are not errors or missing the ones that are.

Update behaviour differs at the sources. A hierarchical tier walks from one controller outward and expects the walk to partition cleanly. A partitioned tier walks from several controllers and has to resolve what happens where two walks meet, which is why a tie device’s state matters so much more in a partitioned model — closing it merges two subnetworks by design.

Reorganisation is not an edit. Changing tier type invalidates every subnetwork in the tier, which means re-stamping every feature and re-deriving every propagated attribute. On a production estate this is a planned outage of the operational picture, not a schema tweak, which is why the decision belongs at the start.

Choosing a tier type for a commodity The governing question is whether a subnetwork in this commodity can legitimately be fed by more than one source at the same time. Where it cannot — a distribution feeder is fed by one breaker at a time — a hierarchical tier matches the physics and its loop detection is a real safeguard. Where it can, as with a pressure zone fed by two pump stations, a partitioned tier is the only honest model, and forcing a hierarchy on it produces validation errors for the network operating exactly as designed. Can one subnetwork have several live sources at once? no — one source at a time Hierarchical tier benefit Loop detection is a genuine safeguard caveat Model temporary parallels as switching, not structure yes — by design Partitioned tier benefit Ties between peers are normal, not errors caveat Unintended merges become the thing to validate Changing tier type later invalidates every subnetwork inside it.

Worked Selection: Two Commodities, One Estate

A combined utility running water and electric will normally end up with both tier types in the same geodatabase, and that is correct rather than inconsistent.

Electric distribution gets a hierarchical tier. The substation breaker is the controller, the feeder nests the laterals, and the laterals nest the services. Loop detection is switched on and means something: a closed loop that was not part of an authorised switching operation is a protection concern before it is a data concern. Temporary parallels during a transfer are modelled as switching states, not as structure — the tier does not have to represent them because they do not persist.

Water distribution gets a partitioned tier. Each pressure zone is a subnetwork with its own controller at the pump station or regulator outlet, zones interconnect through normally-closed ties, and a zone with two sources is ordinary. The validation is tuned to detect merges: if opening a tie brings two zones into one stamped set outside a planned operation, that is the finding worth raising, because it usually means a valve is in the wrong position.

Gas frequently needs both, one per pressure class, and this is where estates most often get it wrong. The tell is usually organisational rather than technical: transmission and distribution are operated by different groups with different diagrams, and the model ends up reflecting whichever group was in the room when the schema was authored. Ask both groups the five questions above separately, and where their answers differ, that difference is the tier boundary. Transmission behaves hierarchically from the city gate; distribution below the regulator stations often behaves as partitioned zones. Modelling both as one tier collapses the pressure classes into a single subnetwork and destroys exactly the distinction the operators care about.

Conclusion

The tier type is a statement about how the commodity is operated, not about how the data is stored, and it is read off the operating diagram rather than the schema. Hierarchical tiers buy loop detection and clean nesting at the cost of rejecting legitimate multi-source operation; partitioned tiers accept peers and ties at the cost of needing merge detection instead. Getting it right at authoring time costs one conversation with operations; getting it wrong costs a re-stamp of the whole tier later, together with the re-derivation of every propagated attribute that hangs off it and a period during which the operational picture cannot be trusted. Once the tier is settled, the controllers can be placed against it — and kept honest afterwards by the controller drift comparison.

For authoritative reference, consult the ArcGIS Pro tier documentation and the AWWA distribution system standards.

Related pages