Testing

IEC 60870-5-104 conformance testing: what is actually tested

2026-10-29 · 9 min read

IEC 60870-5-104 looks simple: a handful of frame types, a couple of timers, and a two-byte sequence number. That simplicity is why implementations pass a lab test and then fall over on a 500-point link with a flaky radio behind it. Here is what a conformance test actually exercises, and where real links break.

The frame types, and why the sequence numbers matter

Three frame formats share the same start byte. I-frames carry numbered information in both directions, S-frames acknowledge received I-frames without carrying data, and U-frames handle start/stop, test and clock synchronisation. Every I-frame increments a send sequence number; acknowledgements travel as the receive sequence number in the next I-frame or in an S-frame.

Two window parameters govern how many unacknowledged I-frames may be in flight (k) and how many received frames may accumulate before an acknowledgement must be sent (w). Almost every field failure in 104 is a window or timer problem wearing a different costume.

What a conformance test exercises

A serious suite walks each of these, on both roles, with the peer's real bytes:

• Start/stop handshake, and behaviour when the peer restarts mid-session.
• TESTFR activation and confirmation, including the case where the test frame is ignored.
• Timer behaviour: t0 for connection setup, t1 for acknowledgement of sent frames, t2 for acknowledgement of received frames, t3 for idle keep-alive.
• Window behaviour: sending exactly k frames without acknowledgement, then refusing to send more; and the recovery path once acknowledgement arrives.
• General interrogation, including the case where a second GI arrives before the first completes.
• Spontaneous, cyclic and background-scan transmission, and the interaction between them under load.
• Clock synchronisation, and what the outstation does with a timestamp that is not monotonic.
• Command select/execute, the negative cases (execute without select, select twice, select timeout), and the qualifier handling.
• Redundancy and link switching, if the product claims it.
• Error handling: unknown type identification, malformed length, out-of-sequence frames, and the correct response to each — which is often silence plus a counter, not an error frame.

The five failures that actually happen

These are the ones we see on live links far more often than in test reports:

• k/w misconfiguration between the two ends. One side allows 12 unacknowledged frames, the other expects 8. Everything works until the link gets busy, then it stalls and recovers on reconnect — which looks like a network problem and is not.
• t1 too tight for the real round-trip. On a radio or satellite path, 15 s may be generous while 5 s is not. When t1 expires the connection drops, so the symptom is periodic disconnects under load.
• General interrogation storms. A master that issues GI on every reconnect, against an outstation with 20,000 points, creates a burst that saturates the link and triggers t1 on the next command. The cure is a staged GI with a background scan, not a bigger timeout.
• Sequence number wrap and stale state. After a long outage, an outstation that resumes numbering from where it left off rather than restarting the session produces out-of-sequence frames forever.
• Timestamp quality. 104 carries a quality descriptor and a 7-byte timestamp; an outstation that fills them from a free-running clock rather than a synchronised one passes the lab and misleads the control room.

Throughput claims, measured honestly

Our published figures for the 104 package are ≥50,000 data points per second sustained per link, with bursts to 100,000, ≥64 concurrent links, and link rebuild under one second. Those numbers mean something only with the conditions attached: point count, frame size, link type, and whether the counters include the parsing and the application callback.

When you compare vendors, ask for the conditions, not the number. A figure without a test setup is marketing.

Preparing for the test

A day of preparation removes most of the surprises:

• Fix k and w on both ends, write them in the test plan, and test at exactly the boundary — k frames without acknowledgement, then k+1.
• Measure the real round-trip time on the target link and set t1 with at least 2× margin.
• Have a capture on both sides. When the two ends disagree about what was sent, only the bytes settle it.
• Decide in advance what "pass" means for the error cases: a counter increment, a log line, or an explicit close.
• Run a 24-hour soak with the real point count. Memory growth and handle leaks do not appear in a 10-minute test.

Questions that come up

Is 104 testing the same as 101 testing?

The application layer is shared, so the point model, quality descriptors and command semantics carry over. What changes is the transport: 104 puts the APDU into TCP, adds the k/w windows and the t0–t3 timers, and replaces the link-layer handshake with a start/stop sequence. Test the transport behaviour separately from the application behaviour.

Do we need a conformance certificate to sell?

Buyers differ, but the practical artefact most of them want is a test report they can file, produced against a defined suite, with the conditions stated. A certificate without the underlying captures answers fewer questions than a report with them.

Why does our link drop every few minutes under load?

Almost always a timer or window mismatch rather than a bug. Check t1 against the measured round trip, then check that both ends agree on k and w. Only after those two are eliminated is it worth looking at the code.

Keep reading