CIM and Interoperability: The Common Language

The Common Information Model is defined in IEC 61970 and IEC 61968. It provides a shared vocabulary, a set of classes, attributes, and relationships, for describing electricity network elements. Think of CIM as a dictionary that every utility agrees to use. A substation in CIM has a specific set of attributes (name, location, voltage level). A transformer has a specific set of relationships (connected to a substation, associated with a winding, linked to a tap changer). By agreeing on this dictionary, different utilities can exchange network models that are immediately understandable without translation.

The CIM family: three related standards

CIM is maintained by the IEC and comes in three parts that cover different corners of the electricity system. IEC 61970 describes the transmission network and the systems that run it. IEC 61968 extends the same ideas to distribution networks, the lower-voltage wires that reach homes and businesses. IEC 62325 covers energy markets. GB's LTDS work is a distribution use, so it draws on IEC 61970 for the core model and on IEC 61968 for the distribution-specific parts. A common misunderstanding is that CIM is a transmission-only standard; the distribution and market parts are what make it usable across the whole sector.

GB's CIM implementation is best understood as a four-layer implementation stack. The vocabulary says what things mean. Profiles say which subset of that vocabulary is needed for a use case. Exchange documents serialise the profile into a file or payload. Validation checks whether the exchanged model conforms to the rules.

Layer 1: Vocabulary

The foundation layer defines a small set of base classes that appear in virtually every CIM model. The most important is IdentifiedObject, the base class from which almost every other CIM class inherits. Every element in a CIM model has a name, a description, and an mRID (master Resource Identifier), a globally unique identifier that distinguishes this specific element from every other element in the world.

The mRID is critical for interoperability. When UK Power Networks publishes a CIM model containing a substation with mRID “abc123-def456-ghi789”, and NESO receives that model, the mRID ensures that both parties know they are referring to exactly the same physical substation. Without globally unique identifiers, merging models from different sources would be ambiguous.

Other widely used base classes include PowerSystemResource(anything that participates in the power system), Equipment(physical devices), ConductingEquipment (devices that carry current), Terminal (connection points on equipment), andConnectivityNode (logical points where terminals connect). More specialised classes such as Connector describe particular arrangements rather than forming part of this common core. Together the base classes give every CIM model a shared shape.

“IEC 61968 defines a standard application program interface for distribution management systems, enabling interoperability between systems from different vendors and organisations.”

IEC 61968: Application Integration at Electric Utilities - System Interfaces for Distribution Management

IEC 61968 is the distribution-focused complement to IEC 61970 (which covers transmission). Together they form the CIM standard that GB's LTDS programme implements. IEC 61968 Part 11 defines the distribution-specific classes and relationships that are essential for DNO network models.

Layer 2: Profiles

A profile selects the parts of the vocabulary required for a particular exchange. Equipment, steady-state hypothesis, topology and state variable profiles exist because no user needs the entire CIM vocabulary every time. Profiles make the exchange smaller, more testable and more precise.

The Common Grid Model Exchange Standard (CGMES) is the profile-and-rules package Europe's transmission operators agreed so their planning and operational models work together. Two versions matter in practice. CGMES 2.4.15 is older and still runs much of Europe's day-to-day exchange. CGMES 3.0 is the current international standard and corrects known defects in the earlier version. Neither has fully displaced the other, so a competent reader treats them as coexisting rather than assuming everyone has moved to 3.0.

Profiles also depend on how the network itself is described. A node-breaker model shows every busbar, switch and breaker, so it captures the exact switching state. The simpler bus-branch model collapses that into nodes and the branches between them. Utilities master the node-breaker form, and topology processing derives the bus-branch view from it, not the other way round. When two operators need to join their models, a boundary set defines the shared points where one model meets the next, so neighbouring networks stitch together consistently.

GB's LTDS profiles are defined as precise deltas from the CGMES 3.0 profiles: a deviation and an extension for each one, rather than a fresh standard. They are grouped as Physical (Equipment, Short Circuit, Geographical Location), Situation (Steady State Hypothesis), Solution (Topology, State Variables), plus System Capacity and Diagram Layout, and the unbalanced-network extensions draw on the distribution model in IEC 61968. Governance sits with the GB CIM Advisory Group, which is independent of the regulator and led by BSI, with the technical artefacts hosted on the BSI Engagement Hub. Ofgem's stated approach is to mandate CIM for network data exchanges starting with LTDS, with CGMES 3.0 as the core GB standard.

Layer 3: Exchange documents

Exchange documents package the profile into a concrete payload. In the LTDS context, this includes CIM grid-model files and capacity heatmap datasets. The important distinction is that the exchange document is the container; the CIM model is the meaning inside the container.

A CSV file, RDF/XML file, JSON dataset or API response can all be exchange documents. For CIM grid models the standard serialisation is RDF/XML, sometimes called CIM XML, defined by IEC 61970-552 and packaged as named zip files with a header that records the scenario time, version and dependencies. These files only become interoperable when the field meanings, identifiers, units and relationships are governed by the same profile rules.

Layer 4: Validation

Validation checks whether the exchanged model is structurally and semantically usable. Ofgem's Form of LTDS refers to RDFS and SHACL, which means validation is not just a spreadsheet check. SHACL constraints let cardinality and value checks run from one shared rule source, and CGMES 3.0 ships these rules with the standard. Validation can test whether required objects exist, whether relationships are valid, whether identifiers are present, and whether a model is complete enough for its intended analysis.

This is the layer that turns a data standard into operational confidence. Without validation, two parties can claim to publish CIM while still producing models that cannot be merged or solved.

The Long Term Development Statement (LTDS) programme requires distribution licensees to publish CIM grid models and capacity heatmap data under Ofgem's Form of LTDS. The course uses nine CIM artefact groups to explain the practical building blocks. Some are standard CGMES-style profiles, while others are GB LTDS outputs or results that sit alongside the core model.

The nine artefact groups

• EQ (Equipment), The structural model: every substation, transformer, line, cable, switch, and their connections. This is the physical topology of the network.
• SC (Short Circuit), Electrical parameters needed for fault level calculations: impedances, fault contribution characteristics, and earth path data.
• GL (Geographical Location), Coordinates for every network element, enabling GIS mapping and spatial analysis.
• SSH (Steady State Hypothesis), Operational state data: switch positions, tap changer settings, and generator dispatch for a specific scenario.
• TP (Topology), Logical connectivity derived from the EQ model and SSH switch positions. Defines which parts of the network are electrically connected at a given moment.
• SV (State Variables), Calculated results: voltages, power flows, and losses for a solved power flow case.
• SCR (Short Circuit Results), Calculated fault levels at each busbar, used for protection coordination and connection assessments.
• SYSCAP (System Capacity), Available capacity at each primary substation for new connections, both demand and generation.
• DL (Diagram Layout), Schematic layout information for rendering single-line diagrams of the network.

Artefact groups combine into cases

Individual artefact groups become operationally useful when combined into cases. A case represents a specific scenario that a planner or engineer needs to analyse. The LTDS programme defines five standard cases:

• Existing Fault Level, EQ + SC + SCR. Combines the physical network with short circuit parameters and calculated fault levels. Used for protection coordination and assessing whether a new connection would exceed fault level limits.
• System Capacity, EQ + SYSCAP. Combines the physical network with available capacity data. Used for connection applications and investment planning.
• NETS Maximum / NETS Minimum, EQ + SSH + TP + SV. Combines physical network, operational state, topology, and solved power flows for maximum and minimum demand scenarios. Used for voltage management and thermal constraint analysis.
• Future Year, EQ + SSH + TP + SV with projected demand and generation changes. Used for long-term network planning and investment justification.
• Development, EQ with planned reinforcements and new connections included. Used for assessing the impact of planned network changes.

The modularity of profiles is a key design choice. Rather than publishing a single monolithic model that includes everything, the artefact-group approach allows users to download only the data they need. A developer applying for a new connection needs EQ and SYSCAP but not SC or DL. A protection engineer needs EQ, SC, and SCR but not GL or SYSCAP. This reduces data transfer volumes and ensures that users receive data relevant to their specific use case.

The five workstreams

The LTDS CIM programme is structured into five workstreams, each delivering a specific set of capabilities:

• WS1 (Carry-over), Core equipment and topology data. This was the foundation workstream that established the EQ and TP profiles and the basic model exchange infrastructure.
• WS2 (Short Circuit), SC and SCR profiles for fault level data. Critical for connection assessments and protection coordination.
• WS3 (Capacity), SYSCAP profile for available capacity data. Essential for the connections process and network planning.
• WS4 (Future Models), SSH and SV profiles for scenario modelling. Enables long-term planning and investment analysis.
• WS5 (Non-grid), Extensions beyond traditional network data, including demand forecasts, flexibility asset data, and integration with DSI/FMAR.

Stage timeline

Ofgem's 13 May 2026 derogation letter changed the delivery sequence. Stage 2 publication remained 29 May 2026, but DNOs were approved to provide one future-year EQ and SYSCAP model at Stage 2, with remaining future-year models deferred to Stage 3. The same letter approved moving short-circuit results from SYSCAP to a dedicated SCR profile, and moved the Stage 3 production deadline from 15 August 2026 to 15 October 2026 while keeping Stage 3 publication at 30 November 2026.

The worked example: a CIM model from DNO to NESO

To understand how CIM operates in practice, consider the journey of a network model from a DNO to NESO. A DNO, say, UK Power Networks, publishes its EQ model for the Eastern Power Networks licence area. This model contains every substation, transformer, and circuit from 132 kV down to low voltage, each with a unique mRID, electrical parameters, and geographical coordinates.

NESO receives this model and merges it with models from adjacent distribution licence areas and with its own transmission model. The boundary points, typically at 132/33 kV interfaces, are where the DNO model connects to the NESO model. Because both use CIM with consistent mRIDs at boundary points, the merge is automated rather than manual. NESO can then run power flow analysis across the entire merged model, identifying constraints that span the transmission-distribution boundary.

Before CIM standardisation, this merge required manual mapping between different data formats, naming conventions, and model structures. Each licence area used its own approach, and NESO had to maintain multiple translation processes. CIM reduces this to a single, automated merge process.

GC0139 alignment risk

GC0139 is a Grid Code modification that defines the data exchange requirements between NESO and DNOs. It specifies what data DNOs must provide to NESO, in what format, at what frequency, and for what purpose. The GC0139 modification is being developed in parallel with the LTDS CIM programme, and therein lies the alignment risk.

If GC0139 defines data exchange requirements that are inconsistent with the CIM profiles being developed by the LTDS programme, DNOs face conflicting obligations. They would need to publish CIM-compliant models for the LTDS while simultaneously providing differently-formatted data for GC0139 compliance. This duplication wastes resources and introduces the risk of inconsistency between the two data sets.

The mitigation is explicit alignment: ensuring that GC0139 references CIM profiles as the delivery mechanism for its data requirements. Progress on this alignment has been mixed. The LTDS programme team and the GC0139 workgroup have engaged, but the two processes have different governance structures, different timelines, and different stakeholder groups. The risk of divergence remains until GC0139 formally adopts CIM profiles as its data exchange standard.

The same thinking that makes a CIM model shareable, an agreed vocabulary, defined profiles, a named serialisation and rules that can be checked, is what the wider GB data reforms are reaching for beyond the grid model. A network model that any tool can read is one worked example of a broader ambition: energy data that is described once, in a common language, and reused across the sector rather than rebuilt for each exchange.

Two initiatives carry that ambition. NESO's Virtual Energy System is being built as an ecosystem of connected digital twins, digital models kept in step with the physical system so that analysis and planning can run against a shared picture. The Data Sharing Infrastructure (DSI) is the plumbing meant to let organisations find and exchange that data with consistent descriptions and access rules. Ofgem appointed NESO the interim DSI coordinator in March 2025, with the role running to 2028, and the infrastructure is moving from pilot to a minimum viable product expected in the middle to later part of 2026. It is honest to describe the DSI as in delivery rather than as a finished system.

This closes the loop with the question of who controls the data. Shared vocabularies and validation are not only technical conveniences; they decide whose data can be joined, checked and trusted, and on whose terms. CIM shows in one domain what open, described, interoperable data looks like in practice, and the DSI is the attempt to make that the norm across GB energy data.