Overview of

IEC 61850

COMMUNICATION STANDARD FOR SUBSTATION AUTOMATION

The Engineering Value of IEC 61850

Though originally developed for substation automation, IEC 61850 now serves as the primary communications blueprint across modern power systems, distributed energy resources, power generation, hydroelectric plants, wind power and other electrical automation applications.

The shift toward IEC 61850 stems from the operational headache of managing legacy power architecture. Just like in industrial automation, the world of electrical power developed with a host of incompatible standards, inconsistent data representations, vendor lock-in and an inability to easily get systems to work together.

The IEC 61850 standard solves a problem that will sound familiar to anyone who has integrated a factory floor. A substation contains protection relays, breaker controllers, meters, transformers, tap changers, battery monitors and remote terminal units. Historically, each vendor — SEL, GE, ABB, Siemens, Schneider — shipped its own protocol, and the utility implemented all of them.

Worse, the fast signals between devices weren’t networked at all. A relay that needed to tell a breaker to trip did it over a dedicated copper pair. A substation with a few dozen protection schemes could contain miles of control cable, every strand of which had to be designed, pulled, landed, labeled, tested and maintained.

Just like factory floor automation, the result was predictable: difficult integrations, extensive wiring and systems that became increasingly complicated to modify and maintain. The goal was interoperability, but the situation was far from it.

IEC 61850 provides a mechanism to solve these problems:

• The multi-vendor problem is solved by a standardized object model, so that a circuit breaker looks like a circuit breaker no matter whose relay is reporting it
• The copper problem is solved by GOOSE, an IEC 61850 publish/subscribe message architecture that is fast enough to carry a trip signal

An IEC 61850 system doesn’t need to understand every manufacturer’s proprietary representation of voltage, current, breaker status or protection functions. Those concepts are represented using standardized IEC 61850 models.

How IEC 61850 Works

IEC 61850 is an architectural standard and data modeling framework. Think of it as the “OPC UA” of the electrical industry. Instead of just defining bits on a wire, IEC 61850 standardizes information models, names, communication services and engineering methods so that devices can exchange both data and the meaning of that data.

By separating data definitions from network transport, IEC 61850 provides true interoperability, ensuring that devices share a complete, mutual understanding of what data means. It accomplishes this through four core pillars: contextualization, communication services, communication mappings and system configuration language.

Information Models (Contextualization)

An information model defines what information means. Providing context like this is often called “Contextualization” in manufacturing automation systems and is vital to support manufacturing AI systems.

While legacy protocol pass raw data without meaning, which requires manual mapping, IEC 61850 embeds self-describing context directly into the data.

Instead of telling another device simply:
“Register 40017 = 482.3”
IEC 61850 identifies information as something meaningful, such as:
“Phase A voltage measurement = 482.3 volts.”

That standardized context is one of the most important differences between IEC 61850 and traditional industrial protocols.

Communication Services

Communication services define what devices can do with that information, such as reading data, issuing equipment control commands and generating change-of-state reports.

Communication Mappings

Communication mappings define how communication services are transported over networks. They translate abstract services into concrete network transports, mapping client/server data to the Manufacturing Message Specification (MMS) over TCP/IP and high-speed protection messaging directly to Ethernet multicast (GOOSE).

System Configuration Language (SCL)

System Configuration Language (SCL) is a standardized XML-based mechanism for describing devices, communications and system configurations, eliminating manual data entry across multi-vendor engineering tools.

IEC 61850-6 defines SCL specifically so that IED configuration tools and system engineering tools from different manufacturers can exchange configuration information in a compatible format.

You will encounter several SCL-related file types in IEC 61850 systems, including files that describe device capabilities, configured devices and complete system configurations. For someone implementing an IEC 61850 gateway, SCL import can eliminate a tremendous amount of manual data entry by allowing the device configuration and data model to be imported directly.

IEC 61850 Architecture

IEC 61850 is a comprehensive architectural framework that defines how hardware components present data, how that data is structured and how engineering configurations are passed across the network.

The Hardware Layer: Intelligent Electronic Devices (IEDs)

At the hardware layer, an IEC 61850 system is built on Intelligent Electronic Devices (IEDs). An IED is simply an intelligent device used in an electrical automation system. Rather than relying on simple, single-purpose devices, an IED is a microprocessor-based controller that processes inputs, executes localized logic and communicates natively over Ethernet.

In an IEC 61850 architecture, IEDs replace legacy hardware relays and discrete controllers.

Examples include:

• Protection and Control: Protective relays, breaker controllers and bay controllers
• Measurement and Monitoring: Power meters, power quality meters, battery monitors and digital current/voltage merging units
• Substation and Plant Automation: Remote terminal units (RTUs), transformer controllers and intelligent switchgear

An IEC 61850 IED exposes its functions and data using the standardized IEC 61850 information model and communication services supported by that device. This ensures that no matter where an IED originates from, the system interacts with its underlying data through a universal set of communication services.

The Data Hierarchy

To eliminate manual register mapping, the IEC 61850 data model uses a strict hierarchy. Every piece of information in a substation has an explicit address that defines its context:

• Physical Device: The actual box with a nameplate and an IP address.
• Server: The communication entity inside that box. One physical device hosts one server; the server owns the address space that clients browse.
• Logical Device: A grouping of related functions inside the server. A single relay might expose separate logical devices for protection, control, measurement and disturbance records. Logical devices exist so that a physical box can present itself as several functional units, which matters enormously for gateways and RTUs that front-end a whole row of legacy equipment.
• Logical Node (LN): The heart of the model. A logical node is the smallest standardized chunk of function: a circuit breaker, an overcurrent protection element, a measurement unit, a current transformer.

Datasets, Reports and Logs

Individual reads are the least interesting thing a 61850 server does. The real work happens through datasets. Datasets are ordered collections of data attributes gathered from anywhere in the model, defined once and referenced by name.

A dataset on its own does nothing. It gets attached to a control block that determines how it’s delivered:

• Report Control Blocks: Send the dataset to a client over MMS when something in it changes, on a periodic cycle or on demand. Buffered report control blocks queue events while a client is disconnected and deliver them on reconnect, so a dropped SCADA link doesn’t lose the event sequence. Unbuffered ones don’t.
• Log Control Blocks: Write the dataset into an on-device journal that a client can query later.
• GOOSE Control Blocks: Publish the dataset as a multicast GOOSE message.
• Sampled Value Control Blocks: Publish it as a Sampled Value stream.

Reporting is configurable down to the trigger option (e.g., data change, quality change, data update, integrity period) and includes a per-report sequence number so a client can detect gaps. It’s a genuinely better event mechanism than the change-of-state polling most industrial protocols rely on.

The Three Protocols of IEC 61850

This is where new users get tripped up. IEC 61850 itself is not a protocol, but a data model delivered over three very different mappings, chosen by what the traffic needs to do: MMS, GOOSE and Sampled Values (SV). While not technical protocols, they are commonly referred to as the “three protocols of IEC 61850” because they specify how data packets are formatted and transported across the network.

Manufacturing Message Specification (MMS): The Client/Server Mapping

MMS is the Manufacturing Message Specification, ISO 9506, and it is genuinely old — it came out of the MAP/TOP work of the 1980s and was originally intended as a universal manufacturing protocol. It never caught on, but it had one property the 61850 authors needed: it can carry arbitrary named object structures rather than fixed message layouts. Rather than invent a new one, IEC’s Technical Committee 57 (TC 57) mapped the abstract services of part 7-2 onto MMS and ran it over TCP/IP.

MMS is what a substation HMI, a gateway or an engineering tool uses. It handles association (connecting to a server), browsing the address space, reading and writing values, control operations with select-before-operate, report subscription, log retrieval and file transfer, which is how you pull a COMTRADE disturbance record off a relay. It’s the only one of the three mappings that is confirmed, connection-oriented and routable out of the box, so it’s also the mapping that crosses the boundary out of the substation toward the control center.

Generic Object Oriented Substation Event (GOOSE): The Replacement for Copper

Generic Object Oriented Substation Event, or GOOSE, is the piece of IEC 61850 that changes how substations get built, because it is fast and reliable enough to carry a protection trip.

A GOOSE publisher multicasts a dataset directly onto Ethernet without an IP, TCP or any transport layer at all. Subscribers filter on the multicast MAC address and the application ID. There’s no connection, no acknowledgment and no retry in the usual sense. Reliability is achieved by repetition, where a publisher retransmits the same message continuously, and the retransmission interval is the whole trick.

In steady state, a GOOSE message repeats slowly, every second or two. When a value in the dataset changes, the publisher immediately sends a burst, then retransmits with a rapidly increasing interval until it settles back to the steady-state rate.

Sampled Values (SVs): Digitizing the Current Transformer (CT) and Voltage Transformer (VT)

Sampled Values (SVs) do for the analog measurement path what GOOSE does for the trip path. Instead of running current and voltage secondaries as analog signals from the switchyard into the relay room, a merging unit at the equipment digitizes the waveform and multicasts it.

Typical rates are 80 samples per cycle for protection (4,000/sec at 50 Hz, 4,800/sec at 60 Hz) and 256 samples per cycle for metering and power quality. Every sample carries a sample count and a synchronization flag, and every publisher must be locked to a common time reference. This is the one place in IEC 61850 where precise time synchronization isn’t optional. Two merging units feeding a differential protection scheme must sample the same instant, or the protection sees a difference that isn’t there.

IEC 61850 Communication Model: Client/Server vs. Publisher/Subscriber

Understanding how IEC 61850 handles traffic comes down to recognizing that it supports two fundamentally different communication models:

• Client/Server (MMS): With MMS, a client establishes communications with an IEC 61850 server and exchanges information with it.
• Publisher/Subscriber (GOOSE & SV): With GOOSE and Sampled Values, information is published onto the network for subscribers that have been configured to consume it.

These mechanisms solve very different problems. A SCADA system retrieving measurements from a relay has very different communication requirements than a protection relay notifying another relay that a breaker must trip. IEC 61850 includes services designed for both.

How IEC 61850 Compares to Other Industrial Protocols

Utilities rarely rely on a single protocol. A typical substation utilizes IEC 61850 for internal device communication while relying on DNP3[EW24.1] or IEC 60870-5-104 to communicate with the control center, because that’s what the SCADA master speaks and the WAN link is narrow.

The table below compares IEC 61850 alongside the protocols with which it most often shares a substation.

IEC 61850 and OPC UA

Against OPC UA, the comparison is closer than it looks, since both are object-oriented, both are self-describing, and both separate the information model from the transport. The difference is scope and depth.

OPC UA gives you a modeling framework and leaves the domain vocabulary to companion specifications. IEC 61850 ships the power-industry vocabulary already written, in exhaustive detail, along with the two hard-real-time protocols that OPC UA has no equivalent for. Where they meet, there’s a defined mapping between the 61850 model and OPC UA, which is how substation data most often reaches an enterprise historian.

Advantages of IEC 61850

• Self-Describing Data: A client can browse a device it has never seen and understand what it found. No register maps to lose.
• Dramatically Less Copper: GOOSE replaces hardwired interlocking and tripping; Sampled Values replace analog CT and VT runs. Fewer cables, smaller panels, faster construction, less to maintain. Copper is replaced with fiber optic or Ethernet.
• Supervised Communication: Every GOOSE link continuously proves it’s alive. Hardwired circuits don’t.
• Genuine Multi-Vendor Capability: A breaker is XCBR regardless of whose relay reports it.
• Portable Configuration: SCL makes the design portable, reviewable and version-controlled.
• Quality and Time On Every Value: Clients always know whether to trust the data.
• Room to Grow: The same model now covers wind, solar, storage, hydro and EV charging.

Disadvantages of IEC 61850

• Steep Learning Curve: Dozens of parts, three protocols and an XML schema. Nobody absorbs this in an afternoon, and the training investment is real.
• Expensive, Vendor-Specific Tools: System configuration tools, IED tools and test sets all cost money, and their SCL interpretations don’t always agree.
• Risk of Surprises: Certified doesn’t mean interoperable. Optional features and legal-but-divergent choices still produce integration surprises.
• Network Becomes Critical Infrastructure: Ordinary industrial Ethernet practice isn’t sufficient for a process bus. You need managed switches, VLAN and multicast design, PRP or HSR redundancy, and PTP-aware hardware.
• Security Adoption: IEC 62351 exists, but adoption is thin, and GOOSE spoofing remains a practical concern on any network an attacker can reach.
• Requires Advanced Troubleshooting: A meter and a test set no longer tell you what’s happening. Diagnosing a failed protection scheme means reading packet captures.
• Modernization Timelines: Existing substations are full of legacy equipment, and getting it into a 61850 world means gateways, mapping and careful staging.

Connecting IEC 61850 to Industrial Automation Systems

IEC 61850 is common in electrical automation. Modbus, EtherNet/IP, PROFINET, BACnet, OPC UA and other technologies are common in industrial automation. Increasingly, those two worlds need to exchange data. A PLC may need:

• Breaker status
• Voltage
• Current
• Frequency
• Power
• Energy
• Power quality
• Alarm information

An IEC 61850 system may also need data originating in industrial controllers, meters or other automation devices.

That creates an ideal application for an IEC 61850 protocol gateway. A gateway can sit between the two systems, communicate with IEC 61850 devices on one network and present the required information to the industrial automation system using the protocol it already understands.

It does not require custom communications code, a PC running protocol-conversion software, or a PLC programmer to become an IEC 61850 expert.

The IEC itself recognizes this type of architecture. IEC TR 61850-80-5:2026 provides a framework for gateway-based information exchange between IEC 61850 and Modbus systems.

IEC 61850 Frequently Asked Questions