What Is an IEC 61850 Logical Device?

Back to Blog

A Container Between the IED and Its Functions

IEC 61850 needs a middle layer between a physical box and the many functions it performs, and the logical device is that layer. It lets a vendor split one IED into functional groupings - a control logical device, a measurement logical device, a protection logical device - so that the object model reflects how the substation engineer thinks about the bay rather than how the firmware happens to be organized. The name of the logical device becomes part of every object reference beneath it, which is why the grouping matters for integration and not just for tidiness.

Two logical nodes are mandatory in every logical device. LLN0, the Logical Node Zero, holds settings that apply to the whole logical device and, importantly, the control blocks that publish its data - report control blocks, GOOSE control blocks, and dataset definitions typically live here. LPHD describes the physical device that hosts the logical device: health, nameplate, and proxy status. Everything else in the logical device is application: the protection, control, or metering nodes.

Why the Grouping Shapes Every Reference

An IEC 61850 object reference is a dotted path, and the logical device is the second element after the IED name. A client subscribing to a breaker position navigates IED name, then logical device, then the XCBR logical node, then the data object and attribute. Get the logical-device name wrong and the reference resolves to nothing, so the SCL file that describes the device is the authoritative source for these names - never guess them.

Because the publishing control blocks sit in LLN0 of a logical device, the logical device is also the natural unit for organizing what a client reports on. When you plan reporting, you are effectively deciding which logical devices' datasets a client subscribes to, a design that connects directly to how GOOSE messages and MMS reports are configured. The whole hierarchy - IED, logical device, logical node, data - is the concrete form of the abstract model in the IEC 61850 standard.

Anatomy of a Full Object Reference

It helps to walk one reference end to end. Suppose a bay controller is named Bay1 and presents a measurement logical device whose instance name is MEAS. Inside it, the standard measurement logical node class MMXU, instance 1, carries the data object TotW for total active power, whose magnitude lives in the data attribute mag.f. The complete reference a client asks for is Bay1MEAS/MMXU1.TotW.mag.f, read under the MX functional constraint that groups measured values. Every element of that path except the IED name and the logical device instance comes from the standard's object model; the first two are configuration choices, which is exactly why they must come from the SCL description rather than guesswork.

Laid out level by level, the same reference decomposes like this:

Hierarchy level	Element in the example
IED name	Bay1
Logical device	MEAS
Logical node	MMXU1
Data object	TotW
Data attribute	mag.f

Notice that the logical device is the only level in the middle whose name is pure configuration: MMXU, TotW, and mag.f are fixed by the standard's logical node classes and common data classes, while MEAS is whatever the engineer or vendor chose. That asymmetry is why an integrator can predict most of a reference from the standard but must confirm the logical device portion for every single project.

Working From the SCL File, Not the Nameplate

The device's SCL description is where logical device names actually live. An ICD file is the vendor's capability template, a CID is the configured instance for one physical device, and an SCD describes the whole substation; the roles are laid out in the guide to SCL file types. For building references, the CID or SCD is authoritative because it reflects what was actually engineered for the installed device, including any renaming that happened along the way.

Renaming matters more than people expect. SCL allows a functional ldName to override the product-style logical device instance, so the name a client sees on the wire can differ from what the vendor's template used. If a reference that worked on the bench fails on site, a changed logical device name after a configuration update is one of the first things to check. Re-export the CID after any engineering-tool change and treat that export as the single source of truth for the client configuration.

Commissioning Checks That Catch LD-Level Mistakes

Most integration failures at this layer are name mismatches, and a short discipline eliminates them:

1. Browse the live IED with a test client and list every logical device it presents.
2. Compare that list against the CID or SCD, name by name, before writing a single reference.
3. Open LLN0 in each logical device you plan to use and confirm the datasets and report control blocks you expect are actually present.
4. Enable one report or poll one value per logical device as a smoke test before doing bulk configuration.
5. Record the verified names in the project documentation so the next engineer does not repeat the exercise.

The browse-versus-file comparison is the step people skip and regret. A firmware update or a re-engineered configuration can change the logical device list without anyone updating the client side, and the symptom - references that silently resolve to nothing - looks exactly like a communications problem until you put the live browse and the SCL side by side and compare names.

Frequently Asked Questions