How to Troubleshoot IEC 104 Using Cause of Transmission

Back to Blog

First Checks

Get a capture or a protocol log where the COT of each ASDU is visible - Wireshark dissects 104 natively, and most gateways log COT in their diagnostics. Confirm the session basics first: the connection is established and data transfer was started with STARTDT, because a link where the master forgot STARTDT delivers nothing at all and looks like total silence rather than a COT problem - that startup gate is covered in STARTDT and STOPDT.

Then take an inventory of what COTs you actually see over a few minutes of operation. A healthy feed mixes spontaneous data (COT 3) with periodic or background values and the occasional interrogation sequence. The table below is the reading key for what each signature means; the field's definition itself is covered in the cause of transmission explainer.

COT signature in the capture	What it tells you
COT 3 (spontaneous) flowing for a point	Change reporting works for that point
Data only ever arrives as COT 20 (interrogated)	Spontaneous reporting is not configured or not qualifying
COT 6 sent, COT 7 returned with negative flag	Command reached the outstation and was refused
COT 6 sent, no COT 7 at all	Command lost or outstation not processing commands
COT 10 never arrives after an interrogation or command	Sequence left incomplete - timeout tuning or device fault
COT 44 or 45 returned	Outstation does not implement that type or cause
COT 46 or 47 returned	Addressing mismatch - wrong common address or IOA

With that key, the sections below work through the three signatures that generate most tickets.

Data Arrives Interrogated but Never Spontaneous

If a point updates whenever you run a general interrogation but never announces its own changes, the outstation is not generating spontaneous transmissions for it. The usual causes, in order: the point's change-detection is not configured (no deadband set, or event reporting disabled for it), the change never exceeds the configured threshold, or the point was mapped for cyclic rather than spontaneous transmission and its slow cycle looks like silence. The COT tells you which world each arriving value comes from - spontaneous, cyclic, background scan, or interrogated - so a few minutes of capture classifies the point's actual behavior definitively.

The fix follows the diagnosis: enable or tune change reporting at the outstation, or accept cyclic delivery and set its period deliberately. This division of labor - interrogation for baseline, spontaneous for changes - is the same pattern as an integrity poll plus event reporting in DNP3, a parallel drawn in the integrity poll explainer, and the troubleshooting instinct transfers directly: baseline works, changes missing, therefore look at change generation, not the link.

Commands Refused: Reading the Negative Confirmation

A 104 command normally echoes back through a fixed COT ladder: the master sends activation (COT 6), the outstation answers with activation confirmation (COT 7), and eventually activation termination (COT 10) reports completion. The P/N flag on the confirmation is the verdict: positive means accepted, negative means refused. A negative confirmation with the mirrored command means your message arrived intact and was rejected on grounds - interlock, local mode, unsupported qualifier, bad select-execute state - so the investigation moves to the outstation's command configuration, not the network.

No confirmation at all is a different animal: the command vanished, which points at the session (sequence numbers stalled, link half dead) or a device too busy to respond. And a confirmation that arrives without a later termination leaves the command's field outcome unreported - some devices are lax about termination, but on equipment that normally sends it, its absence after a breaker command deserves attention before anyone assumes the switch operated.

The Error Causes: 44 to 47 Name the Mismatch

The four error causes are the outstation explicitly rejecting what it cannot interpret, and each names its objection: unknown type identification (44) - the device does not implement that ASDU type; unknown cause of transmission (45) - your COT is invalid in this direction, classically a master echoing monitor-direction causes into commands; unknown common address (46) - the station address is wrong; unknown information object address (47) - the station is right but that point does not exist there. A capture showing 46 or 47 converts hours of is-the-link-broken speculation into a five-minute address-table comparison.

These mismatches concentrate at configuration boundaries: after an RTU replacement, a gateway remap, or a SCADA migration, when one end's table changed and the other's did not. The fix is aligning the interoperability profiles - the agreed subset of types, causes, and addresses both ends implement - and re-verifying the points that changed. Getting that agreement right at commissioning time is the subject of the addressing-plan guide referenced from connecting IEC 60870 devices to cloud SCADA.

When to Escalate

Escalate with the COT evidence attached: the capture excerpt showing the signature - the negative confirmation, the error cause, the missing termination - plus both ends' configuration exports for the disputed points. Vendors resolve a ticket that says COT 47 for IOA range such-and-such after firmware update in a day; they cannot do much with commands sometimes fail. The COT vocabulary is the shared language between you, the vendor, and the capture.

Escalate operationally when command sequences misbehave on primary equipment - refused or unterminated commands on breakers and valves are an operations and protection matter first and a protocol matter second. Leave the field state verification to qualified site personnel and their procedures; the capture can wait, the uncertainty about whether a breaker actually opened cannot.

Frequently Asked Questions