Home / Insights / Decision guide
Decision guide

IEC 61850 or IEC 60870-5-104? It depends on which side of the gateway you are

2026-10-29 · 8 min read

This question is usually asked by someone who has been told to pick one. In practice most products end up with both, because they answer different questions: 61850 is how devices inside a substation describe themselves and talk to each other, and 104 is how a control centre talks to a station over a wide area. Understanding that split usually ends the argument in one meeting.

What each protocol is actually for

  • IEC 61850 models the device. A relay does not expose "register 40001"; it exposes a logical node with typed data objects, units, quality and timestamps, and a client can browse that model. It carries its own discovery, reporting and file services, and it has a peer-to-peer layer for time-critical messages.
  • IEC 60870-5-104 models the conversation. It carries points — single and double indications, measured values, setpoints, commands — with quality and timestamps, over TCP, with defined windows and timers. There is no device model: the point list is agreed out of band, in a document.

The three questions that decide it

  • Who is the other end? A control centre speaks 104 (or DNP3, or 101). A bay-level device or engineering tool speaks 61850.
  • How far does the link go? Inside a station, 61850's model-driven approach pays off. Across a WAN with unreliable links, 104's explicit windowing and timeout behaviour is easier to operate.
  • Does the customer need to browse you? If a client must discover what your device offers, 61850 is the only one of the two that can answer that.

Where the two meet: the gateway

A station with modern IEDs and an old control centre needs a device that speaks both. That gateway is not a translator of bytes but a translator of models, and it is where information is lost: 61850 carries documented structure and a full quality model, while 104 carries a flat point list with a narrower quality descriptor.

Design the point table as a first-class artefact. The gateway will outlive at least one generation of the devices on either side.

If you are building a product, build the core once

The two protocols share more than they appear to: a timestamp representation, a quality concept, a command model with select-before-operate, and the same underlying station data. Products that implement both from a shared internal model adapt to whichever protocol the customer names in the specification.

This is why we ship one kernel with 101/103/104 and a separate 61850 stack over a common mapping layer, rather than one code base per protocol: the point list and the device model are the thing worth owning, and the encodings are downstream of them.

Practical advice

  • Do not choose by which protocol is "modern". Choose by which conversation the buyer needs to have.
  • If the specification names both, plan for a gateway product rather than a device that pretends to be both to everyone.
  • Test both directions of the gateway. Translation bugs are symmetric and the reverse path is always the one that was never tested.
  • Whatever you choose, publish the point list or the model. The integration cost the customer pays is dominated by documentation, not by protocol.

Questions that come up

Can a device speak 61850 and 104 at the same time?

Yes, and many gateways do. The practical constraint is that both consume the same CPU and network, so sizing must account for the combined load rather than each protocol in isolation.

Is 104 obsolete now that 61850 exists?

No. Control centres standardise on telecontrol protocols and replace them slowly; 104 remains the normal northern interface for wide-area telecontrol across much of the world.

Which is easier to implement?

104 is a smaller protocol to implement correctly and much easier to test. 61850 is larger, but it gives you a model you would otherwise have to invent and document. The effort difference shows up in maintenance, not in the first week.

Keep reading

Related products

IEC 60870-5-101/103/104 SDK

One code base for serial telecontrol, protection information and TCP/IP SCADA links — plus the tester that ships with it.

EmbedCore-v5

Turn a conventional protection or bay controller into a compliant IEC 61850 IED in one to two weeks.

Ask about your specific case

Describe the device, the platform and the acceptance criteria. You get an answer from an engineer, not a form letter.