When people first hear about IEC 61850, they often assume it is simply another communication protocol like DNP3, Modbus, or IEC 60870-5-104. But this assumption is incorrect. IEC 61850 is not just a protocol—it is a full engineering language designed to describe, model, and structure the functions that make up modern digital substations and power automation systems.
Where older protocols send numerical values with no context, IEC 61850 describes the meaning, behavior, and relationships of data using a rich, standardized, object-oriented model. It provides a self-describing environment so that devices can communicate and interoperate without custom mapping tables, point lists, or manual interpretation.
Understanding IEC 61850 as a language—rather than a protocol—is essential to understanding why it is the foundation of digital substations, process bus systems, and advanced protection schemes.
This article provides a clear, deeply technical explanation of how IEC 61850 is built, how it works, and why it is fundamentally different from traditional SCADA communication. It includes light citations from IEC 61850-5 and IEC 61850-6 to support key points.
Table of Contents
Why IEC 61850 Is Not “Just a Protocol”
Most legacy communication standards (DNP3, Modbus, IEC 101/104) were built around the idea of exchanging data points. A data point has a numerical index and a value, such as:
- Binary Input 12 = 1
- Analog Input 103 = 27.4
- Counter 33 = 15123
The protocol does not care what BI12 or AI103 represent—breaker position? voltage? frequency? alarms?—that information exists only in documentation and spreadsheets.
IEC 61850 takes the opposite approach. According to IEC 61850-5, the exchanged data must be standardized and grouped based on semantic content to ensure interoperability and understanding between devices .
This means the meaning of data is embedded into the communication model, not external to it.
IEC 61850’s Core Idea: Model the Substation First, Then Communicate
IEC 61850 begins with a fundamental idea:
Model the substation and its functions, then map this model onto communication services.
This model-driven approach is why IEC 61850 lasts for decades without becoming obsolete. The model (logical nodes, data objects, functions) remains stable, while mapping to protocols (MMS, GOOSE, Sampled Values) can evolve without altering the meaning of the data.
IEC 61850 defines:
- A vocabulary of functions → Logical Nodes
- Objects that represent real substation equipment
- Data attributes with clear, standardized meaning
- Behavior models for control, reporting, measurement, automation, and protection
- Communication services that operate on these models (ACSI, GOOSE, SV, reporting, logging)
Older protocols define how to send data.
IEC 61850 defines what that data is, what it means, and how it behaves.
The Logical Node Model: The Vocabulary of IEC 61850
What is a Logical Node?
A Logical Node (LN) is a functional block that represents a specific power-system function. IEC 61850-5 defines the logical node as the grouping of semantically related data that supports a particular automation or protection function in the power system .
logical nodes like XCBR or MMXU, each with data objects and attributes.
Examples:
| Logical Node | Function |
|---|---|
| XCBR | Circuit Breaker |
| CSWI | Switch Controller |
| PTOC | Time Overcurrent Protection |
| PDIS | Distance Protection |
| MMXU | Measurement Unit |
| RREC | Reclosing |
| XSWI | Disconnector |
Each logical node contains Data Objects (DOs), such as:
- Pos (position)
- OpCnt (operation counter)
- Amp (phase currents)
- PhV (phase voltages)
- Str (protection start)
- Tr (protection trip)
These DOs contain Data Attributes (DAs) like:
- stVal (status value)
- q (quality)
- t (timestamp)
- mag (magnitude)
This structure ensures semantic meaning:
- “XCBR1.Pos.stVal = TRUE”
means the breaker is closed, everywhere, in every device or vendor.
There is no need for point lists, mapping tables, or manual documentation.
Function-Based, Not Device-Based
IEC 61850 breaks down system functions (like line protection or transformer control) into smaller functional blocks that may be distributed across multiple IEDs. IEC 61850-5 explains how functions and sub-functions may be allocated freely to devices, and that the communication requirements depend on these functional interactions—not on physical device limitations .
Why is this important?
Because:
- A protection function can be distributed across relays from multiple vendors.
- Communication between these blocks is standardized and predictable.
- The engineering model is independent of the hardware platform.
In traditional systems, functions were tied to the physical relay.
With IEC 61850, functions exist as logical models that can be assigned anywhere.
IEC 61850’s Abstract Communication Service Interface (ACSI)
IEC 61850-7-2 defines the ACSI, which describes abstract communication services such as:
- Read / Write
- Report
- Log
- Control
- GOOSE publish/subscribe
- Sampled Values
These services are mapped to actual protocols:
- MMS over TCP/IP for client/server communication
- GOOSE over Ethernet multicast for peer-to-peer protection
- Sampled Values for analog waveform streaming
Because the model is independent of the transport, the messages are simply carriers of meaning.
The Role of SCL: The Grammar of IEC 61850
If Logical Nodes are the vocabulary, SCL (System Configuration Language) is the grammar that describes:
- which devices exist
- what functions they provide
- how they are interconnected
- how communication is configured
- what data is published or subscribed
- how the single-line diagram maps to IED functions
IEC 61850-6 defines SCL as a formal XML-based language to describe IED configurations, communication systems, and the substation topology itself .
SCL is the heart of IEC 61850 engineering.
SCL File Types and Their Purposes
IEC 61850-6 defines several SCL file types:
1. ICD — IED Capability Description
Describes all the functions and communication capabilities an IED supports.
2. CID — Configured IED Description
A project-specific configuration for one IED after engineering.
3. SCD — Substation Configuration Description
The complete substation model:
- Single line diagram
- All IEDs
- GOOSE/SV subscriptions
- Datasets and reports
- IP addresses, VLANs, redundancy
- Logical node allocations
This file describes the entire digital substation.
4. SSD — System Specification Description
Functional specification of the substation:
- Equipment
- Required logical nodes
- Single line diagram
- Function requirements
5. SED — System Exchange Description
Used when multiple projects, integrators, or vendors collaborate.
How SCL Acts Like Code
SCL files are machine-readable, deterministic engineering definitions. They act like software code that describes:
- the topology of the substation
- the logic and behavior of protection and control functions
- the communication behavior of IEDs
- the interactions between IEDs
For example, SCL can describe:
A CSWI logical node controlling breaker XCBR1:
<LN lnClass="CSWI" lnInst="1" lnType="CSWI1">
<DOI name="Pos">
<DAI name="ctlModel">
<Val>sbo-with-normal-security</Val>
</DAI>
</DOI>
</LN>
This defines:
- an instance of a switch controller
- its position control model
- the behavior expected during operation
SCL can configure GOOSE messaging:
<GSEControl
name="TripGOOSE"
type="GOOSE"
appID="0001"
confRev="1"
fixedOff="false"
datSet="TripDataset">
</GSEControl>
And define communication networks:
<SubNetwork name="StationBus" type="8-MMS">
<ConnectedAP iedName="IED1" apName="AP1">
<Address>
<P type="IP">192.168.1.10</P>
<P type="IP-SUBNET">255.255.255.0</P>
<P type="IP-GATEWAY">192.168.1.1</P>
</Address>
</ConnectedAP>
</SubNetwork>
This is not a protocol—it is a digital blueprint of the substation.
Modeling Devices, Topology, and Functions Together
IEC 61850-6 requires SCL to describe three interconnected models:
1. Substation Model
Defines the physical equipment:
- Breakers
- Disconnectors
- Busbars
- Transformers
- CT/VT
- Bays and voltage levels
And links Logical Nodes to this equipment.
2. IED Model
Defines:
- Logical Devices
- Logical Nodes
- Data Objects and Data Attributes
- Control blocks
- GOOSE/SV publishers
- Access points
- IP addressing
3. Communication Model
Defines:
- networks
- VLAN IDs
- redundancy (PRP/HSR)
- publisher/subscriber mappings
- routing and access paths
Because these three models are unified under SCL, the entire system becomes self-describing.
Behavioral Modeling: IEC 61850 Defines HOW Functions Work
IEC 61850 does not just describe what data exists—it describes how functions behave.
Examples:
Breaker Control Behavior
Defined by:
- control models (SBO, direct, SBOwES)
- interlocking requirements
- supervision functions
- quality and timestamp behavior
Protection Behavior
Defined by:
- Start (Str)
- Operate (Op)
- Time delay (OpDlTmms)
- Blocking signals
- Trip commands
Automation Behavior
Defined by:
- GOOSE subscription
- dataset triggers
- logic between LNs
IEC 61850 standardizes the internal relationships of functions, not just the messages they exchange.
GOOSE and Sampled Values: Communication Without Protocol Negotiation
GOOSE and SV represent IEC 61850’s commitment to high-speed automation.
GOOSE Messaging
- multicast over Ethernet
- 1–4 ms delivery
- replaces copper wiring
- deterministic
- used for:
- tripping
- interlocking
- protection scheme coordination
- auto-reclose
- transfer tripping
GOOSE messages carry semantic-rich objects, not raw bits.
Sampled Values
- digital current/voltage samples
- 4000 or 4800 samples per second
- used for process bus architectures
Again, the data carried has unified meaning due to the underlying model.
Self-Description: The Most Powerful Feature of IEC 61850
IEC 61850-5 states that the data model shall support self-description, meaning devices must be able to describe their own structure, capabilities, and data definitions to other tools or IEDs .
This eliminates:
- point lists
- manual mapping
- user error
- vendor lock-in
An IED can announce:
- its Logical Nodes
- its datasets
- its GOOSE messages
- its report control blocks
- its capabilities
- its supported services
This enables automatic engineering and interoperability.
Why IEC 61850 Works Across Vendors
Because all vendors must use:
- the same Logical Node definitions
- the same data structures
- the same semantics
- the same SCL structure
Interoperability is guaranteed by design.
IEC 61850-6 requires IEDs to provide ICD/IID files that describe their capabilities in a standardized way so any engineering tool can interpret them .
Why IEC 61850 Lasts for Decades
IEC 61850 separates:
- models (stable for decades)
- mappings (may evolve)
Today, mappings exist for:
- MMS (client/server)
- GOOSE
- Sampled Values
Tomorrow, mappings could exist for:
- TSN
- REST APIs
- Cloud-based services
- 5G URLLC
And the model will not need to change.
This future-proof design is why IEC 61850 is used in the world’s most advanced substations.
Putting It All Together: Why IEC 61850 Is a Language
IEC 61850 is a language because:
1. It has vocabulary
Logical Nodes, Data Objects, and Attributes.
2. It has grammar
SCL describes relationships, behavior, and structure.
3. It defines meaning
Semantics are embedded directly into the model.
4. It describes actions
Control models, protection actions, behavior rules.
5. It defines interactions
GOOSE, SV, reports, logs, client/server associations.
6. It provides a complete blueprint
The entire substation can be modeled in SCL.
This is far deeper than a communication protocol.
Conclusion
IEC 61850 represents a revolution in power-system communication. Instead of sending raw data, it provides a structured, semantic-rich language that describes the functions, equipment, topology, and behavior of an entire substation.
Through Logical Nodes, Data Objects, SCL files, GOOSE messaging, and Sampled Values, IEC 61850 creates a self-describing, interoperable, future-proof framework.
It is not simply a protocol—it is the foundational language of modern digital substations.