Part 3 — IEC 61850 Terminology & Nomenclature
Naming Rules, Data Types, and Path Grammar

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 ProcessorLSSC= 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– CurrentV– VoltagePos– PositionOp– 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 valueq– Qualityt– TimestampctlVal– 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 Type | MMS Representation | Typical Use |
BOOLEAN | MMS Boolean | On/Off, True/False |
INT8 / INT16 / INT32 | MMS Integer | Counters, positions |
UINT8 / UINT16 / UINT32 | MMS Unsigned Integer | Status flags |
FLOAT32 | MMS Floating Point | Measurements |
ENUM | MMS Integer | Enumerated states |
UTC Time | MMS UtcTime | Timestamps |
Quality | MMS Bit String | Data 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 ValueCMV– Complex Measured ValueWYE– Phase quantitiesDEL– Phase-to-phase quantities
Status
SPS– Single Point StatusDPS– Double Point StatusINS– Integer StatusENS– Enumerated Status
Control
SPC– Single Point ControlDPC– Double Point ControlINC– Increment ControlBSC– Binary Step Control
Protection / Logic
ACT– ActionACD– Action DetectionSEC– Security Enable
Identification / Description
DPL– Device PlateLPL– Logical Node PlateCUR– 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
| FC | Meaning |
| ST | Status |
| MX | Measurement |
| CO | Control |
| SP | Setting Parameter |
| CF | Configuration |
| DC | Dynamic Configuration |
| SG | Setting Group |
| SE | Setting Group Editable |
| SV | Sampled Values |
| BR | Buffered Reporting |
| RP | Unbuffered Reporting |
| LG | Log Control |
| GO | GOOSE Control |
| GS | GOOSE Status |
| EX | Vendor 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, andt
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, andctlTm
Example:
IED_Relay1/LD0/GGIO1.Mod.ctlVal
Value: 2
Meaning: Select operating mode 2
Key Distinction
| Term | What It Is |
| ENUM | Data type (integer with defined meanings) |
| ENS | Status CDC that uses ENUM |
| ENC | Control 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 elementsCase-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:
IED exists
LD exists
LN class and instance exist
DO exists
DA exists in CDC
BDA type matches
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



