Operations

IEC 60870-5-104 troubleshooting: symptom, cause, and where to look first

2026-10-29 · 8 min read

104 failures are famously repetitive. The same handful of causes produce the same handful of symptoms, and almost all of them are visible in a capture within minutes if you know what to look for. This is the mapping we use when a customer reports a problem.

Symptom: the link drops every few minutes, always under load

Classic timer or window mismatch. The sender runs out of credits, stops transmitting, and the receiver's acknowledgement never arrives within the timeout, so the connection is torn down and re-established. On an idle link nothing happens, which is why it "works in the lab".

• Check first: the measured round-trip time against t1 on both ends. Then confirm both ends agree on k and w.
• Check second: whether the drop happens exactly when the unacknowledged frame count reaches k — if so, the cause is the window, not the network.

Symptom: commands hang, then eventually time out

Either the command was sent but the outstation never answered, or it answered and the master did not match the response to the request. The second is more common and looks like the first.

• Check: the type identification and the object address echo in the response.
• Check: whether the outstation is waiting for a select that never happened, or refused the selection and the master ignored the refusal.

Symptom: everything freezes for a minute after every reconnect

General interrogation storm. The master issues GI on reconnect, the outstation blasts the full point set, the link saturates, acknowledgements queue up, and the next command hits t1. The freeze ends when the backlog drains.

• Check: the number of points in the GI response and the frame rate during it.
• Fix direction: staged or background interrogation, and a point count the link was actually sized for — not a bigger timeout.

Symptom: values are stale but the link is up

The connection is healthy and the data has stopped changing. Either the outstation stopped scanning, or the master stopped applying what it received, or the point mapping changed and the master is updating registers nobody reads.

• Check: a capture — are there spontaneous frames arriving with new values? If yes, the problem is north of the protocol.
• Check: whether the quality bits say "old" while the master displays the value as current.

Symptom: duplicate events in the sequence-of-events log

Either the master is acknowledging so late that the outstation retransmits, or two masters are polling the same outstation, or the outstation is replaying buffered events it already sent because it never received the acknowledgement.

• Check: the receive sequence numbers — a repeated number range means retransmission, not new events.
• Check: whether a second client is connected to the same port.

Symptom: works with our test master, fails with the customer's

Optional behaviour. Test masters tend to be permissive; production masters exercise the corners — different qualifier bits, different select/execute timing, GI before the start-up confirmation completes.

• Check: the first divergent frame, not the first error. The divergence is usually a few frames before the visible failure.
• Fix direction: implement the negative paths and test with a tool that can be deliberately hostile.

The first five minutes of any 104 problem

• Capture on both ends if possible, one end if not — and record which.
• Write down k, w, t0, t1, t2, t3 as configured on both sides, before changing anything.
• Establish whether the link is up: start/stop completed, test frames answered.
• Find the first divergent frame and work forward from it, not backward from the error.
• Change one parameter at a time, and write down the result. Parameter roulette is how a fix becomes a mystery.

Questions that come up

Should we increase t1 when the link drops?

Only if the measured round trip justifies it. Raising t1 on a window problem just delays the drop and makes it look like a different problem.

Why does the customer's master behave differently?

Because it is doing more: exercising optional fields, different qualifiers, and timing sequences your test master did not. Test against something hostile before shipping.

How do we prove a fix?

Replay the original capture through the fixed implementation and compare. If the fix cannot be demonstrated against the original evidence, it is a hypothesis, not a fix.

Keep reading