Why a power grid digital twin diverges from actual measurements
A power grid digital twin begins to diverge from reality not because of an error in the equations, but because of the state of the source data.
The topology changes faster than the equivalent circuit is updated: new connections are added, cable lines are rerouted, and loads are redistributed between feeders.
If the model lives on an old snapshot, the calculation error of operating modes accumulates across the network and reaches the boundaries of the balance.
The second source is disparate measurements. Commercial metering and telemetry record data with different averaging intervals and different time references, while some points come from manual readings.
Merging such streams "by eye" produces a power imbalance that is convenient to write off as losses — although it is a discrepancy between the model and the measurements.
The third is manual assumptions that no one revisits: averaged specific loads per node, a constant power factor, typical resistances for groups of lines.
Individually, each contributes a fraction of a percent; together, they produce a systematic shift, especially noticeable on lightly loaded connections, where the model is sensitive to every correction.
The fourth is unaccounted operating modes. Repair schemes, backup inputs, operation of distributed generation at minimum output, and seasonal switching remain outside a model configured for one characteristic peak.
In a non-standard mode, the model predicts one thing, while measurements show another — which is why the work begins not with tuning the calculation, but with auditing the data.
What a synchronous model provides: effects in operating modes and losses
A synchronous model holds the current state of the network — flows along sections, equipment loading, positions of regulating devices — and recalculates them whenever the topology changes.
Network mode optimization grows directly from this: the dispatcher sees not an "average" mode, but a specific set of switching operations that removes imbalance and equalizes loading between inputs.
Loss reduction also becomes targeted. The model shows on which feeders losses grow due to suboptimal distribution, and after load transfer they drop by 8–15% — the effect is visible from metering devices, not from a calculated estimate.
Overload management is built the same way: a section that exceeds the permissible current during peak is highlighted in advance, and a decision is made before protection operates.
Equipment loading forecasting provides a window for repairs and switching. If it is known that a transformer will reach its limit by the evening peak, work is planned for the trough rather than the peak — equipment stops going into overload, and repairs are not postponed.
Incident analysis is accelerated by retrospective data: the engineer has the network state before and after the event, a reconstructed sequence, and points where protection operated outside the calculated scenario. Finding the cause is replaced by testing hypotheses, and time to removal from service is reduced.
We maintain reliability by comparing calculations with telemetry and public loss statistics IEC — we analyze discrepancies and calibrate the model; otherwise the effects remain on paper.
Approaches to building a network model: comparison of options
All three approaches describe the same network, but answer differently the question of what constitutes its current state. A static network model fixes the topology and parameters of lines and loads for a selected snapshot and runs a steady-state calculation for it.
A streaming model updates state from telemetry and keeps the network alive, while a hybrid one builds a core from static data and overlays dynamics on top.
How the options differ
| Option | When it fits | Where accuracy ends |
|---|---|---|
| Static network model | Design and operating calculations, setpoint verification, incident analysis from archived snapshots | Between recalculations, it does not see switching and daily load growth |
| Streaming model | Dispatch monitoring, state estimation after switching | Depends on telemetry completeness: with gaps in data, the estimate drifts |
| Hybrid scheme | Mixed network coverage: detailed nodes with instruments, the rest as an equivalent | Requires synchronization of layers; equivalenting error accumulates at boundaries |
The difference manifests at the boundaries: the more frequently the mode is recalculated, the higher the requirements for data reliability, and the wider the network coverage, the more nodes must be replaced with an equivalent.
For steady-state calculations, we take a proven open-source core — for example, pandapower — and build our own data preparation layer on top of it.
The option is selected before work begins: it determines the composition of telemetry, the equivalenting scheme, and the scope of checks on historical snapshots.
Work stages: from asset inventory to handover into operation
The order of work is strict: calibrating a model on an incomplete network is pointless — the discrepancy with reality then cannot be distinguished from a topology error. First data, then the network, and only after that the parameters. Here is how the implementation of a digital twin looks step by step.
- Network inventory and data audit. We compile a register of assets, single-line diagrams, equipment passports, and operating mode archives. We note gaps in measurements, nodes without metering, and discrepancies between the diagram and the actual state.
- Topological model assembly. We merge the inventory with the real configuration: voltage levels, links, metering points, and boundaries of balance responsibility. The output is a connected network on which the mode is then calculated.
- Model setup and calibration. We set the nameplate parameters of lines and transformers, then refine them using historical operating modes — until the discrepancy of losses and flows with measurements falls within the specified accuracy.
- Validation against reality. We run the model on a period that was not used in calibration. An increase in discrepancy is a sign of a topology error, not a parameter error: we return to the network assembly step.
- Acceptance tests. We calculate the scenarios for which the twin is being built: switching, repair schemes, load growth, element failure. We compare the result with manual calculations and the actual behavior of the network.
- Handover into operation. We deliver the model, its update regulations, and an access rights scheme, and train dispatchers and engineers to work with the twin independently.
Delivery package: diagrams, configurations, and regulations
The delivery package is not an archive for reporting, but a working tool: the power grid digital twin continues to live at the customer's site after project handover.
We deliver everything in editable formats, linked to the model version and with a change history, so that diagrams and scenarios can be edited by the customer's own team without rebuilding the solution from scratch.
- Network diagrams — topology with nodes, links, and references to real metering assets; editing one section does not affect the rest of the model.
- Calculation scenario configuration — winter peak, repair outages, load growth: boundaries, step, and assumptions are described separately from the calculation code.
- Model passport — data sources, training period, feature set, list of assumptions, and sections with reduced accuracy.
- Model update regulations — retraining frequency, procedure for diagram edits, validation on reference periods, and conditions for rolling back to a previous version.
- Access policies — roles, visibility scopes, request logging: it is visible who changed a scenario or node parameters and when.
- Operating instructions — stand deployment, connection of telemetry sources, actions when the forecast diverges from reality.
A separate block is the validation log: the error by nodes and periods at the time of handover serves as a reference against which each subsequent update is compared.
Case study: how overload was eliminated in a distribution power grid
The customer is City Distribution Networks: several dozen medium-voltage feeders and mixed load — city, industrial zone, and private sector.
Overloads were identified after the fact: the dispatcher compared telemetry with line data sheets manually, and the cause of the deviation was found in 3–4 hours, often already after consumers were disconnected.
We built a digital twin: topology, line and transformer data sheets, daily load profiles, and switching history. The model recalculates modes daily by scenario — summer peak, repair schemes, new connections — and ranks sections by overload risk.
The dispatcher sees not an "average load," but a list of sections with the cause: phase asymmetry, a transformer lagging in power, or a closed loop.
| Indicator | Before | After |
|---|---|---|
| Share of overloaded sections | 18% | 2% |
| Time to find the cause of deviation | 3–4 hours | 10–15 minutes |
| Match between calculation and reality | 71% | 94% |
Accuracy was verified against the deviation log: calculation and reality matched in 94% of cases, and false alerts decreased threefold.
Discrepancies remained in sections without telemetry — there the model works from indirect data and marks such conclusions as requiring manual verification.
What to do if the network is already described in an old calculation model?
An old calculation model is not a draft, but an accumulated asset: topology, equipment parameters, telemetry references, and operating archives. It cannot be transferred "as is": the solution methods and assumptions in a digital twin are different.
Therefore, model migration begins with inventory — what in the old system is data, and what is a hardcoded assumption that will have to be rebuilt.
Data is transferred without loss: connection diagram, line resistances, transformation ratios, setpoints, measurement points, and historical snapshots. We build the exchange on an industry standard for model representation — manual input goes away along with rekeying errors.
The calculation part has to be rebuilt: equivalenting of the external network, zone boundaries, and loss tolerances — the twin calculates the mode using different mathematics.
Then — shifting calculations to retrospective data: we run archived snapshots and already-made decisions through the new model and compare power flows, voltage levels, and losses by node.
A discrepancy above the agreed tolerance is a signal to investigate a specific node or assumption, not to write it off as an error.
Until the list of discrepancies is closed, the old system operates in parallel: the dispatcher sees the same picture in two circuits and can compare both.
Migration proceeds in iterations — by network districts or voltage classes, without stopping operational work. Accumulated calculations are not discarded: the archive remains a reference and history for model validation.
What exactly to rebuild in each specific case is decided based on reconciliation results, not by default — this way, the transfer does not turn into rewriting the network from scratch.
Technical concerns: accuracy, integration, and model operation
The accuracy of a digital twin is limited by the quality of metering and the completeness of topology, not by the algorithm. That is why we begin with a telemetry audit, not with model training: without it, any metric remains a number without support. Below are answers to what customer engineers most often check.
How can we verify model accuracy before implementation?
We assemble a control sample of operating modes: peak load, repair schemes, emergency outages. We calculate deviation for each node — flows, voltages, losses — rather than an average across the network; otherwise problematic sections are masked.
The output is a reliability map: for which decisions the model can be placed in the loop, and where additional sensors are needed.
Will the model replace existing metering systems?
No, the twin is integrated alongside. It reads telemetry from operating metering and dispatch systems via industrial exchange protocols, but does not write to them directly.
Control actions are issued only through agreed setpoints and dispatcher confirmation — the implementation does not affect protection and emergency automation circuits.
What does model support include after handover?
Topology and loads change: assets are commissioned, diagrams change, and new measurements arrive.
Therefore, along with the model, we deliver calibration regulations: retrospective runs after switching, reconciliation with reality, parameter updates, and repeated accuracy verification.
Some work is performed by the customer's team independently after training, and the rest we cover according to an agreed schedule.
Let's discuss the task: what data is needed to start work
The scope of work for a power grid digital twin is determined not by the number of nodes in the diagram, but by the completeness and connectivity of the source data.
If there is a telemetry archive covering several seasonal modes and equipment data sheets, the model is calibrated against reality and reproduces actual power flows; with only single-line diagrams, the calculation relies on typical equivalent circuits, and this becomes a separate refinement stage.
To come back with a work plan and estimate, rather than general words, we need the following set:
- Network diagram: topology with nodes, links, and voltage levels — an export from the data acquisition system, a CIM model, or a table.
- Telemetry archive: measurements at key points with polling frequency and a period covering winter and summer peaks.
- Equipment data sheets: transformers, generation, lines — types, ratings, equivalent circuits, coefficients.
- Operating constraints: protection setpoints, permissible flows, voltage limits.
- Load and generation profiles: daily and seasonal schedules, links to weather data, plans for commissioning and decommissioning equipment.
- Access: a test loop or separate environment, read access to the data acquisition system, and history export. Plus an operating mode engineer and an IT specialist on your side to coordinate data exchange.
There is no need to prepare everything in advance — some questions are resolved in conversation. Describe the task: the facility, which decisions the twin should support, and what data and access already exist. We will come back with a work plan, stage breakdown, and estimate.
