A classic IEC 60870-5-104 commissioning surprise is a connection that looks perfect and yet delivers no data. The TCP socket is open, the master and outstation can see each other, and still nothing flows. Almost always the missing step is STARTDT. IEC 60870-5-104 separates opening the connection from opening the data flow, and STARTDT is the command that turns the data on. This guide explains STARTDT, its partner STOPDT, and the TESTFR keepalive - the small control frames that manage a 104 link on top of TCP - and why forgetting them leaves a connected socket silent.
STARTDT and STOPDT in one line: STARTDT and STOPDT are U-format control frames in IEC 60870-5-104 that manage the flow of user data over an already-established TCP connection. STARTDT tells the outstation to begin sending process data; STOPDT halts that data flow without closing the TCP connection. A related frame, TESTFR, keeps an otherwise idle link alive by testing that both ends are still responsive.
IEC 60870-5-104 runs over TCP, but it wraps its data in its own application layer. Every message is an APDU, and the control field at the front - part of what the standard calls the APCI - determines the frame's format. Frames that carry actual process data are I-format. Frames that only acknowledge received data are S-format. And frames that do pure connection control, carrying no process data at all, are U-format. STARTDT, STOPDT, and TESTFR are all U-format frames.
The key idea is that establishing the TCP connection and enabling the data flow are two separate acts. Opening the socket gets the two ends talking at the transport level, but the outstation will not spontaneously start streaming measurements just because a socket exists. It waits for an explicit instruction. This separation is intentional: it lets a master hold a connection open in a quiet, controlled state and decide precisely when data should begin and end, rather than data gushing the instant TCP connects. STARTDT and STOPDT are the switches that control that gate.
After the TCP connection is up, the master sends STARTDT-activation. The outstation replies with STARTDT-confirmation, and only then does user data flow: spontaneous changes, interrogation responses, and command traffic all become possible. Before that confirmation, the outstation deliberately holds its data back. This is the single most common reason a freshly configured 104 link appears dead - the connection is fine, but STARTDT was never sent or never confirmed, so the gate is still shut.
STOPDT does the reverse. The master sends STOPDT-activation to tell the outstation to stop sending user data, and the outstation confirms and goes quiet, but the TCP connection stays open. That lets the master pause the data stream - for example during maintenance or when switching between a primary and backup connection - without tearing down and re-establishing the socket. TESTFR handles a third situation: when a link sits idle for a while with no traffic, either end can send TESTFR-activation and expect a TESTFR-confirmation, proving the peer is still alive. If the test goes unanswered, the link is treated as failed and the connection is closed, so a dead peer is detected rather than assumed healthy just because the socket never errored.
The practical lesson for anyone bringing up a 104 link is to check STARTDT before suspecting anything deeper. If a technician sees an established TCP connection but zero incoming values, the fault is very often that STARTDT was not issued, not confirmed, or was sent by a master that then stopped listening. It is easy to misread this as a routing problem, an addressing problem, or a dead outstation, when the real answer is that the data gate was never opened. Confirming that STARTDT-activation went out and STARTDT-confirmation came back usually resolves the mystery in seconds.
For a cloud SCADA platform ingesting IEC 60870-5-104, correct handling of these control frames is part of a reliable connection. The platform side must send STARTDT after connecting so data actually begins, keep the link healthy with TESTFR during quiet periods, and interpret an unanswered TESTFR as a failed link to be re-established rather than a healthy but silent one. It also helps operators when the platform surfaces this connection state plainly - showing not just whether the TCP socket is up but whether data transfer is actually started - so a stalled STARTDT presents as an obvious link-status problem. A cloud platform such as Merobix manages that STARTDT, STOPDT, and TESTFR lifecycle so that a connected-but-silent outstation is detected and flagged instead of quietly delivering no telemetry.
Almost always because STARTDT was never sent or never confirmed. In IEC 60870-5-104, opening the TCP connection and enabling the data flow are separate steps - the outstation deliberately holds its data back until the master sends STARTDT-activation and receives STARTDT-confirmation. A socket can be fully connected yet silent because the data gate is still shut.
STOPDT halts the flow of user data but leaves the TCP connection open, so the master can pause data - for maintenance or during a failover between connections - without tearing down and re-establishing the socket. Closing the TCP connection ends the transport session entirely and requires a new connection and a new STARTDT to resume. STOPDT is a lighter, reversible pause.
TESTFR is a keepalive. When a 104 link sits idle with no traffic, either end can send TESTFR-activation and expect a TESTFR-confirmation, proving the peer is still responsive. If the test goes unanswered, the link is treated as failed and the connection is closed, so a dead peer is detected rather than silently assumed healthy because the socket never reported an error.
Primary references from the standards bodies and regulators that define this topic:
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.