8 min read1,691 words

Isolation Trace vs Subnetwork Trace: Choosing the Right One

Both traces start from a location and return a set of features, which is why they are so often substituted for one another. They answer different questions. An isolation trace asks what has to be operated to disconnect this location from every source, and its answer is a list of devices somebody will physically turn. A subnetwork trace asks what belongs to this circuit or zone, and its answer is a membership list stamped by the last subnetwork update. Using the membership list to plan a shutoff returns features nobody can operate and misses the operable devices that actually bound the work. Using an isolation set as an inventory understates the circuit. This guide sets out the distinction, the inputs each depends on, and how to choose from the decision the result will drive. It builds on upstream and downstream tracing algorithms.

Environment Prerequisites

  • A validated topology with no outstanding dirty areas in the trace extent, because both traces are only as good as the graph beneath them.
  • A current barrier overlay for isolation work — device states no older than the operational policy allows, per syncing SCADA barriers to valve state.
  • An updated subnetwork tier for membership work, with the last-updated timestamp readable so staleness can be reported rather than assumed.
  • Operability attribution on isolation devices: a valve that is open and seized is not a barrier a crew can use.
  • ArcGIS Pro 3.2+ with a Standard or Advanced licence for the rule-aware engine, or an exported graph where the work is analytic.

Selection Protocol — Score the Question Before Choosing the Trace

  1. Ask whether a device will be operated. If yes, only an isolation trace is admissible, and it must consult live state.
  2. Ask what the consumer does with the result. A count, a report, or a map layer wants membership; a work order wants devices.
  3. Ask how stable the answer must be. Membership changes only when the subnetwork is updated; an isolation set changes every time a device is operated.
  4. Ask what the cost of being wrong is. An over-large membership list is a reporting inaccuracy; an incomplete isolation set is a safety event.
  5. Ask whether the barrier overlay is current. If it is not, an isolation trace must decline rather than answer, and the caller should be told why.
Isolation trace against subnetwork trace, on the five questions that separate them The two traces answer different questions and are frequently substituted for one another because both return a set of features around a point of interest. An isolation trace finds the smallest set of operable devices that disconnects a location from every source. A subnetwork trace returns everything that belongs to a subnetwork as currently stamped. Using the second where the first is required returns a set that is both too large and not actionable. Property Isolation trace Subnetwork trace Question answered what must be closed? what belongs to this circuit? Depends on live barrier state the last subnetwork update Device state must be current not consulted Result a set of devices to operate a set of member features Typical use shutoff, clearance reporting, membership One returns an action; the other returns an inventory.

What Each Trace Actually Does

An isolation trace walks outward from the location in every direction, stopping at each operable device it can reach, and returns the minimal set whose closure disconnects the location from every source. Its correctness depends on three things: the graph, the live state of every device it considered, and the operability flag that says whether a device can actually be turned. Any of the three being wrong produces a set that is confidently incomplete — which is the failure mode with a crew standing on the other end of it.

A subnetwork trace returns the features stamped with a subnetwork name by the last update. It does not walk device states at all, which is exactly why it is stable and why it must never be used to plan a shutoff. Its correctness depends on the update being current, and its failure mode is stale membership rather than a wrong action — a reporting error rather than a safety one.

The same location traced both ways, and why the answers differ A subnetwork trace from the marked main returns every feature stamped with that circuit, including the span beyond the open tie that is currently fed from elsewhere. An isolation trace returns the two closed-able valves that bound the location and nothing else. The first answer is right for a report and useless for a crew; the second is right for a crew and incomplete as an inventory. not fed from here Source V-1 closeable ! Work site V-2 closeable Far span same subnetwork Open tie other source isolation result subnetwork member Two correct answers to two different questions about one location.

Using Both Together

Most real workflows need both, sequenced. Impact analysis starts with a subnetwork trace to establish who is on the circuit and follows with an isolation trace to establish what has to be operated. A clearance package quotes the isolation set as the devices to operate and the subnetwork membership as the extent of the affected circuit, and the two together are what a switching order needs.

The discipline that keeps this honest is labelling. Every published result should say which trace produced it, against which barrier-overlay time, and against which subnetwork update. A result carrying both timestamps can be judged; one carrying neither will eventually be used for the wrong purpose by someone who assumed it meant the other thing.

Choosing the trace from the decision it will drive The governing question is whether someone will operate a device as a result. If they will, the trace must consult live barrier state and must return operable devices, which is an isolation trace. If the output is a count, a report or a membership list, a subnetwork trace is both cheaper and more stable, because it does not move every time a device is operated. Will someone operate a device because of this result? yes — it drives an action Isolation trace, live state output Returns the devices to operate, in order rule Refuse to answer on a stale barrier overlay no — it is a count or a list Subnetwork trace, stamped membership benefit Stable between switching operations caveat As current as the last subnetwork update The output shape follows from the decision, not from which API is nearer to hand.

The Substitution That Causes Incidents

The failure worth naming explicitly is using subnetwork membership to plan a shutoff, because it happens for an understandable reason: the membership list is always available, always fast, and never refuses to answer. The isolation trace, done properly, sometimes declines because the barrier overlay is stale — and a system that occasionally declines is less convenient than one that always answers.

What the membership list omits is the thing the crew needs. It contains every feature stamped with the circuit, including spans currently fed from elsewhere through a closed tie, and it contains no information about which devices can actually be operated. A crew given that list has an extent and no instruction. Worse, the extent is wrong in the dangerous direction whenever a tie has been operated since the last subnetwork update: features that are currently live still carry the circuit name they had before the transfer.

The reverse substitution is safer and still wrong. Using an isolation set as an inventory understates the circuit, because it stops at the first operable device in every direction. A count built from it will be smaller than reality, and a report built on that count will be quietly inconsistent with the one built from membership.

The practical defence is at the interface rather than in the algorithm: name the endpoints for the question rather than for the mechanism, so a caller looking for “what do we close” cannot reach the membership list by accident.

Production Deployment Pattern

  1. Expose them as two endpoints, not one with a flag. A single endpoint with a mode parameter invites the caller to pick the default, and the default will be wrong for half the callers.
  2. Refuse an isolation trace on a stale overlay. Return an explicit error naming the overlay age rather than an answer nobody can evaluate.
  3. Stamp both timestamps on every result — the barrier overlay time and the subnetwork update time — even when only one is relevant, so a consumer can tell which trace it received.
  4. Cache subnetwork results, never isolation results. Membership is stable between updates; an isolation set is invalidated by the next device operation.
  5. Test both against the certification network. The isolation set and the membership list for a hand-verified feeder are the regression baseline that catches an engine or rule change.

Conclusion

The two traces differ in what they consult, what they return and what it costs to be wrong. An isolation trace consults live device state and returns an action; a subnetwork trace consults the last update and returns an inventory. Choosing from the decision the result will drive — will somebody operate a device? — settles it in one question, and stamping both timestamps on every published result keeps the distinction visible to whoever reads it next.

For authoritative reference, consult the ArcGIS Pro trace types documentation and the NetworkX traversal reference.

Related pages