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.

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.

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.
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.

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.

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