9 min read1,981 words

Terminal Configuration Reference for Electric Devices

Terminals are the least visible part of a utility network model and the part that decides most trace outcomes. A device’s terminal configuration says how many connection points it exposes, what they are called, and which pairs of them are internally connected. Every connectivity rule is written against those names, every trace enters and leaves through them, and a device configured with too few terminals removes a path from the network without raising anything. This page is the reference table for the common electric device classes, together with the audit that finds devices whose configuration does not match the class they belong to. It supports the rule authoring described in configuring connectivity rules for pipe and cable.

Environment Prerequisites

  • ArcGIS Pro 3.2+ with a Standard or Advanced licence and arcpy importable from Python 3.11, so terminal configurations and association counts can be read from the schema.
  • The deployed asset package, because terminal configuration names are defined by the data model in use and the table below follows common conventions rather than a universal standard.
  • A validated topology, so the association counts the audit reads reflect the built network rather than a pending edit.
  • The engineering device catalogue, which is where the expected terminal count for each device class actually comes from — the model should follow the equipment, not the other way round.
  • A reconciled snapshot for the audit read, so a live edit is not reported as a defect.

Schema Validation Protocol — Run Before Trusting the Reference

  1. Export the deployed terminal configurations and compare names. A configuration named Source/Load in one asset package and Line/Load in another means every rule written against the wrong name silently matches nothing.
  2. Confirm the terminal count matches the physical device. A three-way switch mapped as two-terminal is the single most common terminal defect and it removes a branch from every trace.
  3. Check internal connectivity pairs on multi-terminal devices. A transformer’s high and low windings are not a pass-through, and a configuration that models them as one collapses the voltage step.
  4. Verify that each rule references terminals the asset type actually has. An orphan terminal reference in a rule is a rule that can never match.
  5. Sample real devices and count their associations. The configuration is a permission; the associations are what exists. Both matter, and they disagree more often than expected.

The Reference Table

Terminal configurations by electric device class, with the trace behaviour each implies Terminal count and naming decide which associations a device may hold and how a trace enters and leaves it. A single-terminal device is a dead end by construction. A two-terminal device has a defined upstream and downstream side. A three-terminal regulator or a four-terminal switch expresses positions that a trace must respect, and mapping one with too few terminals silently removes a path. Device class Terminals Names Trace behaviour Service point 1 Line terminates the walk Fuse / cutout 2 Line / Load barrier when open Sectionalising switch 2 Source / Load barrier when open Voltage regulator 3 Source / Load / Bypass bypass path is traversable Three-way switch 3 Common / A / B position decides the path Transformer (two-winding) 4 HV1 / HV2 / LV1 / LV2 winding pairs, not a pass-through Every row is a contract between the device model and every trace that meets it.

Three notes on reading the table. Names vary by data model — the counts and the behaviour are what transfer between estates, not the strings. A barrier is a device state, not a terminal property: a two-terminal switch is traversable when closed and a barrier when open, and the terminal model is what lets the trace know which side it is entering from. And a transformer is not a pass-through: modelling it as one produces a trace that walks from the high-voltage network straight into the low-voltage one, which is exactly the phantom propagation the upstream and downstream tracing diagnostics look for.

The same three-way switch modelled with two terminals and with three On the left the switch carries two terminals, so the model can express only one path through it and the branch to feeder B disappears from every trace. On the right the same device carries a common terminal and two switched terminals, and the trace can follow whichever position the device reports. The physical device is identical; the difference is entirely in the terminal model. no terminal to hold it position B Feeder A Switch 2 terminals Load Feeder B unreachable Feeder A Switch 3 terminals Load Feeder B selectable traversable lost to the model Under-modelled terminals do not raise an error; they remove a path.

Auditing Terminal Configuration Against Reality

from __future__ import annotations

import logging
from dataclasses import dataclass, field

import arcpy

logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s")
LOG = logging.getLogger("terminal-audit")

# Expected terminal count per device class, taken from the engineering catalogue.
EXPECTED = {
    "ServicePoint": 1, "Fuse": 2, "SectionalisingSwitch": 2,
    "VoltageRegulator": 3, "ThreeWaySwitch": 3, "Transformer": 4,
}


@dataclass
class TerminalFinding:
    asset_type: str
    global_id: str
    kind: str          # CONFIG_MISMATCH, UNDER_CONNECTED, IMPOSSIBLE
    detail: str


@dataclass
class AuditReport:
    findings: list[TerminalFinding] = field(default_factory=list)
    devices: int = 0

    @property
    def ok(self) -> bool:
        return not self.findings


def audit_terminals(un_path: str, device_class: str,
                    association_counts: dict[str, int]) -> AuditReport:
    """Compare assigned terminal configurations against the class reference.

    ``association_counts`` maps a device global id to the number of connectivity
    associations it currently holds, read separately so this function stays testable
    without a live geodatabase.
    """
    report = AuditReport()
    expected = EXPECTED.get(device_class)
    if expected is None:
        report.findings.append(TerminalFinding(
            device_class, "", "CONFIG_MISMATCH", "no expected terminal count for this class"))
        return report

    fields = ["GLOBALID", "ASSETTYPE", "TERMINALCONFIGURATION"]
    with arcpy.da.SearchCursor(f"{un_path}/{device_class}", fields) as cursor:
        for global_id, asset_type, config in cursor:
            report.devices += 1
            terminals = int(config or 0)

            if terminals != expected:
                report.findings.append(TerminalFinding(
                    str(asset_type), str(global_id), "CONFIG_MISMATCH",
                    f"configured with {terminals} terminal(s), class expects {expected}"))
                continue

            held = association_counts.get(str(global_id), 0)
            if held > terminals:
                report.findings.append(TerminalFinding(
                    str(asset_type), str(global_id), "IMPOSSIBLE",
                    f"{held} associations on {terminals} terminal(s)"))
            elif held < terminals - 1:
                report.findings.append(TerminalFinding(
                    str(asset_type), str(global_id), "UNDER_CONNECTED",
                    f"{held} association(s) on a {terminals}-terminal device"))

    LOG.info("%s: %d device(s), %d finding(s)", device_class, report.devices,
             len(report.findings))
    return report
Auditing an estate’s terminal configurations against its device classes The audit reads the assigned terminal configuration per asset type, compares it against the reference for that device class, and counts the associations each device actually holds. A device holding fewer associations than it has terminals is either genuinely unused or missing a connection; one holding more than its configuration allows is a schema error that should have been impossible. READ terminal config per asset type COMPARE against the class reference COUNT associations held per device CLASSIFY unused, missing, or impossible Three findings, and only one of them is a data problem rather than a schema one.

The UNDER_CONNECTED threshold allows one unused terminal deliberately. A three-way switch with a spare position and a regulator with an unused bypass are both normal; a three-terminal device holding one association is not, and that is the case worth a ticket.

Where Terminal Defects Come From

Terminal configurations are rarely wrong at random; four origins account for almost all of them, and knowing which one produced a finding decides who fixes it.

The asset package default. A device class created from a template inherits whatever terminal configuration the template carried, which is usually the two-terminal case because it is the most common. Every three- and four-terminal class then has to be corrected deliberately, and the ones nobody thought about stay wrong.

A migration from a geometric network. The source model had no terminals at all, so the migration assigned a default. The result validates cleanly and traces as though every device were a simple pass-through.

A rule authored against a guessed name. Terminal names differ between data models, and a rule written for Source/Load against a schema using Line/Load matches nothing. The device is configured correctly and no connection is ever permitted through it.

An equipment change the model never learned about. A two-terminal switch replaced in the field by a three-way unit is a common upgrade, and unless the work order carries the class change, the model keeps the old configuration and loses the new position.

The first two are found by the audit; the third is found by counting rules that never match; the fourth is only found by reconciling against the work-management record, which is one more reason the CMMS integration matters to the network model and not only to maintenance.

Production Deployment Pattern

  1. Run the audit per device class on a schedule, against a reconciled snapshot, and route findings by kind: configuration mismatches to schema owners, under-connected devices to data maintenance.
  2. Treat IMPOSSIBLE findings as urgent. More associations than terminals means the schema permitted something it should not have, and every trace through that device is suspect.
  3. Keep the expected-count table with the connectivity rules. They are the same body of configuration and they drift together.
  4. Re-audit after every asset package upgrade. Terminal configuration names and defaults change between data-model versions, and a rule written against the old name matches nothing after the upgrade.
  5. Publish the reference to the people authoring rules. Most terminal defects originate in a rule authored against a guessed terminal name, and a table on a page is cheaper than a defect in production.

Conclusion

Terminal configuration is a small piece of schema that decides whether a trace can express the network’s real topology. Auditing the assigned configuration against the engineering catalogue finds the devices that were modelled with too few connection points, and counting associations against the configuration finds the ones that were configured correctly and connected wrongly. Both classes of defect are silent, both remove or invent paths, and both are cheap to detect once the expected counts are written down.

For authoritative reference, consult the ArcGIS Pro terminal configuration documentation and the IEEE standards catalogue.

Related pages