How IEC 61850 Coexists with the Ethernet Protocols You Already Know

Two questions I’ve hated since I first put a hard hat on:

“John, what is the best protocol?”

“John, what PLC should I use?”

Wrong question guys. I could probably just write a whole article on that. PLCs and protocols are tools, and asking which tool is best is how you end up using a torque wrench as a hammer.

The better question is what each one was built to do. So let’s line IEC 61850 up next to the protocols you already run and see where it actually fits.

IEC 61850 vs. Industrial Ethernet Protocols

	IEC 61850	Modbus	DNP3	EtherNet/IP & PROFINET	OPC UA
How data is identified	Standardized named model	Register numbers	Typed point indexes	Vendor-defined tags and I/O assemblies	Named node model
Tells you what it holds	Yes, plus System Configuration Language (SCL)	Not at all	Somewhat	Somewhat	Yes
Device-to-device messaging	Yes, via Generic Object Oriented Substation Event (GOOSE)	No	Limited	Yes, cyclic I/O	Yes, PubSub
Fast enough to trip a breaker	Yes	No	No	Fast, but not built for protection	No
Quality and time on values	Every attribute	None	Most points	Limited	Every value
Bandwidth appetite	Heavy	Featherweight	Light	Moderate to heavy	Moderate
Where it lives	Inside the substation	Nearly everywhere	Substation to control center	Machine and cell control	Plant to enterprise

IEC 61850 vs. Modbus

This comparison is almost unfair, and Modbus still wins more often than you’d think.

Modbus knows nothing. It moves numbered registers and that’s the entire feature list. No data types worth the name, no timestamps, no quality, no self-description and no standard way to find out what’s in a device.

It is the single most successful industrial protocol ever written, because when you need sixteen registers out of a flow meter, “knows nothing” is exactly right. It’s free, it’s trivial, it’s in everything and any engineer can get it working before lunch.

IEC 61850 would be an absurd choice for trying to pull a few raw registers out of a basic flow meter. Likewise, Modbus would be an absurd choice for protection and control in a transmission substation. Nobody is confused here.

IEC 61850 vs. DNP3

Now we’re comparing siblings. Both IEC 61850 and DNP3 come out of IEC TC 57. Both serve electric utilities. They are not competing.

DNP3 was designed for narrow and unreliable wide-area links. It is frugal in a way IEC 61850 never even attempts. It features efficient event reporting, unsolicited responses, good time synchronization and it will run over a radio link that barely qualifies as a network.

IEC 61850 assumes switched Ethernet and plenty of it. It is not going over a leased serial circuit to a rural recloser, and it was never meant to.

So, utilities run both. IEC 61850 inside the substation fence where the bandwidth lives, DNP3 or IEC 60870-5-104 heading out to the control center where the SCADA master is already listening and the WAN pipe is skinny. That split is the normal architecture, not a compromise.

IEC 61850 vs. EtherNet/IP and PROFINET

This is the comparison our customers find most useful, and the one nobody writes about. It helps to look at them across three distinct areas:

Network Transport

Structurally, Generic Object Oriented Substation Event (GOOSE) has a lot in common with PROFINET RT. Both dump frames straight onto the Data Link Layer (Layer 2) and skip the IP stack entirely to save time. EtherNet/IP’s implicit messaging takes a slightly different road with UDP multicast and a producer/consumer model, but the instinct is the same: normal request/response is too slow, so publish it and let the consumers sort it out.

What They Model

EtherNet/IP and PROFINET model machines containing assemblies, modules, slots and I/O data sized to your drive or your remote I/O rack. The vocabulary is defined by the vendor and the GSDML or EDS file. By contrast, IEC 61850 models an electrical power system, with a vocabulary written once by committee and shared by every vendor.

Defining “Fast”

For factory protocols, fast means holding a deterministic cycle so a servo doesn’t lag. For IEC 61850, fast means getting a trip from one relay to another inside four milliseconds, on a network that may be carrying thousands of Sampled Value frames per second at the same time.

There’s also a philosophical split worth noting. In EtherNet/IP and PROFINET, configuration lives in your PLC project. In IEC 61850, configuration lives in an SCL file — an XML description of the devices and the whole system that can be reviewed, diffed, version-controlled and handed between vendors’ engineering tools. We have nothing that clean on the factory floor, and frankly we should.

IEC 61850 vs. OPC UA

This is the closest race in the field. Both IEC 61850 and OPC UA are object-oriented, self-describing and deliberately separate the information model from the transport. If you understand one, you’re halfway to the other.

The split is scope versus depth.

• OPC UA hands you a modeling framework and leaves the industry vocabulary to companion specifications that get written later, by somebody else, at whatever pace that industry manages. It’s magnificently general.
• IEC 61850 went the other way. It arrived with the entire power-industry vocabulary already written down to exhausting detail, plus two hard real-time protocols OPC UA has no equivalent for. You cannot trip a breaker with OPC UA. That was never the assignment.
  The two meet in the middle anyway. There’s a defined mapping between the IEC 61850 model and OPC UA, and that mapping is how substation data most often finds its way into an enterprise historian.

The Protocol War is the Wrong Conversation

Nobody picks just one. That’s the honest conclusion, and it’s the same conclusion I reach about data centers, machine shops and packaging lines.

A real facility runs IEC 61850 in the electrical room, DNP3 out to the control center, Modbus on half the meters, EtherNet/IP or PROFINET on the production equipment, and OPC UA carrying whatever the enterprise asked for this quarter. Every one of those choices was correct on its own. Together they create the seams where integration projects go to die.

Those seams are what we do. Tell the RTA Enginerds which two worlds need to meet and what data crosses between them, and we’ll help find you a connectivity solution, give us a call at 1-800-249-1612 or email solutions@rtautomation.com .