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.

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 seven core 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 core classes in the base layer include PowerSystemResource(anything that participates in the power system), Equipment(physical devices), ConductingEquipment (devices that carry current), Connector (terminal points), Terminal(connection points on equipment), and ConnectivityNode (logical points where terminals connect). These seven classes form the skeleton of every CIM model.

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

CGMES version 3.0 defines common grid model exchange profiles for power-system modelling. The LTDS work adapts that profile discipline for GB distribution needs through Ofgem's Form of LTDS and the BSI-hosted GB CIM artefacts.

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