OSIsoft PI (now AVEVA PI System) is the de facto historian standard in North American utilities. If you are a reliability engineer at an IOU, there is a high probability that the PI infrastructure already exists and has been running for 10–20 years. The tag tree reflects decades of organic growth — substation IEDs, SCADA masters, DCS integrations, AMI concentrators. The question for distribution field asset telemetry is not whether to use PI; it is how to bring the new telemetry in cleanly without creating tag debt that becomes unmaintainable.
This post covers the specific decisions that come up when integrating distribution transformer, recloser, and voltage regulator telemetry into an existing PI environment: tag naming conventions, compression settings that preserve anomaly-detection signal quality, and how to structure PI Asset Framework (PI AF) elements so the telemetry is queryable in context rather than as a flat list of raw tags.
Tag Naming: What Works at Scale
Tag naming in PI is irreversible in the sense that once tags are being written and consumed by downstream processes (PI AF templates, PI Vision displays, PI Notifications, third-party analytics tools), renaming them requires coordinating every consuming system. Getting the naming convention right before you have several thousand tags in production is worth the time.
For distribution field asset telemetry, the naming pattern that scales best follows the hierarchy: territory.feeder.asset-id.measurement-type.qualifier. Each segment carries specific meaning:
- territory: The operating territory or district code (e.g.,
HOUfor Houston district) - feeder: The feeder identifier as it appears in the GIS system (e.g.,
T41N_F12) - asset-id: The unique asset identifier from the asset management system (GIS object ID or SAP functional location), not a descriptive name
- measurement-type: The physical quantity (
vib_120hz_rms,top_oil_temp_c,load_kva,ambient_temp_c) - qualifier: Channel or axis identifier where needed (
ph1,ph2,ph3,axial,radial)
A complete example: HOU.T41N_F12.TX-0047821.vib_120hz_rms.tank_north. This is verbose, but verbosity is the right tradeoff for tags that will exist for decades and be queried by engineers who were not involved in the original deployment.
The mistake to avoid is using installation address or customer account identifiers in tag names. Addresses change; asset GIS IDs do not. Customer accounts are private information that should not appear in an OT historian tag tree. Use the GIS object identifier as the asset anchor.
Compression Settings: The Anomaly Detection Trade-off
PI's compression algorithm (deadband compression) is designed to reduce data storage by discarding data points that fall within a defined deviation band from a linearly interpolated value between stored points. This works well for slowly varying signals like oil temperature — a 1°C deadband on a temperature tag might reduce stored data points by 80% with negligible impact on trend fidelity.
For vibration spectral features, the compression interaction is more nuanced. Vibration at 120 Hz amplitude changes meaningfully over hours as loading varies, and the anomaly signal you are trying to preserve is typically a 5–15% deviation from the load-conditioned baseline. If the compression deadband is set too aggressively (e.g., 20% of engineering range), the compression algorithm may swallow the anomaly signal entirely, particularly for low-amplitude transitions early in a fault development sequence.
The practical guideline for vibration feature tags destined for anomaly detection use: set compression deviation to 2–5% of the expected signal range, and set the exception deviation to 10% of the same range. PI's exception reporting (which filters data before it reaches the compression algorithm) should be disabled for anomaly-detection-critical tags, or set with a very permissive exception filter. The storage cost of less compression on a few hundred vibration tags is negligible compared to the consequence of losing the signal that the anomaly model depends on.
For temperature and load tags, standard compression settings are appropriate. A 1–2% deadband on temperature tags and a 2–3% deadband on kVA load tags preserves adequate fidelity for thermal aging calculations and load analysis without excessive storage overhead.
PI AF Structure for Distribution Asset Context
Raw PI tags contain no asset context — they are identified by their tag name and nothing else. PI Asset Framework (PI AF) adds the asset model layer: elements representing physical assets, with attributes that reference PI tags and carry metadata (manufacturer, installation year, kVA rating, GPS coordinates, feeder assignment). This is the layer that makes the historian useful for asset management rather than just data archiving.
For distribution transformer telemetry, the recommended AF structure creates an element hierarchy that mirrors the distribution topology: service territory → operating district → feeder → individual asset. Each transformer element carries attributes for:
- Referenced PI tags for all measurement streams (vibration features, temperature, load)
- Static metadata from the GIS and asset management system (manufacturer, model, kVA, installation year, voltage class, last inspection date)
- Calculated attributes for derived values (loading percentage relative to nameplate, hot-spot temperature estimate, loss-of-life accumulation rate)
- The anomaly flag value written back from the condition monitoring platform
The calculated attributes can use PI AF formula templates to perform the loading percentage and thermal calculations directly in PI AF, without requiring a separate application to run these calculations. The IEEE C57.91 thermal model is expressible as a PI AF formula, though the maintenance burden of keeping the formula accurate as the transformer fleet changes means some organizations prefer to have the condition monitoring platform perform these calculations and write the result as a PI tag rather than implementing the formula natively in AF.
A Concrete Setup Scenario
A distribution reliability engineering team deploying Fieldiq monitoring on 450 transformers across four feeders in a suburban Texas territory connected the monitoring platform to their existing PI System via an OPC-UA server running in the OT DMZ. The OPC-UA server writes 12 tags per transformer (six vibration spectral features, two temperature channels, load current per phase, and the anomaly flag and confidence value) — approximately 5,400 net new tags added to the PI server.
With a 4% compression deviation on vibration feature tags and standard compression on temperature and load tags, the incremental data growth rate was approximately 35 MB per day for all 450 assets combined — a negligible addition to a PI server already handling gigabytes per day from the larger substation and AMI telemetry streams.
The PI AF element tree was populated using a batch import from the utility's GIS export, creating transformer elements with static metadata pre-populated before the first telemetry arrived. When the monitoring data began flowing, the calculated attributes for loading percentage and thermal model output were immediately operational because the static metadata (kVA nameplate, thermal rating, ambient design temperature) was already in place.
Retrieval Patterns for Anomaly Analysis
The retrieval pattern that matters most for anomaly analysis work is time-aligned retrieval of multiple tags for the same asset over a sliding window — the last 30 days of vibration, temperature, and load data for a specific transformer, time-synchronized so the values can be analyzed in their operating context. PI's interpolated value retrieval with a consistent time step (e.g., 15-minute intervals) is the appropriate call for this use case rather than compressed value retrieval, which may not produce consistent timestamps across different tags.
For fleet-level queries — "show me all transformers where the anomaly flag value is above 0.7 in the last 24 hours" — PI AF queries against the anomaly flag attribute across the element tree are more efficient than tag searches. This is the argument for writing anomaly flag values to PI as tag-referenced attributes on AF elements rather than as standalone tags: the asset context is immediately available in the query result without a secondary lookup step.
The worst retrieval antipattern we see in distribution telemetry deployments is using PI via OPC-DA polling for real-time dashboards of field asset telemetry. OPC-DA poll rates that are appropriate for real-time SCADA HMI use (1–5 second scan) create unnecessary load on both the PI server and the OPC-DA server when the underlying telemetry is updating at 15-minute intervals. The right interface for real-time dashboard updates of slowly varying field asset data is PI AF WebAPI with server-side event subscription — it pushes updates when values change rather than polling at fixed intervals.
