Predictive maintenance of power grids: why forecasting does not save the day
At the majority of substations, telemetry is already being collected: temperature, partial discharge, vibration, and current sensors reliably transmit data, and trip thresholds are configured. Yet sudden outages continue, and this is usually attributed to a lack of measurements. In practice, the reason is different.
Threshold protection catches a defect once it has already developed: the trip occurs at the threshold of failure, not hours before it.
The flip side is false trips of protection during transients and interference; the dispatcher gets used to noisy alarms and over time responds to them less and less often.
Diagnostics of substation equipment rests not on sensors but on processing logic.
Measurement channels exist separately, the trend for each is not correlated with the others, the thermal picture of a unit is not assembled into an overall degradation picture, and remaining useful life is not estimated at all — there is only "normal" and "emergency."
The key shift is moving from threshold to dynamics.
The model compares the rate of change of parameters with the current operating mode, compares a unit with its own history, and instead of a "threshold exceeded" signal produces an estimate of remaining useful life with a window in which repair can still fit into the plan.
This is exactly how predictive maintenance of power grids works: not reaction to an accident, but planning work based on condition. Below we break down how this is assembled — from raw measurements to a justified decision to take equipment out for repair.
What predictive equipment condition monitoring provides
Predictive monitoring changes the very logic of maintenance: decisions are made based on the actual condition of the unit, not on the calendar.
Transformer condition monitoring is built on continuous reading of parameters — winding and oil temperature, partial discharge, dissolved gas composition, vibration, current load.
The model compares the current profile with history and with the behavior of known-good units of the same type.
The reference value here is equipment operating hours, not service life. Insulation degradation is uneven: it is accelerated by overloads, heating and cooling cycles, oil quality, and cooling conditions.
Therefore, equipment failure prediction is built on the rate of change of signs, not on threshold tripping — the trend is visible weeks before the parameter exceeds the setpoint.
In measurable terms, it looks like this. The share of prevented failures grows: some defects are caught at the development stage rather than at the moment of failure. An entire class of failures with instantaneous winding damage disappears from the statistics.
Repair preparation time is reduced — the request goes out with an already known list of units, materials, and required crew qualifications, rather than being clarified on site.
Planned preventive maintenance becomes condition-dependent: the overhaul interval is extended for healthy units and shortened where the rate of degradation is increasing.
This fits into the asset management framework according to ISO 55000 — with documented criteria instead of "crew experience." Below we break down how this is arranged at the level of data and control loops.
Monitoring modes: from setpoints to remaining useful life estimation
Monitoring modes differ not by sensors but by the question they answer. A threshold setpoint reports whether a value has crossed a boundary; a degradation model reports how much life remains until failure.
Between them lie periodic measurements: they provide a snapshot of condition but do not show how a defect developed between rounds.
The mode is chosen based on two factors: the cost of a missed failure and the rate of defect development. Where a unit degrades over months, infrequent but in-depth diagnostics are sufficient; where destruction occurs within hours, a continuous data stream is needed.
What to choose for the task
| Mode | When appropriate | What limits it |
|---|---|---|
| Threshold setpoints | Simple units, few sensors, need fast protection | Trips on an already developed failure, threshold is configured manually and falsely trips during transient modes |
| Periodic vibration monitoring | Rotating equipment: pumps, motors, fans | Between rounds, the defect grows unnoticed; the result depends on load at the time of measurement |
| Thermal imaging monitoring | Contact connections and switchgear under load | Access and load are required; the defect is visible only after heat appears |
| Online monitoring with remaining useful life estimation | Critical units where downtime is expensive and the defect develops quickly | More expensive in sensors and communication channels; requires failure labeling and regular validation of the model on new data |
In practice, modes are combined: setpoints act as fast protection, periodic checks as diagnostics, and the remaining useful life model as the basis for planned withdrawal for repair.
We verify defect signs and the threshold methodology against ISO 17359 and record them in the configuration so that the mode can be changed without rewriting the system.
Stages of implementing a monitoring system at a facility
Work proceeds from the facility to the model, not the other way around: until there are labeled accidents and confirmed monitoring points, tuning models produces beautiful metrics and zero benefit in the control room.
Therefore, predictive maintenance of power grids starts with an inventory, and algorithms appear only after it.
- Energy facility audit. We visit substations and grid sections, record equipment composition, operating modes, and failure history. We verify what is already captured in telemetry: relay protection archives, operator logs, repair records.
- Sensor placement plan. We determine where monitoring provides an early signal and where it duplicates existing measurements. The output is installation points, sensor types, and data transmission channels.
- Data collection and labeling. We consolidate archives into a single history, link events to equipment, and label pre-failure states — otherwise the model cannot distinguish an accident from a planned switching operation.
- Model tuning. We train anomaly detectors and remaining useful life forecasts for specific equipment. We set thresholds so that the signal arrives with enough lead time for a decision.
- Validation on historical data. We run the model on past accidents and see how many hours before failure it warns and how many false positives it produces.
- Handover to operation. We hand over the regulations, thresholds, instructions for dispatchers, and a trained team. After launch, we support the system and adjust the model with new data.
Set of documentation, configurations, and regulations
After handover, you are left not with a presentation but with a working set: documentation, configurations, and regulations that allow the system to be maintained without us.
The set is designed for two readers — the engineer who keeps the infrastructure running and the dispatcher shift that works with forecasts every day.
- Integration scheme — telemetry collection points, exchange formats, polling period, behavior when a channel breaks, and backfilling of accumulated data after communication is restored.
- Model datasheet — input signals, forecast horizon, accuracy on a holdout sample, and signs under which the result is considered unreliable.
- Response regulations — event grading by criticality, trip thresholds, deadline for the operator to confirm the forecast, and recording of the actual outcome.
- Dispatcher instructions — step-by-step actions for the shift: reviewing an event card, behavior during a false trip, and escalation procedure for a confirmed risk.
- Access policies — roles and rights differentiated by substation and section, action log, and procedure for granting and revoking access.
- Configurations and updates — settings files, deployment scheme, rollout of a new model version, and rollback to the previous one without stopping data collection.
Documents are versioned together with the system, so with every change it is clear what changed and why.
Case study: how sudden failures of substation equipment were reduced
The fleet of transformer equipment at substations was maintained according to regulations: inspections and oil analysis on schedule, silence between checks.
The accident history showed the same thing: a unit failed within the inspection interval, and the shift learned about the problem from protection tripping — that is, when repair was already an emergency, with risk to adjacent equipment.
Together with our engineers, the customer collected archives from already installed sensors and connected to the substation data bus via IEC 61850: winding and oil temperature, vibration, current load, and dissolved gas analysis results.
The model was trained not on one-off threshold exceedances but on dynamics — gas growth rates and temperature divergence under comparable load at different times of year.
The output is not an "alarm" but an estimate of remaining useful life and a window in which the unit needs to be taken out for repair.
Metrics before and after
| Metric | Before implementation | After |
|---|---|---|
| Share of sudden failures of transformer equipment | 62% | 18% |
| Average warning time for the shift | 6 hours | 11 days |
| Damage resolved by planned repair | 3 out of 10 | 7 out of 10 |
Not only the failure count changed, but also the operating mode. Withdrawal for repair is planned taking into account load and seasonal peaks; units and components are ordered in advance rather than on an emergency basis.
Every warning is reviewed with on-duty personnel: it is either confirmed by inspection or becomes a reason to retrain the model on a new example — the share of confirmed signals has grown, and the flow of false positives does not prevent the shift from working.
How does condition-based forecasting differ from planned repair?
Operating-hours-based repair relies on a standard: for a device, a service life is specified — operating hours, number of switching operations, insulation service life — and once it is used up, the unit is taken out for repair or replacement.
The logic is averaged: the interval is calculated from fleet statistics rather than for a specific unit, so healthy equipment is opened ahead of time, and problematic equipment sometimes later.
Condition-based forecasting works from measurements: vibration and bearing heating, partial discharge, dissolved gas composition in oil, insulation resistance under load.
The model builds a trend for each sign, estimates remaining useful life, and produces not a "time or not" answer but a window in which the unit should be taken out of service.
Hence the difference in equipment replacement criteria. With operating-hours-based repair, the criterion is reaching the standard; with condition-based forecasting, it is the parameter crossing the threshold together with the degradation rate.
Two transformers with the same operating hours receive different decisions: one holds its operating mode, the other accelerates in the trend.
One does not cancel the other. Operating hours remain the baseline and a safety net: for units without sensors, for rare modes, and where there is no accumulated failure history, the standard overhaul interval is the only support.
Forecasting does not discard it but refines it: it shifts the deadline for a specific device and confirms or removes the need for opening it up.
In practice, this results in a two-loop scheme: a baseline overhaul interval based on operating hours and continuous condition monitoring within it. There are fewer sudden failures and fewer unjustified openings, and the interval stops being the same for the entire fleet.
Common technical doubts before starting a project
Before starting, technical teams ask the same questions: will there be enough data, what happens if communication breaks, and will the shift drown in false positives. Below are short answers without generalities.
Sensors are not installed everywhere — what accuracy will the forecast provide?
Accuracy is determined not by the number of sensors but by the history of accidents in the archive. The model is built on available channels — load, temperature, vibration, insulation — and we immediately state the horizon it can hold.
For units without a signal, we leave a threshold rule and record this in the report rather than issuing a prediction with unclear reliability.
How much data is needed for the model to work?
The minimum is two to three seasonal cycles of retrospective data from the archive, together with recorded accidents and restorations.
If the history is shorter, we start with monitoring deviations from the norm: it catches drift without labeling and accumulates examples for the next iteration.
We have our own telemetry and control room — how do you integrate?
We read existing channels without changing the scheme: historical archive, control room data bus, relay protection logs.
We grant read-only access and keep an access log; the model output arrives as a separate flag and does not interfere with the operation of existing protections.
What happens if communication with the facility is lost?
We record the time of the last reliable measurement and mark the interval as unreliable — no forecast is built on it. After restoration, we load the buffer from the facility and recalculate the observation window, so a communication break does not turn into a false accident.
Won't we be overwhelmed by false alarms?
The threshold requires confirmation across several channels and a time delay, and for the first weeks the system operates in observation mode: the dispatcher sees estimates, but signals are not sent to the shift. After that, we raise the threshold to an agreed level.
Let's discuss the task: what we clarify at the first review
At the first review, we do not sell a solution but gather the inputs that determine the scope estimate.
Predictive maintenance of power grids rests not on the model but on the quality of historical data and the signal route to the control panel: without a retrospective of failures with cause labels, a forecast remains guesswork, and without a request into the repair program, it is a report that no one will open.
We break down the task by the points that determine both the scope and the composition of the pilot section:
- Perimeter: which equipment classes and units are included — transformers, lines, switching devices — and who is responsible for the section.
- Data: what is already written to telemetry and repair logs, polling frequency, share of gaps, and whether failures are linked to a cause.
- Target event and horizon: what we consider a failure, how much warning time is needed, and what level of false positives is acceptable.
- Process: how maintenance is assigned today, who decides on taking equipment out of service, and in what form the signal should arrive.
- Contour: where we deploy — the customer's isolated contour or an external one, which exchange protocols are used, and who provides access.
- Acceptance criteria: which metrics we record in the pilot and over what period we compare with planned preventive maintenance.
After the meeting, we return with a scope estimate and an implementation plan broken down by stages. Describe the task — name the fleet, the data period, and the forecast horizon.
