Integration

IEC 61850 to Modbus TCP gateway: point mapping that does not rot

2026-10-29 · 9 min read

Modbus TCP is how a lot of the industrial world still talks. IEC 61850 is how substations do. A gateway between them looks like a translation problem and is really a data-modelling problem: Modbus has registers, no quality, no timestamps and no notion of a dataset, so every decision about what to discard has to be made explicitly, in advance, and written down.

Two mapping philosophies

Every gateway implements one of these, and the choice determines what happens the next time the device model changes.

• Model-driven. Registers are derived from the 61850 hierarchy: logical device, logical node, data object, attribute, laid out in a deterministic order. When the model changes, the map changes — and every client pointing at register 40001 is now pointing at something else.
• List-driven. The map is an explicit table, written and versioned by a human, with a fixed address for each point. Survives model changes, but drifts from the model unless someone maintains it.
• In practice the best answer is list-driven with generation: keep the table as the artefact of record, generate it from the SCL, and diff on every model change so the drift is visible rather than discovered on site.

Carrying quality into a protocol that has none

This is the decision people postpone and then regret. Modbus has no quality flag, so a status point that is "invalid" and one that is "open" are the same bit unless you make them different.

• Reserve a status word per block of points, one bit per point, meaning "the 61850 source says this value is not good". Costs almost nothing and prevents the worst class of error: acting on a stale value.
• Never encode "no data" as a plausible numeric value. Zero is a valid measurement; a gateway that outputs zero on comms loss has lied to the SCADA.
• If the point is time-stamped in 61850, expose the timestamp in a companion register pair (seconds + milliseconds since epoch), even if the Modbus client ignores it. It is the only way to debug later.
• Document the scale factor, the sign convention and the byte order in the point table itself. Not in a PDF nobody opens.

The control path is where gateways hurt people

Reading is forgiving; writing is not. A Modbus write that becomes a 61850 control operation must preserve the safety semantics of the 61850 side, and most gateways quietly lose them.

• If the 61850 device requires select-before-operate, the gateway must either implement the two-step sequence or refuse the write. A single-register write that internally does select-then-execute within milliseconds is not the same operation and should not be presented as one.
• Map control commands to distinct registers per operation (select, execute, cancel) rather than encoding them in the value.
• Echo back what was actually sent and what the device answered, in readable registers, and keep the last error code.
• Consider a dead-man behaviour: if the Modbus client disconnects mid-sequence, the gateway must cancel the selection rather than leave it armed.

A point table that survives five years

What we insist on, and what we recommend you insist on from any gateway vendor:

• The table is generated from the SCL and stored in version control, with the SCL hash recorded next to it.
• Every point has a stable identifier independent of its register address, so that re-addressing does not break the client configuration.
• A diff report exists: what changed between two versions of the model, and which registers moved.
• Startup is deterministic — the same configuration always produces the same map, with no dependence on file iteration order.
• The mapping file is exportable in a format a spreadsheet can read, because that is how the integrator will actually work with it.

Questions that come up

Should the gateway be model-driven or list-driven?

List-driven with generation from the model. A purely model-driven map is elegant until the first model revision re-numbers everything; a hand-maintained list is stable until it silently diverges. Generation plus version control gives you both.

How do we handle datasets and reporting across the gateway?

Do not. Datasets are a 61850 concept with no Modbus equivalent; the gateway subscribes to reports and exposes the resulting values. Trying to expose dataset structure over Modbus produces a mapping nobody can maintain.

What about IEC 60870-5-104 on the other side?

104 is a better fit for wide-area telecontrol than Modbus, and it carries quality and timestamps natively — so a 61850↔104 gateway generally loses less information than 61850↔Modbus. Choose the northern protocol by what the control centre already runs, not by what is easier to implement.

Keep reading