Standards

IEC 61850 Edition 1 vs Edition 2: read the ICD before you argue

2026-10-29 · 8 min read

Sooner or later a project meeting produces the sentence "that device is only Edition 1" and the room splits. Nine times out of ten the answer is already in a file you have: the ICD or CID that the vendor supplied. What it does not tell you is which behaviours actually differ — and that is what decides whether the device is a problem.

Step one: ask the file, not the datasheet

Every SCL document declares its edition in the root element and its capability envelope in a Services block. Two attributes and one element answer the first question in under a minute.

• The root version/revision pair identifies the SCL schema edition. 2003 with a letter revision is the family in use across Edition 1 and Edition 2 devices; the letter and the element structure tell you which.
• The per-IED <Services> block is the part that matters operationally: how many datasets may be configured, how many report control blocks exist, whether dataset names are configured or fixed, whether buffering is available.
• If a device advertises ConfDataSet max="0", you cannot configure datasets on it at all — that single attribute has killed more integration plans than any edition dispute.

<SCL xmlns="http://www.iec.ch/61850/2003/SCL"
     version="2003" revision="B" ...>
  <Header id="ACME_BCU_1" version="2.0" revision="R3" .../>
  <IED name="BCU1">
    <Services>
      <ConfDataSet max="32" maxAttributes="512"/>
      <ConfReportControl max="16"/>
      <ReportSettings cbName="Conf" datSet="Conf" rptID="Conf" optFields="Conf"/>
      <GOOSE max="8"/>
      <FileHandling/>
    </Services>
    ...
  </IED>
</SCL>

What actually changes behaviour

Ignore the version number for a moment and look at these four areas. They are where a mixed fleet produces real defects rather than philosophical debate.

• Control models. Edition 1 devices often implement only direct control with normal security. Edition 2 expects the fuller family of control models, including the enhanced and time-activated variants. If your master assumes select-before-operate against a device that only supports direct control, the failure is in the control flow, not the protocol.
• Reservation and ownership. Reservation of control and ownership of report control blocks are Edition 2 concepts. A device that does not implement them is not "broken" — it simply cannot arbitrate two clients, and your commissioning tool has to know that.
• Configured versus creatable. Configured datasets and report control blocks are defined in the file; creatable ones are created at runtime within the advertised limits. Both are legitimate. Mixing them up produces the classic "it works in the lab, not on site" because the lab configured it and the site assumed it was creatable.
• SCL structure. Later editions add elements for equipment hierarchy and logical device naming that an older parser will either ignore or trip over. A parser that silently drops unknown elements is fine; one that validates strictly and rejects the file is not.

Running a mixed-edition station

This is the normal case, not the exception: a new bay controller next to a 2012 relay. Three rules keep it workable.

• Model the lowest common denominator explicitly. If most of the fleet is direct control only, do not design a select-before-operate workflow that only works on the newest device.
• Test against real devices, not against simulators configured to be modern. A simulator that implements everything hides exactly the gaps you are trying to find.
• Capture both sides during acceptance. When two devices disagree, the bytes decide, and the argument ends faster.

The practical checklist

Before the next meeting, produce these four things and the edition question usually resolves itself:

• The version/revision from each device's SCL file, in one table.
• The <Services> limits per device, especially dataset and report control block counts.
• A list of the control models each device actually supports, verified by reading the model rather than the datasheet.
• One sentence per device: what breaks if we assume Edition 2 behaviour here?

Questions that come up

Does Edition 2 break Edition 1 devices?

No. The standard is designed for coexistence, and a well-built client handles both. What breaks is an implementation that assumes every device behaves like the newest one it was tested against.

Do we need Edition 2 to sell into Europe?

Buyers differ. What they consistently want is a device whose declared capabilities match its behaviour, plus evidence you can produce when the two disagree. Edition 2 gives you more of the mechanisms they may ask for; it does not substitute for testing.

Our stack says it supports both editions. Is that enough?

No. "Supports both" is a claim about code paths, not about your device. The device declares its capabilities in its own Services block, and that declaration is what the customer will test against.

Keep reading