IEC 61850 Logical Node Naming (LLN0, LPHD)

Back to Blog

Reading a Logical Node Name

A logical node instance name is assembled from up to four elements. First an optional prefix, chosen by the engineer to indicate the node's role in the application (something like PROT or CTRL). Then the mandatory four-character class name from the standard - PTOC, XCBR, MMXU - which fixes what the node does. Then an instance number to distinguish multiple nodes of the same class in one logical device (PTOC1, PTOC2 for two overcurrent stages). Finally an optional suffix. So PROT_PTOC1 reads as the first time-overcurrent protection node in the protection grouping.

The instance number is important: a device can have many nodes of the same class, and only the instance number tells them apart. Two XCBR nodes on a bay controller might be XCBR1 and XCBR2 for two breakers. When you build an object reference or subscribe to a dataset, you need the exact instance, which is why the SCL file - not a guess - is the source of the real names.

The Two Nodes Every Logical Device Has

Two logical nodes are mandatory in every logical device, and both have fixed names. LLN0, the Logical Node Zero, is special: it represents the logical device as a whole and carries device-wide settings plus the control blocks that publish data - report control blocks, GOOSE control blocks, and dataset definitions typically live in LLN0. It has no instance number because there is exactly one per logical device.

LPHD, the Physical Device node, describes the hardware hosting the logical device: its health, nameplate, and proxy indication. Between them, LLN0 and LPHD give a client the housekeeping it needs before touching the application nodes. Recognizing these two names on sight speeds up reading any device model, and they sit at the base of the naming scheme that runs through the whole logical node layer.

From Node Name to Full Object Reference

The logical node name is the middle of a longer address. A complete object reference stacks the IED name and logical device instance, then the logical node, then the data object and data attribute: something like STN1Feeder1/PROT_PTOC1.Str.general. Read right to left, that is the general start flag, of the Str data object, in the first prefixed PTOC instance, hosted in the Feeder1 logical device of the IED named STN1. Every layer of that reference comes from the engineering configuration, so the reliable way to build one is to copy it from the exported file rather than compose it by hand and hope the instance numbers match.

One more piece rides along in real communications: the functional constraint, which tags whether an attribute is a status value, a measurement, a setting, or configuration data. When a client browses a device or a dataset lists its members, that constraint appears next to the reference, and a mismatch there is a common reason a value cannot be read or does not trigger reports as expected. Treat the pair - full reference plus constraint - as the complete address of any point you integrate.

What the First Letter Tells You

The four-letter class names look opaque until you know the first letter encodes the functional family, which turns browsing an unfamiliar device from guesswork into reading.

First letter	Family	Example
P	Protection functions	PTOC - time overcurrent
X	Switchgear	XCBR - circuit breaker
M	Metering and measurement	MMXU - measurement unit
C	Control	CSWI - switch controller
G	Generic functions	GGIO - generic I/O
L	System nodes	LLN0, LPHD

Two families earn special attention in integration work. GGIO, the generic I/O node, is the escape hatch vendors use for points that have no dedicated class; a device model heavy with GGIO is telling you the semantic meaning of each point lives in project documentation, not in the standard. And the L family is the housekeeping layer: LLN0 and LPHD, plus supervision nodes for monitoring communications and hardware, which is where you look when the question is device health rather than process state.

A Worked Walkthrough: Two Breakers, One Bay

Consider a bay controller that operates two breakers. One legal model gives it XCBR1 and XCBR2 side by side, each paired with its own switch controller, CSWI1 and CSWI2. Another equally legal model uses prefixes to carry the bay-plan designations, so each breaker gets its own prefixed instance and the prefix, not the instance number, does the distinguishing. Both are conformant, both browse cleanly, and both will burn an integrator who assumes the other convention - a control mapped to the wrong XCBR instance passes every syntax check and operates the wrong breaker. The exact names in the delivered SCL are the only truth worth trusting, and confirming a control-to-breaker mapping end to end is a commissioning test, witnessed per site procedure, not a desk exercise.

Prefixes, Instances, and Project Discipline

The standard fixes the class; the project chooses prefixes and instance numbers. That freedom is useful and dangerous. Useful, because a consistent convention - the same prefix meaning the same role in every bay - makes an unfamiliar configuration readable at speed. Dangerous, because tools sometimes renumber instances when a configuration is regenerated, and every client mapping, report subscription, and peer-to-peer connection that referenced the old name breaks silently. Fix a naming convention early, write it down, and treat any rename after subscribers exist as a configuration change that requires re-verification of everything downstream.

When you inherit a system without documentation, the exported configuration files are the ground truth for names - a browsing tool can mislead by caching, but the file the device actually loaded cannot. Comparing the names in the file against what a live client sees is a fast integrity check, and knowing the roles of ICD, CID, and SCD files tells you which file reflects the device as it is configured today rather than as it left the factory.

Frequently Asked Questions