14 European Utilities Agree: IEC 61850 Engineering Needs to Change. Here's What They Proposed

Editorial Note This article opens a new series on top-down IEC 61850 engineering — one of the most significant shifts in digital substation engineering methodology in recent years. Two new IEC technical reports (TR 61850-90-30 and TR 61850-7-6 ed2) are now published; a coalition of 14 European utilities has formally backed the approach; and the first production deployments are on the horizon. In this series, we trace that shift from its origins to its practical implications — for utilities, IED suppliers, and tool developers. This first article sets the context.

In 2023, fourteen European transmission system operators and utilities signed a common statement on IEC 61850 engineering. It was not a regulatory instrument. It came with no enforcement mechanism. But it was something that rarely happens in industrial standardisation: a group of large utilities, each protective of its own processes, converging on a shared position about how engineering should work — and publicly committing to it.

The initiative was led by Elia Group — the Belgian TSO Elia and its German subsidiary 50Hertz — and attracted thirteen other utilities. Together they published what is now known as the Common Vision on IEC 61850 Engineering: a document that describes a five-step top-down engineering process, explains what it requires from tool vendors and IED suppliers, and demonstrates — through a working proof of concept — that it is technically achievable today.

This article examines what the Common Vision says, how it came to exist, and what it means for the people and organisations that build digital substations.

The Problem: Why the Current Approach Has Structural Limits

The standard IEC 61850 engineering workflow today is built around devices. A utility prepares requirements — typically as Word or PDF documents — and sends them to IED suppliers. Each supplier interprets those requirements, configures a device according to its own toolchain, and returns a capability description file (ICD). The system engineer assembles the final system configuration by cross-referencing these ICD files, resolving naming differences manually, and binding datasets, GOOSE subscriptions, and ExtRef elements by hand.

This approach produced working IEC 61850 systems for twenty years. But it has become structurally limiting as digital substations move from pilot deployments to standard infrastructure, and as large utilities simultaneously manage dozens of IEC 61850 projects.

The problems are well understood among practitioners:

• Interpretation gaps. PDF specifications create room for misreading. Two suppliers reading the same document can produce meaningfully different configurations. The user finds out at commissioning.
• No machine-readable exchange. There is no formal, tool-processable format for communicating what an IED should do. Every project re-creates the specification from scratch.
• Late testing. Verification typically begins after device selection and procurement — the most expensive point at which to discover a design error.
• No reuse. Function specifications developed for one project cannot be transferred directly to the next. Each deployment restarts the engineering cycle.

Thomas Sterckx, expert in virtual substations at Elia Engineering and co-editor of the relevant IEC technical reports, described the direction of change in a December 2023 technical webinar: "Instead of giving [the IED supplier] a large series of written documents... you can give him something that is machine readable, that he can process inside his own tool."

The History: From CIGRE 2012 to Common Statement 2023

The demand for better IEC 61850 engineering processes is not new. In 2012, the CIGRE organisation published a statement — under study committees A3 and B5 — calling for improvements in how IEC 61850 systems were specified and engineered. The requirements articulated then remained largely unmet for a decade.

In 2018, Elia participated in OSMOSE, a European-funded research project. OSMOSE developed the early conceptual framework for what is now the top-down engineering approach: beginning with function specifications that are independent of any particular device, and formalising the exchange between utilities and suppliers in structured, machine-readable formats.

From 2020 onward, IEC TC57 Working Group 10 began developing two technical reports that would give these concepts a standards basis: TR IEC 61850-90-30, addressing function modelling in SCL, and TR IEC 61850-7-6 ed2, covering basic application profiles. Both have since been published — TR 7-6 ed2 in 2024, TR 90-30 in 2025.

The Common Statement, signed in 2023 by Elia Group together with thirteen other European utilities, was the moment when this trajectory became a market signal. As Sterckx observed: "I think I can say that finally we are being able to meet the statements or requirements they asked for in 2012."

Alongside the Common Statement, Elia completed a proof-of-concept project with three industry partners — Condis/Helinks (system specification tooling), Siemens (IED configuration tooling), and Triangle MicroWorks (simulation and testing) — demonstrating the full five-step process using prototype tools.

What the Common Vision Proposes: Five Steps

The Common Vision describes an engineering process built around five sequential steps. The logic is genuinely top-down: the process begins with functional requirements expressed entirely independent of any specific device, and only arrives at physical device configuration at the end.

flowchart LR
    P1["① System Profiling\n(FSD / ASD templates)"]
    P2["② System Specification\n(ISD files)"]
    P3["③ Simulation & Validation\n(ASD / SSD testing)"]
    P4["④ IED Capability\n(process ICD)"]
    P5["⑤ System Configuration\n(SCD)"]

    P1 --> P2 --> P3 --> P4 --> P5

Step 1 — System Profiling. Engineers create reusable function and application templates. A Function Specification Description (FSD) defines a single function — distance protection, circuit breaker control, transformer monitoring. An Application Specification Description (ASD) combines multiple FSDs, defines data flow between them, and can include formal behavior logic written in IEC 61131-3. Critically, these templates reference no physical device. They define what the system must do, not how any particular device does it.

Step 2 — System Specification. Application templates are instantiated into a project. The engineer assembles a system specification and generates per-IED specifications: IED Specification Description (ISD) files — structured SCL documents that formally define the expected data model, signal interfaces, and configuration values. An ISD file is vendor-independent. The same file can be sent to multiple suppliers in parallel, requesting competing capability responses.

Step 3 — System Simulation and Validation. With the ISD files complete, the design can be tested before any device is selected or procured. Tools import ASD and SSD files, simulate the application logic — including the IEC 61131-3 behavior descriptions — and allow test sequences to be run against expected inputs and outputs. The PoC used Triangle MicroWorks' DTM (Distributed Test Manager) for this step. As Jackson Moore, Application Engineer at Triangle MicroWorks, put it: "Many potential errors can now be identified much earlier in the engineering process — and are comparatively much cheaper and easier to fix."

Step 4 — IED Capability Description. Suppliers receive the ISD file, import it into their IED configuration tool (ICT), and map their device's actual capabilities to the specification. Where device capabilities match the specification, the mapping is direct. Where differences exist — different logical device naming, absent data objects, alternative implementations — the supplier documents the deviation formally. The result is a process ICD: a standard ICD file extended with explicit specification-to-device mapping information. This file tells the system configuration tool exactly how each element of the utility's specification is implemented in the real device.

Step 5 — System Configuration. The System Configuration Tool (SCT) imports process ICD files from each supplier. Using the mapping information embedded in each file, it automatically binds logical nodes to real devices, generates GOOSE control blocks and datasets, and populates ExtRef subscriptions. The result is a complete SCD file — with substantially less manual intervention than the current approach requires.

The Proof of Concept: A Complete Workflow, Live

The Elia-led proof of concept ran through all five steps using a real, if simplified, engineering scenario: a circuit breaker application and a distance protection application implemented across four IEDs. The workflow was demonstrated publicly in a December 2023 webinar hosted by Triangle MicroWorks.

In the demonstration:

• Helix STS (Condis/Helinks) handled System Profiling and System Specification, generating ASD and ISD files from function templates assembled in its tool environment.
• Triangle MicroWorks' DTM imported the ASD and demonstrated simulation of the P21 distance protection application, including interactive manipulation of inputs and a test sequencer driven from Excel.
• Siemens' DIGSI 5 imported the ISD files for a 6MU merging unit and a 7SA87 distance protection relay, performed the LNode-to-LN mapping, and exported process ICD files — with the option to either retain the device's native naming or adopt the unified data model from the specification.
• Helix STS then imported both process ICD files, automatically implemented the LNode specifications using the mapping data, generated GOOSE control blocks and datasets, and exported a complete SCD.
• Siemens' Digital Twin imported the SCD, applied the GOOSE configuration, and ran both virtual devices simultaneously to verify signal flow and data model.

The entire workflow used the SCL namespace 6-100 — the extension defined in TR 61850-90-30 and TR 61850-7-6 that introduces the new SCL elements the process requires: AllocationRole, SourceRef, LNodeSpecNaming, BehaviorDescription, and others.

What This Means for the Market

The Common Statement and the accompanying proof of concept have a specific intended audience: IED suppliers and tool vendors who need to understand what large European utilities will expect from their products.

For IED suppliers, the formal ISD interface changes the procurement dynamic. A utility holding a machine-readable ISD file can send it to multiple suppliers simultaneously and compare their process ICD responses — including documented deviations — in a structured format. The barrier to switching suppliers decreases. As Sterckx noted: "An ISD is vendor independent and you can easily give it to multiple IED suppliers and get multiple offers back."

For IED configuration tool vendors, the Common Vision defines concrete capability requirements: ISD import, LNode-to-LN mapping, process ICD export, deviation documentation. These are the features that will determine whether a tool is usable in the new workflow.

For system configuration tool vendors, the key requirement is process ICD support: the ability to read the mapping information in a process ICD file and use it to automate SCD generation.

Elia Group has indicated a development roadmap reaching to 2029–2030 for first production projects, with tool procurement anticipated around 2027. The timeline gives the tooling ecosystem several years — but decisions about development priority are being made now. TR 90-30 and TR 7-6 ed2 are published. The process has been demonstrated. Elia is preparing to tender for an engineering ecosystem.

Conclusion

The Common Vision is a well-structured response to a real and recognised problem. The current IEC 61850 engineering approach — specification by PDF, manual integration, late validation — is not where a mature standard should be. Fourteen utilities formally backing the same process definition creates a demand signal that the tooling market cannot ignore.

The standards infrastructure is in place. The proof of concept demonstrates that the process is technically feasible with existing tools. The question now is how quickly the broader ecosystem — IED suppliers, tool vendors, and utilities beyond the current coalition — will align with the approach the Common Vision describes.

Subsequent articles in this series examine the technical details: the five-step process in depth, the ISD file format and what it changes about IED procurement, the SCL namespace 6-100 and what tool developers need to implement, and the process ICD as the pivot point between specification and configuration.

Primary sources: Technical webinar — "Establishing a Vendor-Independent Specification Process for Top-Down Engineering of IEC 61850 Systems" (Triangle MicroWorks / Elia Group, December 2023); TR IEC 61850-90-30:2025; TR IEC 61850-7-6 ed2:2024; Elia Group — Common Vision on IEC 61850 Engineering.

Photo: Mercator 380 kV substation, Kruibeke, Belgium (Elia). Supercharge / Wikimedia Commons, CC BY-SA 3.0.