The Problem Nobody Talks About
We spend an inordinate amount of time debating the “future-proof” nature of substation automation, yet we consistently fail to acknowledge that the primary cause of commissioning delays isn’t the protocol itself, but the misunderstanding of the abstraction layer. You have likely seen the marketing brochures promising that moving from IEC 60870-5-104 to IEC 61850 will magically solve your interoperability woes. It won’t. In fact, if you approach IEC 61850 with the mindset of a legacy serial-to-IP migration, you are essentially building a high-speed, high-complexity failure point that is significantly harder to troubleshoot than a standard RTU-based polling scheme.
The industry often treats these two protocols as interchangeable communication pipes. They are not. IEC 60870-5-104 is a transport-oriented protocol designed for telemetry and control over wide-area networks. IEC 61850 is a semantic object-oriented modeling language that happens to use networking protocols as a transport mechanism. Treating them as peers is the fundamental error that leads to botched integration projects.
Technical Deep-Dive
To understand the delta, we must look at the data structure. IEC 60870-5-104 is essentially a point-to-point or point-to-multipoint messaging system. You define an address, you map a data type, and you wait for a master station to poll or send a spontaneous event. It is rigid, predictable, and—crucially—dumb. It doesn’t know what a circuit breaker is; it only knows that bit 101 at address 4002 is now high.
IEC 61850, conversely, is built on the Substation Configuration Language (SCL). It forces you to define your system in terms of logical nodes and data objects. When you communicate in 61850, you aren’t just sending a status bit; you are sending a state change for a specific logical device within a defined substation hierarchy.
The transport mechanism for 61850 (specifically MMS for client-server or GOOSE for peer-to-peer) operates on a completely different philosophy than the TCP/IP-based 104. While 104 is heavily reliant on the master-slave polling cycle (or spontaneous reports), 61850 allows for publisher-subscriber models that can operate independently of a central SCADA master. This is the difference between a telephone call (104) and a multicast radio broadcast (61850). If you want to dive deeper into how these legacy versus modern approaches impact performance, check out our iec-61850-vs-iec-104 deep dive.
Implementation Guide
When implementing 61850, your configuration is only as good as your Substation Configuration Description (SCD) file. The engineering workflow is non-negotiable:
- Define the physical topology in the System Specification Tool.
- Map the logical nodes to physical IEDs.
- Validate the Subnet Configuration. If your VLAN tagging is incorrect at the switch level, your GOOSE messages will fail, and you will spend three days chasing a “communication loss” error that is actually a broadcast storm or a blocked multicast group.
With 104, your implementation guide is usually a spreadsheet of addresses. With 61850, it is a set of XML files that must be consistent across the entire vendor ecosystem. If the vendor’s Implementation Conformance Statement (PICS) does not align with your system requirements, the protocol-level interoperability is irrelevant. You will end up with a system that connects but cannot interpret the data objects.
Failure Modes and How to Avoid Them
I once consulted on a project where a major utility attempted a “brownfield” migration to 61850. The engineering team assumed that because the switches supported IGMP snooping, the GOOSE traffic would be handled automatically. They failed to account for the latency introduced by the switch fabric during a high-traffic event—specifically, a bus-bar fault.
When the fault occurred, the protective relays generated a flurry of GOOSE messages to initiate a breaker failure scheme. The switch, overwhelmed by the multicast traffic and improperly configured IGMP timers, delayed the delivery of the trip signal. The primary protection worked, but the secondary backup failed to clear in the required time, leading to significant collateral damage to the switchgear.
The lesson here is simple: 61850 is not “plug and play.”
- VLAN isolation: Never mix GOOSE/Sampled Values (SV) traffic with general SCADA or office traffic on the same physical link without strict traffic shaping and priority queuing (802.1p/Q).
- Time Synchronization: 104 is relatively forgiving of jitter. 61850—specifically when using SV—is not. If your Precision Time Protocol (PTP) implementation is not rock-solid, your sampled values will be meaningless, leading to differential protection trips or, worse, stable-state errors.
When NOT to Use This Approach
Do not force IEC 61850 into a project that does not require high-speed peer-to-peer interlocking or complex object modeling. If you are retrofitting a legacy site where you only need simple telemetry (telemetry, status, and control) and the existing RTU infrastructure is stable, 61850 is an expensive, high-maintenance burden.
If your procurement team is looking at 61850 solely for “future-proofing,” ensure you have the in-house capability to manage the SCL files and the network infrastructure. If your team consists of traditional RTU technicians who are not trained in network management, you are setting the project up for failure. In such cases, a well-implemented 104 gateway remains the more resilient and maintainable choice.
Conclusion
The choice between 61850 and 60870-5-104 is not a choice of technology; it is a choice of architectural philosophy. 104 is a transport protocol for the status quo. 61850 is a framework for digital substation automation that demands a higher level of network engineering rigor. Do not confuse the two, and for heaven’s sake, do not implement 61850 without a robust PTP and VLAN strategy. The complexity of 61850 is a feature, not a bug, but it is a feature that will bite you if you treat it like a serial cable.
*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: Der nutzer hat seine ladung beendet. auf dem bildschirm ist zu sehen, wie viele kwh er geladen hat.. Generated via GridHacker Engine.
