Integration

Seven IEC 61850 integration mistakes that show up in every project

2026-10-29 · 8 min read

These are not exotic. They are the same seven things, in roughly the same order, on project after project — which is good news, because a checklist catches them before commissioning week instead of during it. For each one, here is what it looks like from the protocol side.

1. The ICD is treated as documentation instead of an interface

Someone edits the file to "fix" a point name, the device is unchanged, and the master is now configured against a model that does not exist. Everything reads as a protocol error and is really a configuration divergence.

• Check: hash the file the device reports against the file the master was configured from. They must match, on site, in writing.

2. Edition assumptions nobody wrote down

The master assumes reservation and report ownership; the older device implements neither. Nothing is broken, but the master's arbitration logic silently does nothing.

• Check: a table of declared capabilities per device, read from each Services block, before design — not after.

3. Datasets nobody sized

One enormous dataset so that "everything is in one report". One point changing invalidates the whole dataset, and the report rate becomes a bandwidth problem on a link that was sized for the average case.

• Check: count the events per second for each dataset under a stated load case, and compare with the link budget.

4. Reporting without general interrogation

The client enables reporting and considers itself initialised. Points that have not changed since startup never arrive, and the control room shows stale values until someone notices.

• Check: disconnect and reconnect the client; every value must return to a known state without human intervention.

5. Buffered report overflow ignored

The link is down for two hours, the buffer overflows, and the client replays what survived while believing it has the full history.

• Check: force a long outage and verify the client detects the gap and resynchronises rather than filling it with assumptions.

6. Control success judged by the write

The write returns, the operator is told the command succeeded, and the device refuses it on interlock milliseconds later. The protocol was correct; the reporting of the outcome was not.

• Check: issue a command that must be refused and confirm the operator sees a refusal, not a success followed by an unrelated alarm.

7. Time is assumed to be right

No monitoring of clock offset, no alarm on loss of synchronisation, and a sequence of events that orders two operations the wrong way around. Nobody notices until the incident review.

• Check: disconnect the time source for a day, then compare device timestamps against a reference.

Questions that come up

Which of these causes the most schedule damage?

In our experience the first one, because it is discovered late and looks like a protocol bug. Every hour spent proving the model is fine is an hour not spent on the actual defect.

Can a protocol analyser catch these?

Most of them, yes — an analyser shows the declared capabilities, the report contents and the control exchange. It cannot catch a configuration that was never applied, which is why the file comparison matters.

Do these apply to 104 as well?

Several translate directly: point list drift instead of model drift, no general interrogation after reconnect, control success judged by the frame, and time synchronisation. The protocol differs; the failure modes rhyme.

Keep reading