Topology, Data Models, and Sources

REPORT ID: 03-TOPOLOGY-AND-DATA · 7 MIN READ

The network as a graph

A grid model is a graph with electrical attributes. But which graph depends on the level of detail, and the two standard levels answer different questions.

Node-breaker

Every conductive connection point is a node; busbar sections, circuit breakers, and disconnectors are all explicit elements. This is the operator’s view, because switching is an operational action: the network’s connectivity changes many times a day, and the model must be able to represent the state before and after.

Bus-branch

Closed switches are collapsed, so that each group of nodes joined by zero-impedance connections becomes a single electrical bus. Branches are lines and transformers. This is what nearly every analysis engine consumes — power flow solvers work on buses, not breakers.

Topology processing

Going from node-breaker to bus-branch is mechanical in principle: build the subgraph of closed switches, take connected components, each becomes a bus. In practice it is a common source of defects:

  • A single wrong switch status merges or splits a bus, changing impedances and flows materially.
  • Components that end up with no injection and no path to a source are islanded and must be detected and removed, or the solver will fail on a singular matrix.
  • Measurement and equipment identifiers must survive the collapse, or results cannot be mapped back to physical assets.

Anyone building a pipeline over operator data will spend more time here than they expect.

The Common Information Model

The Common Information Model (CIM) is the IEC standard information model for power systems — IEC 61970 for energy management, IEC 61968 for distribution, IEC 62325 for markets.1 It defines classes (ACLineSegment, PowerTransformer, SynchronousMachine, Terminal, ConnectivityNode, …), their attributes, and their relationships, as an RDF/OWL ontology.

CGMES (Common Grid Model Exchange Standard) is ENTSO-E’s profiled subset of CIM, and it is the mandatory format for grid model exchange between European TSOs under the CACM and SO network codes.2 Understanding its structure explains a lot about how European grid data actually moves.

A CGMES dataset is split into profiles, each a separate file:

ProfileContains
EQ — EquipmentPhysical assets and their parameters
TP — TopologyWhich terminals connect to which topological nodes
SSH — Steady State HypothesisSetpoints, switch statuses, injections for a specific case
SV — State VariablesThe solved result: voltages and flows
SC / DYShort-circuit and dynamics data
GL / DLGeographical and diagram layout

The separation is deliberate. The EQ profile changes rarely; the SSH profile is what varies between cases. Individual TSOs publish IGMs (individual grid models) which are merged into a CGM (common grid model) for the synchronous area — the artefact on which pan-European capacity calculation and security analysis run.

The practical difficulty with CGMES is that it is verbose, deeply referential (following TerminalConnectivityNodeTopologicalNode chains), and permits variation in how equivalents and boundaries are expressed. Libraries such as pycgmes, CIMpy, and PowSyBl’s CGMES importer exist to absorb this.3

Other formats you will meet

  • MATPOWER case files — a compact bus/branch/gen matrix format, and the de facto research standard. Simple, positive-sequence, bus-branch, with an OPF-oriented cost section.4
  • PSS/E RAW — the dominant commercial format in industry; fixed-field text, version-sensitive.
  • PyPSA / pandapower native formats — Python-object or CSV/HDF5 based, and the natural target if your pipeline is Python.56
  • PowerModels.jl / .m and JSON — used for optimisation research, with a strong emphasis on rigorous problem formulations.7

A rule of thumb: format conversion is never lossless. Going from CGMES to MATPOWER discards node-breaker detail, dynamics, and most control descriptions. Decide once what the model is for, then convert in that direction only.

Where to get data

Operational and market data (open)

The ENTSO-E Transparency Platform publishes, for all European bidding zones, actual and forecast load, generation by type and by unit, installed capacity, cross-border scheduled exchanges and physical flows, balancing volumes and prices, and planned/unplanned outages of generation and transmission assets. Publication is mandated by Regulation 543/2013, and a documented REST API is available with a free token.8

Its main limitations, which you should assume rather than discover: coverage and quality vary by TSO; unit-level generation is reported only above capacity thresholds; revisions are published without loud announcement; and outage data are self-reported with variable timeliness.

Complementary sources include national TSO portals (often richer than what reaches ENTSO-E), the Open Power System Data project for curated cross-country time series, and ENTSO-E’s TYNDP scenario datasets for forward-looking assumptions.9

Network topology and parameters (mostly not open)

Impedances and detailed topology are treated as security-sensitive and are generally not published. The realistic options:

  • Reconstructed networks. SciGRID and PyPSA-Eur derive a European transmission network from OpenStreetMap substations and lines, assign standard impedance values by voltage level and conductor type, and validate against known aggregate flows.10 They are good enough for scenario and market-adjacent work and are explicitly not a substitute for an operator’s model.
  • Published test systems. IEEE cases (14, 30, 57, 118, 300 bus), the Nordic32 and other CIGRE benchmark systems, the ENTSO-E CGMES conformity test configurations, and the synthetic-but-realistic ACTIVSg cases from Texas A&M, which are geographically plausible and unclassified by construction.11
  • Bilateral access. Operators and regulators do share models under NDA for connection studies and formal processes. This is the only route to answers that must be right about a specific asset.

Distribution networks

Even scarcer. Common substitutes are the IEEE distribution test feeders, the SimBench and DIgSILENT/pandapower synthetic German networks, and the OpenDSS example systems.12 Where real LV data exist they are usually incomplete on phase connectivity, which is precisely the attribute unbalanced studies need.

Judging whether a dataset supports your question

Before building anything, ask three questions of the data.

Is the topology at the right resolution? A reconstructed 380/220 kV network cannot answer a question about a 110 kV corridor, no matter how good the optimisation on top of it.

Are the parameters real or assumed? Reconstructed networks assign typical impedances by voltage class. Flows on individual branches will therefore be wrong even when aggregate patterns are right. Any conclusion that depends on a specific line’s loading is unsupported.

Is the scenario consistent? Load, generation, exchanges, and topology must describe the same moment. Mixing a demand series from one source with a dispatch from another produces a case that balances numerically and corresponds to nothing.

Stating these limits explicitly in the write-up of a study is not a weakness. It is the difference between a model and a claim.

Summary

Grid data lives in a standardised but heavy information model (CIM/CGMES) designed around the separation of equipment, topology, and case. Market and operational data are open in Europe; network parameters largely are not, and the working alternative is a reconstructed or synthetic network whose limitations should be stated up front. Topology processing between node-breaker and bus-branch is where most data-pipeline defects live.

Next: the computation these datasets exist to feed.

References


  1. IEC 61970-301, Energy management system application program interface (EMS-API) — Common Information Model (CIM) base. iec.ch ↩︎

  2. ENTSO-E, Common Grid Model Exchange Standard (CGMES). entsoe.eu/data/cim/ ↩︎

  3. PowSyBl open-source power system framework (LF Energy). powsybl.org ↩︎

  4. R. D. Zimmerman, C. E. Murillo-Sánchez and R. J. Thomas, “MATPOWER: Steady-State Operations, Planning and Analysis Tools”, IEEE Trans. Power Systems, vol. 26, no. 1, 2011. matpower.org ↩︎

  5. T. Brown, J. Hörsch and D. Schlachtberger, “PyPSA: Python for Power System Analysis”, Journal of Open Research Software, vol. 6, no. 4, 2018. pypsa.org ↩︎

  6. L. Thurner et al., “pandapower — An Open-Source Python Tool for Convenient Modeling, Analysis, and Optimization of Electric Power Systems”, IEEE Trans. Power Systems, vol. 33, no. 6, 2018. pandapower.org ↩︎

  7. C. Coffrin, R. Bent, K. Sundar, Y. Ng and M. Lubin, “PowerModels.jl: An Open-Source Framework for Exploring Power Flow Formulations”, PSCC, 2018. ↩︎

  8. ENTSO-E Transparency Platform and RESTful API. transparency.entsoe.eu ↩︎

  9. Open Power System Data. open-power-system-data.org ↩︎

  10. W. Medjroubi et al., “Open Data in Power Grid Modelling: New Approaches Towards Transparent Grid Models”, Energy Reports, vol. 3, 2017; SciGRID project. scigrid.de ↩︎

  11. A. B. Birchfield, T. Xu, K. M. Gegner, K. S. Shetye and T. J. Overbye, “Grid Structural Characteristics as Validation Criteria for Synthetic Networks”, IEEE Trans. Power Systems, vol. 32, no. 4, 2017. electricgrids.engr.tamu.edu ↩︎

  12. S. Meinecke et al., “SimBench — A Benchmark Dataset of Electric Power Systems”, Energies, vol. 13, 2020. simbench.de ↩︎