IEC 61850 Edition 1 vs Edition 2

Back to Blog

What the Second Edition Set Out to Fix

Edition 1 proved the concept but left gaps that early adopters hit: ambiguities in the data model, uneven conformance testing, and engineering-process details that different vendors interpreted differently, which undercut the interoperability the standard promised. Edition 2 was the consolidation. It clarified and extended the abstract data model, added and revised logical nodes, tightened the SCL rules so configuration files exchange more cleanly between tools, and strengthened the conformance and testing framework so a certificate means more.

The result is that Edition 2 devices and tools tend to interoperate more predictably, but the changes are substantive enough that an Edition 1 device and an Edition 2 device on the same network cannot simply be assumed compatible. Some data-model and SCL details differ, and tools handle the older and newer schema versions differently.

Reading Edition in Practice

The concrete signal of edition is in the SCL file: its schema version and revision attributes declare which edition the file targets, and engineering tools use that to parse it correctly. When you receive an ICD or SCD, checking the declared version tells you what you are dealing with before you import it into a system tool that may target a different edition.

In a mixed substation the safe path is to verify interoperability explicitly - confirm that a client can browse and report on each device's model, and that GOOSE publishers and subscribers agree - rather than trusting that the shared brand of the IEC 61850 standard guarantees it. Edition differences are a frequent, quiet cause of integration surprises, and conformance testing is the tool that surfaces them early.

Edition Differences at a Glance

The changes cluster into a few areas, and seeing them side by side explains why cross-edition work needs verification rather than faith.

Area	Edition 1	Edition 2
Data model	Baseline logical nodes, ambiguities left to interpretation	Clarified semantics, revised and additional logical nodes
SCL engineering	Schema loose enough for vendor-specific readings	Tighter rules, cleaner file exchange between tools
Conformance	Basic device-level testing	Expanded coverage, certificates that mean more
Services	Core reporting and messaging behavior	Clarified service behavior and tracking additions

Just as important is what did not change: the layered architecture, the abstract services, and the mapping approach all carry through, so knowledge and most engineering practice transfer directly between editions. Edition is a compatibility detail of the model and its files, not a different standard - which is exactly why it is easy to overlook until a subscriber stays silent.

The table also understates one practical improvement: Edition 2 formalized how models declare which namespace and revision they belong to, which is what allows tools to detect a mismatch instead of guessing. On Edition 1 projects, that detection often falls to the integrator reading the raw file, cross-checking declared versions by hand, and keeping notes on which device exports parse cleanly in which tool - tedious work, but cheaper than debugging a silent subscriber during an outage window.

Planning a Mixed-Edition Substation

Treat edition as an inventory attribute. Before any integration work, list every IED, its firmware version, and the edition its configuration files declare - firmware upgrades can move a device between editions, so the record must be kept per installed firmware, not per product family. Add the engineering tools to the same list, because a system configurator that targets one edition may import a file from another with silent downconversion or outright rejection, and the failure surfaces much later as a subscriber that never receives data or a report whose members do not match the design.

A workable sequence for a mixed-vintage project:

1. Collect configuration files from every device and record the declared schema version of each.
2. Identify which tools in the chain parse those files and which editions each supports.
3. Design datasets and control blocks against the capabilities of the oldest edition involved.
4. Bench-test one representative device pair for each edition combination before committing the design.
5. Re-verify after any firmware upgrade, since the declared edition can change with it.

Where the mix cannot be avoided, keep the cross-edition interfaces few and boring: simple datasets, well-understood trigger options, and no reliance on features that one side may implement differently. It also helps to know where each edition's changes landed in the document set, which is easier to follow with a map of how the 61850 series is structured, since the parts covering the data model, SCL, and testing each moved at their own pace.

After Edition 2: Amendments Keep Coming

Edition 2 was not the end state. Later amendment cycles - commonly referred to as Edition 2.1 for several parts - continue to refine the model and the services, and devices in the field increasingly declare these newer revisions in their files. Nothing about the discipline changes: the declared schema version is still the ground truth, mixed revisions still call for explicit verification, and formal conformance testing is still the mechanism that turns should-interoperate into evidence a project can rely on.

For the long haul, write edition and schema version into your asset records alongside firmware, and make re-verification a standard step in the change process for protection and control devices. The substations that suffer least from edition drift are the ones where nobody has to rediscover what is installed every time a device is replaced, because the answer is already in the asset data and the current SCD.

Frequently Asked Questions