TL; DR: We are automating voltage transformer (VT) maintenance by linking CIM model context with time series analysis and lightweight apps. In the future we expect fewer manual site checks, earlier detection of issues, and continuous visibility across substations—without changing field equipment.


Introduction

Operating a national power system means managing one of the most complex machines ever built. In Norway, this machine spans thousands of components distributed across the entire grid, each contributing to a stable and reliable electricity supply. The scale is enormous, and so is the responsibility: when everything is interconnected, a failure in one place can have consequences beyond a single station or region. This makes systematic maintenance a critical part of everyday operations.

Figure 1. A sketch of a voltage transformer device (generated using Copilot Create tool).

Among the many devices that require regular follow-up is the voltage transformer (VT, Figure 1). Voltage transformers are typically connected to high-voltage equipment such as lines, busbars, or breakers. Their role is to scale the system voltage to standardized – usually much lower – levels that can be safely used by protection, control, and measurement systems. VTs do not handle power transfer; they provide precise voltage signals to the equipment that depends on them. Because protection and automation functions rely on accurate inputs, deviation in VT behavior can lead to false alarms, incorrect decisions, or, in the worst cases, damaged equipment.

Figure 2. A table mimicking the operator screen. Columns correspond to voltage transformers connected to a—in this case—line; rows show either line-to-line values (top row) or line-to-neutral values. Readings are grouped by nominal voltage.

For these reasons, monitoring the condition of voltage transformers is essential. Today, however, the maintenance workflow is still largely manual. On a regular schedule, technicians visit substations, read values directly from the operator screen (Figure 2), calculate the maximum phase differences for each row, and compare them against the allowed threshold. If the deviation exceeds the limit, the device is reported for further inspection. The procedure itself is simple, but it is also repetitive, time-consuming, and vulnerable to human error. Across all substations, this results in approximately 10,000 manual checks per year, each providing only a single snapshot in time. There is no continuous monitoring, and emerging problems can remain unnoticed until the next scheduled visit.

This creates a clear need for automating the process: to reduce operational costs, minimize manual work, and provide earlier and more reliable detection of potential issues.

Design goals

  • Reduce repetitive manual work without adding field complexity
  • Reduce the risk of power outages by avoiding unnecessary or intrusive testing
  • Reduce HSE risk by enabling condition‑based maintenance instead of manual preventive actions
  • Provide continuous visibility, not point in time snapshots
  • Make investigations faster when anomalies appear
  • Keep the stack lightweight and easy to run in existing infrastructure

How we are automating the maintenance process

1) Map each VT to its operational context

We use the Common Information Model (CIM) — an IEC standard that defines how to describe grid equipment and how those pieces connect. In practice, we represent it as a graph: devices and connection points are nodes; their relationships are links. The model covers hundreds of thousands of devices across substations and voltage levels. CIM doesn’t replace field reality; it provides a consistent structure and vocabulary so different tools can refer to equipment and connections in the same way.

For this work, CIM lets us quickly and reliably determine, for each VT:

  • Where it is: the substation and voltage level.
  • What it’s attached to: line, breaker, power transformer, etc.
  • Who is responsible: the owning/operating organization (i.e., who maintains it).
  • How to assess it: nominal voltage, phase designation, and whether measurements are per-phase or averaged line-to-line.

Because model paths differ by equipment type (e.g., an AC line vs. a power transformer vs. a breaker), we implemented case-specific traversals to attach each VT correctly to its equipment and station context. This ensures ownership, that thresholds are applied correctly, and that issues are routed to the right place.

2) Normalize the measurement basis (line-to-line → phase)

Some VTs report voltage between two wires (line-to-line, e.g., A–B). Others report the voltage for a single wire relative to neutral (line-to-neutral, e.g., A–N). To make an apples-to-apples comparison across devices, we convert everything to the same scale: line-to-neutral.

VLineToNeutral=VLineToLine3V_{Line ToNeutral}=\frac{V_{LineToLine}}{\sqrt3}

In a standard three-phase system, the line-to-neutral magnitude equals the line-to-line magnitude divided by √3. We compare magnitudes only, so the 30° angle difference between line-to-line and line-to-neutral doesn’t affect the threshold check.

Importantly, this conversion is usually not performed during today’s manual checks. By standardizing values to per-phase magnitudes, the automated workflow not only makes thresholds consistent across devices and phases, it also enriches the dataset—enabling fair cross-device comparisons and more reliable alerts.

3) Time series + data quality, aggregated to daily

This is the essence of the approach: without reliable time-series data, any threshold check or trend detection would be impossible.

For each VT, we fetch:

  • Voltage time-series, and
  • Data-quality flags

We aggregate to daily values to smooth noise and make slow drifts visible, while preserving operational relevance for threshold checks. A practical benefit is that the interactive app remains responsive even when querying the last four years of data. The trade-off is that averaging can introduce artefacts on days with partial operation (e.g., when a VT was active for only half a day), which can bias the daily value. We are planning to mitigate this in the future iterations with more flexible aggregation.

4) Two lightweight applications (on OpenShift)

To support both deep investigation and system-wide monitoring, we built two lightweight apps. We chose tools that let us move fast, keep effort low, and still be “good enough” for a prototype/pilot.

a) Interactive app (Streamlit) — investigate trends and cases

Purpose: a fast, interactive workspace for exploring signals over time.

Figure 3. Voltage-transformer dashboard (Streamlit) for a small substation. The table replicates the operator screen at the substation but also includes the responsible organization (“participant”) and the calculated maximum phase difference. If the maximum difference exceeds the threshold, the exceedance is highlighted, and the min/max cells are color-coded to help locate the contributing values. Data has been anonymized for confidentiality.

Functionality of the interactive app:

  • Select a substation to see all VTs at that site
  • Explore interactive charts (Plotly) with up to 4 years of history for each VT
  • Inspect phase differences and threshold breaches

Figure 3 shows a view of the interactive app for a small substation.

Why Streamlit for the prototype?

  • Fast to build: pure Python—no front-end boilerplate
  • Good enough UI: forms, filters, and Plotly integration out of the box
  • Low overhead: easy to containerize and run on OpenShift
  • Easy to evolve: if needed, we can later port core logic to a different UI with minimal rework

b) Scheduled screening (cron job) — monitor everything, frequently

Purpose: an automated sweep that surfaces problems early—without manual effort.

Figure 4. Summary of logs where voltage values are above threshold for the latest successful run of a cron job. Data is either anonymized or fake due to confidentiality.

Functionality of the cron job workflow:

  • Runs automatically on a schedule (more often than manual checks)
  • Scans all VTs, grouped by substation and voltage level
  • Logs issues: max phase difference above threshold, model inconsistencies (e.g., duplicate names)
  • Feeds two dashboards: an overview of cases where voltage values are above threshold (Figure 4) and an overview of potential errors in CIM model or failures of cron job
  • Sends summary emails to selected recipients

Why a cron job for screening?

  • Simple & predictable: dead-easy scheduling with clear run boundaries
  • Fleet-first: scales to all sites without complex orchestration
  • Operationally friendly: logs and alerts are easy to wire up

Together, these tools cover both modes of work: focused deep-dives when something looks off, and continuous, system-wide monitoring to surface issues early—plus a tight feedback loop (screening flags → browser investigates).


What’s next?

This is an early prototype. First version of the app was built in roughly a single work-week for one person. Hardening it for production will take more engineering, but even at this stage, the prototype reduces repetitive work and extends coverage beyond point-in-time checks.

Next, we’ll run a pilot on selected substations. If results hold, we’ll scale to additional sites while iteratively improving the app. We also plan to add pre-threshold warnings: when a VT trends toward a limit, the system will flag it before the breach. This will let us act early when needed.


From ~10,000 manual snapshots to continuous insight—fewer site visits, faster detection, a safer grid.

This work is carried out under NorwAI (see: https://www.ntnu.edu/norwai).
The text was prepared with the help of GPT-5.2.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trending

Discover more from Data Science @ Statnett

Subscribe now to keep reading and get access to the full archive.

Continue reading