IEC 60870-5-104 in practice: ASDUs, IOAs, and the interrogation that hangs
IEC 60870-5-104 is the protocol you meet when industrial telemetry has to talk to a SCADA or dispatch system. The specification is precise and the reference material is thin, so most of what you actually need to know ends up living in the parsing code. Here is what matters when you implement it against real equipment.
ASDU type IDs are a byte-layout contract
Every value travels in an ASDU (Application Service Data Unit) tagged with a type ID that fixes its exact byte layout. A single-point status is one byte; a normalized measured value is three; a short float with a quality descriptor is five; the time-tagged variants append a CP24 or CP56 timestamp. Your parser is, at its core, a table from type ID to byte layout, and one wrong entry corrupts every object in that ASDU. The type ID also tells you whether you are looking at a measurement, a command, or an interrogation response, so it is the first thing you branch on.
Normalized values have a defined range
A normalized value is a 16-bit integer that represents a fraction of full scale, and the spec pins it to the range of minus one up to just under one. In code that means dividing the raw value by 32768 and clamping to that range. Skip the clamp and a noisy reading can present as an out-of-range float that propagates into whatever consumes it downstream. This is the kind of detail that is obvious once it has burned you and invisible until then.
Sequential vs non-sequential addressing
Information Object Addresses (IOAs) identify each point, and an ASDU can pack its objects two ways. In the sequential form it carries one starting IOA and the objects follow in order, so you increment the address yourself. In the non-sequential form each object carries its own IOA. A flag in the variable structure qualifier tells you which form you have, and a parser that assumes one will read the other as garbage. Sites with many points use the sequential form to save bytes, so you will meet both in the field.
The interrogation flow, and where it hangs
A general interrogation is a handshake. The controlling station asks, you confirm activation, you send the current value of every point as a series of ASDUs stamped with the right cause of transmission, and you send a termination. The failure that costs a day is when the link looks up but the interrogation never completes. That usually means a firewall is passing the initial TCP connection while dropping the asynchronous data, so your activation confirmation goes out and the values never arrive. Connection-level timeouts with bounded retries (the spec's T1 and T2 timers) are what keep a half-working link from masquerading as a healthy one. A link that connects but does not interrogate is the signature, and you have to instrument for it on purpose, because nothing throws an error on its own.
Where AgentKick fits
We implement and debug industrial protocol stacks, including IEC 60870-5-104 to SCADA and dispatch systems, where the gap between the written spec and a working field link is the actual job. If you are integrating telemetry with a grid operator or a control center, that is the work we do, usually as a short scoping engagement into a phased build.