The Problem Nobody Talks About
We have all seen it. A procurement manager, dazzled by a glossy brochure from a motion-control vendor, decides that since “Ethernet is Ethernet,” the facility’s new protection relay scheme should run on the same EtherNet/IP network as the plant’s conveyor belt motors. This is how you end up with a protection trip that takes 400 milliseconds to propagate because a PLC decided to dump a massive tag-update packet exactly when the relay needed to issue a GOOSE (Generic Object Oriented Substation Event) message.
In the world of North American power systems, we are seeing an increasing convergence of Information Technology (IT) and Operational Technology (OT). However, the convergence of industrial OT (factory automation) and utility OT (substation automation) is a recipe for catastrophic failure. If you are trying to decide between IEC 61850 and EtherNet/IP, you aren’t just choosing a communication protocol; you are choosing between a deterministic, peer-to-peer architecture designed for millisecond-level protection and a master-slave polling architecture designed for assembly lines.
Technical Deep-Dive
To understand why these protocols don’t mix, we have to look at how they handle the stack and the timing requirements of their respective domains.
IEC 61850: Designed for the Grid
IEC 61850 is not a protocol in the traditional sense; it is a standard for substation automation. It uses MMS (Manufacturing Message Specification) for client-server reporting and GOOSE or SV (Sampled Values) for high-speed peer-to-peer communication.
The critical differentiator is that GOOSE messages bypass the standard TCP/IP stack entirely, mapping directly to the Ethernet Data Link Layer (Layer 2). By removing the overhead of the transport and network layers, IEC 61850 achieves the sub-4ms performance required for high-speed interlocking and tripping. It is inherently object-oriented, meaning the relay knows exactly what “Status of Circuit Breaker 52A” means without needing a register map.
EtherNet/IP: The Factory Workhorse
EtherNet/IP (Ethernet Industrial Protocol) is built on the CIP (Common Industrial Protocol). It is a master-slave architecture. A PLC (the scanner) periodically polls I/O devices. While it is excellent for controlling a robotic arm, it relies heavily on the TCP/IP and UDP/IP stacks.
In a substation environment, EtherNet/IP introduces jitter. Because it relies on a scanner to manage the data flow, the latency is dependent on the scan cycle of the PLC. If your PLC scan time is set to 20ms, your protection logic is fundamentally incapable of reacting faster than that, regardless of how fast your relay hardware is.
| Feature | IEC 61850 (GOOSE) | EtherNet/IP |
|---|---|---|
| Architecture | Publisher/Subscriber (Peer-to-Peer) | Master/Slave (Client/Server) |
| Network Layer | Layer 2 (Direct to Ethernet) | Layer 3/4 (TCP/UDP/IP) |
| Primary Goal | Deterministic Protection/Interlocking | Industrial Control/Data Acquisition |
| Data Model | Self-describing (SCL/XML) | Register/Tag-based (EDS files) |
| Failure Mode | Multicast storm (if misconfigured) | Scanner timeout/Packet collision |
Implementation Guide
When integrating these systems, you must treat the substation network as a separate, hardened VLAN. If you have already made the mistake of trying to bridge these worlds, you should review iec-61850-vs-modbus-tcp to understand the fundamental differences in data structure and why simple gateways often fail to translate the semantic richness of 61850.
Configuration Strategy
- Traffic Segregation: Use managed switches with IGMP Snooping and VLAN tagging (IEEE 802.1Q). GOOSE messages are multicast; if you don’t constrain them, they will flood every port on your network, potentially overwhelming an EtherNet/IP PLC that isn’t designed to filter high-frequency multicast traffic.
- Prioritization: Implement Quality of Service (QoS) using IEEE 802.1p. IEC 61850 traffic should be tagged with the highest priority (CoS 6 or 7) to ensure it gets through the switch fabric ahead of routine SCADA polling or diagnostic traffic.
- Time Sync: IEC 61850 relies on PTP (Precision Time Protocol / IEEE 1588) for microsecond-level synchronization. EtherNet/IP has its own time-sync requirements (often CIP Sync), which are rarely compatible with the Grandmaster clocks used in substations. Do not attempt to share a PTP clock between these two domains unless you are prepared for a nightmare of clock-drift offsets.
Failure Modes and How to Avoid Them
I once consulted on a site where a contractor used an EtherNet/IP-based bridge to pass “trip signals” between two legacy switchgear lineups. During a routine software update on the plant-wide SCADA server, the network load spiked. The PLC managing the bridge missed a polling cycle, and the “trip” command was delayed by over 200ms. The result? The primary protection cleared the fault, but the secondary breaker—which should have opened—welded its contacts shut because the delayed trip arrived after the arc had already caused catastrophic damage to the cubicle.
Common Pitfalls:
- The “Gateway” Trap: Every protocol converter is a potential point of failure. Each gateway adds latency and a new configuration file that can be corrupted. Avoid them if you can use a native protocol.
- Multicast Flooding: If you don’t configure IGMP Queriers on your switches, your GOOSE traffic will be broadcast to every device. Your EtherNet/IP PLC will likely crash when it receives thousands of packets per second that it doesn’t know how to parse.
- Security Misalignment: NERC CIP compliance is built around the assumption of specific communication patterns. Introducing an EtherNet/IP scanner into a NERC-regulated environment changes the attack surface significantly, often requiring a total re-evaluation of your Electronic Security Perimeter (ESP).
When NOT to Use This Approach
Do not use EtherNet/IP for protection-class signals under any circumstances. If the signal is “trip,” “close,” or “interlock,” it belongs on IEC 61850 or hard-wired copper. Period.
EtherNet/IP is perfectly acceptable for non-critical monitoring of auxiliary equipment (e.g., cooling fans, oil temperature sensors, or battery room HVAC). If you are buying a piece of equipment that only supports EtherNet/IP, ensure it is isolated behind a firewall or a strictly configured VLAN that prevents it from touching the protection bus.
Conclusion
The industry is full of “universal” communication solutions that claim to bridge the gap between everything. In reality, these are usually just expensive ways to introduce latency and complexity. Stick to the standards that were written for your specific environment. IEC 61850 is the language of the grid; EtherNet/IP is the language of the factory. Keep them in their respective silos, and use a hardened, unidirectional gateway if you must pass telemetry between them. Your protection scheme is only as good as its weakest packet.
*This article is intended for informational purposes only for experienced electrical engineers and equipment procurement professionals. All specific technical parameters, protocol compliance thresholds, and performance specifications mentioned must be independently verified against the applicable standard revision, equipment datasheet, and site-specific engineering studies before any design, procurement, or operational decision is made. GridHacker and its authors accept no liability for misapplication of the content herein.*
Hero image: A car's dashboard shows speed and various data.. Generated via GridHacker Engine.
