Skip to main content

Command Palette

Search for a command to run...

Part 3 — IEC 61850 Terminology & Nomenclature

Naming Rules, Data Types, and Path Grammar

Updated
12 min read
Part 3 — IEC 61850 Terminology & Nomenclature

From Parts 1 and 2, we now understand:

  • Why IEC 61850 exists

  • Where IEC 61850 systems are defined (SCL)

This part focuses on the language itself.

IEC 61850 is a formal system.
Every name, structure, and identifier follows strict rules.

Once you understand these rules, IEC 61850 stops being confusing and becomes deterministic.


Why IEC 61850 names are Verbose by Design

IEC 61850 names are intentionally verbose.

They trade brevity for:

  • Unambiguous meaning

  • Machine validation

  • Vendor interoperability

A name in IEC 61850 is not meant to be typed manually or remembered by humans.
It is meant to be parsed, validated, and exchanged reliably across tools and vendors.

Once you view names as structured identifiers rather than labels, their length starts to make sense.


Core Structural Terms

IEC 61850 data is organized hierarchically:

IED
└── Logical Device (LD)
    └── Logical Node (LN)
        └── Data Object (DO)
            └── Data Attribute (DA)
                └── Basic Data Attribute (BDA)

IED — Intelligent Electronic Device

Definition: A physical device that performs electrical functions.

Different types of IEDs:

  • Protection relay - protects electrical equipment (transformers, feeders, generators, motors)

  • Bay controller - controls and supervises one bay in a substation (a bay = one feeder, transformer, or line)

  • Meter - used for measurement and billing

  • RTU - used mainly for remote monitoring and control, especially in older or smaller substations

Examples:

  • Siemens SIPROTEC 5 relay

  • ABB REC relay

  • GE MMUH meter

  • SEL-351 protection relay

Naming rules

  • Unique within an SCL file

  • Case-sensitive

  • Opaque to the standard (no semantic meaning)

In SCL: Identified by <IED name="..."/>

Example:

<IED name="Relay_North_220" manufacturer="Siemens" type="Relay">

The IED name is the root of all IEC 61850 paths.


Logical Device (LD)

Definition: A functional grouping of related functions inside one IED.

Characteristics:

  • Not physical

  • Used for organization

  • Scoped only to the IED

Examples in one relay:

  • LD0 = Measurement device (MMXU, frequency measurement)

  • LD_PROT = Protection logic (PTOC, distance protection)

  • LD_CTRL = Control logic (breaker commands)

Why separate? Allows organizing functions logically, multiple MMS access points.

In SCL: Identified by <LDevice inst="0"/> etc.

Typical count: 1-5 LD per IED


Logical Node (LN)

Definition: A standardized function template that is predefined by IEC 61850 standard.

LN class names are defined by IEC 61850-7-4.

Standard LN classes:

  • MMXU = Measurement Unit (3-phase current, voltage, power)

  • PTOC = Phase Overcurrent (slower, sensitive)

  • PIOC = Phase Instantaneous OC (fast, less sensitive)

  • GGIO = Generic Input/Output (binary signals, alarms)

  • XCBR = Circuit Breaker (switching element)

  • PTYP = Protection Tripping Processor

  • LSSC = Load Shedding Scheme Selector

LN Naming Convention

[prefix][lnClass][lnInst]

Prefixes are optional and should be used sparingly.

Instance numbers: Each LN class can have multiple instances (MMXU1, MMXU2, PTOC1, PTOC2)

In SCL: Identified by <LN lnClass="MMXU" lnInst="1"/>

Real example:

<LN lnClass="MMXU" lnInst="1" prefix="">
  <!-- First measurement unit in this device -->
</LN>

<LN lnClass="MMXU" lnInst="2" prefix="">
  <!-- Second measurement unit (maybe for different 3-phase set) -->
</LN>

<LN lnClass="PTOC" lnInst="1" prefix="">
  <!-- First overcurrent protection function -->
</LN>

<LN lnClass="PTOC" lnInst="2" prefix="">
  <!-- Second overcurrent protection function (different zone) -->
</LN>

Data Structure inside Logical Nodes

Data Object (DO)

Definition: A group of related values (structured or simple).

Examples:

  • A – Current

  • V – Voltage

  • Pos – Position

  • Op – Operation

DO names are not free-form.
They are dictated by the LN’s CDC.

In SCL:

<LN lnClass="MMXU" lnInst="1">
  <DO name="A" type="CurrentM"/>
  <!-- DO "A" is 3-phase current -->

  <DO name="V" type="VoltageM"/>
  <!-- DO "V" is 3-phase voltage -->
</LN>

Data Attribute (DA)

Definition: An individual data element inside a DO.

Common attributes:

  • stVal – State value

  • q – Quality

  • t – Timestamp

  • ctlVal – Control value


Basic Data Attribute (BDA)

Definition: The atomic unit (can't be broken down further).

  • FLOAT32

  • INT16

  • BOOLEAN

  • ENUM

Example suffixes:

.mag.f
.stVal.e

In IEC 61850 paths, the final element (e.g., .f, .e) represents the typed member of a Basic Data Attribute, not an arbitrary suffix.


Data Types and MMS Representation

IEC 61850 data ultimately travels over the network using MMS (Manufacturing Message Specification).

While paths and names are logical constructs, every value must map to a concrete MMS data type.

Understanding these types is essential for:

  • Correct simulator behavior

  • OPC DA/UA mapping

  • Avoiding silent type mismatches

This section explains the naming-level data types, not MMS services or messages.


Primitive Data Types

These are the atomic building blocks used throughout IEC 61850.

IEC 61850 TypeMMS RepresentationTypical Use
BOOLEANMMS BooleanOn/Off, True/False
INT8 / INT16 / INT32MMS IntegerCounters, positions
UINT8 / UINT16 / UINT32MMS Unsigned IntegerStatus flags
FLOAT32MMS Floating PointMeasurements
ENUMMMS IntegerEnumerated states
UTC TimeMMS UtcTimeTimestamps
QualityMMS Bit StringData validity

These types appear at the BDA level.


Structured Data Types (CDC-Based)

IEC 61850 favors structured data over flat values.

Examples include:

  • Measured values

  • Control values

  • Status objects

These are composed of multiple primitive types.

Example (conceptual):

Measured Value (MV)
├── mag   → FLOAT32
├── ang   → FLOAT32
├── q     → Quality
└── t     → UTC Time

Each element maps to a corresponding MMS type.


Quality (q) — Special Case

The q attribute deserves special attention.

It is not a boolean and not an enum.

Quality is a structured data attribute that is mapped to a bit string in MMS, representing multiple flags simultaneously:

  • Valid / Invalid

  • Test mode

  • Operator blocked

  • Source substituted

  • Old data

Because it is a bitmask:

  • Multiple conditions can be true at once

  • Simulators must preserve individual flags

  • Simplifying it to “good/bad” loses information


Timestamps (t)

Time in IEC 61850 uses UTC time, not local time.

Characteristics:

  • Includes seconds + fractions

  • Includes time quality indicators

  • Independent of timezone

Accurate timestamp handling is essential for:

  • Event sequence analysis

  • Protection diagnostics

  • Reporting correctness


Enumerations and MMS

Enumerated values:

  • Are transmitted as integers

  • Gain meaning only through context (CDC + attribute definition)

Example:

stVal = 1

Has no meaning unless the receiving system knows:

  • Which CDC is used

  • Which enumeration applies

This is why naming + CDC + data type must be consistent.


Why this matters for Naming and Validation

At the nomenclature level:

  • The path identifies the data

  • The CDC defines the structure

  • The data type defines the encoding

All three must agree for the data to be semantically valid.

A path may be syntactically valid, but still invalid semantically if:

  • The wrong data type is used

  • The wrong MMS representation is assumed

  • Quality or timestamp is omitted


Common Data Classes (CDC)

A Common Data Class (CDC) is a strict schema that defines:

  • Which DOs exist

  • Which DAs exist

  • Their structure and semantics

CDCs are defined in IEC 61850-7-3.

Key insight: All devices use the same CDC definitions, enabling interoperability.

Major CDC Categories

Measurement

  • MV – Measured Value

  • CMV – Complex Measured Value

  • WYE – Phase quantities

  • DEL – Phase-to-phase quantities

Status

  • SPS – Single Point Status

  • DPS – Double Point Status

  • INS – Integer Status

  • ENS – Enumerated Status

Control

  • SPC – Single Point Control

  • DPC – Double Point Control

  • INC – Increment Control

  • BSC – Binary Step Control

Protection / Logic

  • ACT – Action

  • ACD – Action Detection

  • SEC – Security Enable

Identification / Description

  • DPL – Device Plate

  • LPL – Logical Node Plate

  • CUR – Curve

Example CDC (MV)

MV
├── mag (FLOAT32)
├── ang (FLOAT32)
├── q   (Quality)
└── t   (Timestamp)

Real example:

Path: IED_Relay1/LD0/MMXU1.A.phsA.cVal
cVal is an MV (Measured Value) CDC

Contains:
  .mag = 245.6 (current magnitude in amps)
  .ang = 0.0 (angle)
  .q = "good" (measurement quality is good)
  .t = 2024-11-30T12:34:56.123Z (timestamp)

CDC structure is mandatory and identical across vendors.

Note on Vendor Extensions
IEC 61850 allows vendor-specific extensions, but these are not portable.
For simulators and interoperable systems, standard CDCs should always be preferred.


Functional Constraints (FC)

A Functional Constraint (FC) defines the purpose and behavior of a Data Attribute. FC also determines whether data is reportable, buffered, or commandable in MMS.

FC does not appear in textual IEC 61850 paths.

Complete Functional Constraint List

FCMeaning
STStatus
MXMeasurement
COControl
SPSetting Parameter
CFConfiguration
DCDynamic Configuration
SGSetting Group
SESetting Group Editable
SVSampled Values
BRBuffered Reporting
RPUnbuffered Reporting
LGLog Control
GOGOOSE Control
GSGOOSE Status
EXVendor Extension

Some specifications reference ALL for filtering purposes, it is not used as a data attribute FC.

FC determines:

  • Read/write access

  • Reporting behavior

  • MMS object classification

Real-World Examples

MX — Measurement (read-only):

Path: IED_Relay1/LD0/MMXU1.A.phsA.cVal.mag
Value: 245.6 amps
FC: MX (measurement)
Access: Read-only (SCADA can only read, not write)

ST — Status (read-only):

Path: IED_Relay1/LD0/XCBR1.Pos.stVal
Value: "closed" (or "open")
FC: ST (status)
Access: Read-only (SCADA can only read)

CO — Control (write-only):

Path: IED_Relay1/LD0/XCBR1.Pos.ctlVal
Value: "trip" (command to breaker)
FC: CO (control)
Access: Write-only (only SCADA sends commands, doesn't read back)

CF — Configuration (read-only):

Path: IED_Relay1/LD0/PTOC1.Op.setVal
Value: 500.0 (amps)
FC: CF (configuration)
Access: Read-only (normally, until you enter config mode)

Why FCs Matter for Simulators

  • MX values: Cache frequently, update in real-time, display on HMI

  • ST values: Discrete updates only, trigger alarms on change

  • CO values: Require confirmation dialogs, audit logging, validation

  • CF values: Protected (read-only unless in config mode)

  • DC values: Can change, need thread-safe updates


Enumerated Data: ENUM, ENS, and ENC

Not all IEC 61850 data is numeric.
Many values represent discrete states, defined using enumerations.

It’s important to distinguish between the data type and the CDC that uses it.


ENUM — Enumerated Data Type

ENUM refers to the underlying data representation.

It is a basic data type where values are encoded as integers, but each integer has a standardized meaning.

Examples:

0 = open
1 = closed
2 = invalid
3 = reserved

ENUM is used internally by several CDCs.


ENS — Enumerated Status (CDC)

ENS is a Common Data Class used for status information that has more than two possible states.

Typical use cases:

  • Operating modes

  • Protection states

  • Device states

  • Multi-state indications

Characteristics:

  • Read-only

  • Uses ENUM as the underlying data type

  • Includes standard attributes like stVal, q, and t

Example:

IED_Relay1/LD0/PTOC1.Op.stVal
Value: 1
Meaning: Protection operated

ENC — Enumerated Control (CDC)

ENC is a Common Data Class used for control commands that select from multiple discrete options.

Typical use cases:

  • Mode selection

  • Control scheme selection

  • Multi-option commands (not just open/close)

Characteristics:

  • Write-capable

  • Uses ENUM as the underlying data type

  • Includes control-related attributes such as ctlVal, origin, and ctlTm

Example:

IED_Relay1/LD0/GGIO1.Mod.ctlVal
Value: 2
Meaning: Select operating mode 2

Key Distinction

TermWhat It Is
ENUMData type (integer with defined meanings)
ENSStatus CDC that uses ENUM
ENCControl CDC that uses ENUM

ENUM is the representation.
ENS and ENC are the contexts in which it is used.


Why This Matters

  • GOOSE and MMS transmit integers, not strings

  • SCADA and HMIs must map integers to meanings

  • Simulators must translate ENUM values correctly

  • Confusing ENUM with ENS/ENC leads to incorrect modeling

Correct handling of enumerated data is essential for interoperability and correct behavior.


IEC 61850 Naming Conventions

A valid IEC 61850 path follows:

<IED>/<LD>/<LN>.<DO>.<DA>[.<BDA>]

Rules

  • / separates hierarchy

  • . separates data elements

  • Case-sensitive everywhere

IED_Relay1     ≠ IED_relay1    (different!)
MMXU1          ≠ mmxu1         (different!)
phsA           ≠ phsa          (different!)

Example:

IED_Relay1/LD0/MMXU1.A.phsA.cVal.mag.f

Internally, these names map to MMS object models; the textual path is a logical representation, not a wire format. Conceptually, services are defined by ACSI (IEC 61850-7-2) and mapped to MMS on the wire.

Reserved vs User-Defined Names

In IEC 61850:

Reserved by the standard (must not be changed):

  • LN class names

  • DO names

  • DA names

  • CDC structures

  • FC assignments

User-defined (instanced):

  • IED names

  • LD names

  • LN instance numbers

  • Dataset names

  • Report control block names

If you rename a reserved element, interoperability is broken — even if the system appears to work locally.


Common Path Patterns

Reading Measurements (MX, read-only)

IED1/LD0/MMXU1.A.phsA.cVal.mag.f     = Phase A current (float)
IED1/LD0/MMXU1.A.phsB.cVal.mag.f     = Phase B current (float)
IED1/LD0/MMXU1.A.phsC.cVal.mag.f     = Phase C current (float)
IED1/LD0/MMXU1.V.phsA.cVal.mag.f     = Phase A voltage (float)
IED1/LD0/MMXU1.F.cVal.mag.f          = Frequency (float)

Reading Status (ST, read-only)

IED1/LD0/XCBR1.Pos.stVal.e           = Breaker position (enum: 0=open, 1=closed)
IED1/LD0/PTOC1.Op.stVal.e            = OC operated? (enum: 0=no, 1=yes)

Reading Configuration (CF, read-only)

IED1/LD0/PTOC1.Op.setVal.f           = OC pickup (float: 500 amps)
IED1/LD0/PTOC1.Str.setVal.f          = OC start (float: 450 amps)
IED1/LD0/PTOC1.Tr.ctlVal.f           = Trip delay (float: 0.5 sec)

Sending Commands (CO, write)

IED1/LD0/XCBR1.Pos.ctlVal.e = "trip"  = Trip command (enum)
IED1/LD0/XCBR1.Pos.ctlVal.e = "close" = Close command (enum)
IED1/LD0/PTOC1.Str.ctlVal.e = "block" = Block command (enum)

Path Validation Rules

A path is valid only if:

  1. IED exists

  2. LD exists

  3. LN class and instance exist

  4. DO exists

  5. DA exists in CDC

  6. BDA type matches

  7. Case matches exactly

Example validation:

Path: IED_Relay1/LD0/MMXU1.A.phsA.cVal.mag.f

✓ SCL has <IED name="Relay1"/>
✓ SCL has <LDevice inst="0"/>
✓ SCL has <LN lnClass="MMXU" lnInst="1"/>
✓ SCL has <DO name="A" type="CurrentM"/>
✓ CurrentM CDC has phsA (3-phase current)
✓ phsA has cVal.mag (magnitude)
✓ .f suffix indicates FLOAT32

Result: VALID path

Key Takeaways

✓ IEC 61850 uses a strict naming grammar
✓ CDCs define data structure
✓ FCs define data behavior
✓ Enumerations require semantic mapping
✓ Paths are deterministic and verifiable

Building an IEC 61850 Simulator in .NET

Part 4 of 4

A complete step-by-step guide to understanding IEC 61850 and building a fully functional simulator in .NET. Perfect for SCADA developers, substation engineers, automation testers, and anyone exploring digital substations.

Start from the beginning

Building an IEC 61850 Simulator in .NET

A Complete Series Introduction