IEC 60870-5 ASDU Types Explained

Back to Blog

How the Type System Organizes Data

An Application Service Data Unit (ASDU) is the container for IEC 60870-5 information, and its type identifier is the first thing that classifies it. The types fall into families. Process information in the monitoring direction covers single-point information (a status that is on or off), double-point information (a status with intermediate and faulty states, ideal for breaker position), step-position, bitstrings, and measured values. Measured values come in flavors - normalized, scaled, and short floating point - so the same physical quantity can be carried with different resolution and encoding.

The type also encodes whether time is attached. A category exists both without a timestamp and with a time tag (the CP56Time2a form), so an event that needs a precise time of occurrence uses the time-tagged variant. In the control direction, command types cover single and double commands, set-point commands, and bitstring commands. System information types handle interrogation, counter interrogation, clock synchronization, and test. Reading the type identifier tells you immediately what a given ASDU is doing.

Why the Type Choice Matters When Mapping

When you map an outstation, you are assigning each real point to an ASDU type, and getting it wrong produces subtle failures. A breaker position mapped as single-point loses the intermediate and faulty states that double-point carries. A measured value mapped as the wrong numeric type reads with the wrong scaling. An event that needs sequence-of-events accuracy but is mapped to a non-time-tagged type arrives without the timestamp the master expects.

The type identifier works together with the cause of transmission - the type says what kind of data, the cause says why it was sent. Both are set as you assign each point, a task laid out in planning the ASDU and IOA addressing. The type system is shared across the family, so it applies whether you run serial 101 or networked 104, and it sits at the heart of the IEC 60870-5-104 data model.

Type Numbers Worth Knowing on Sight

Interoperability lists, gateway configuration screens, and analyzer traces mostly show raw type numbers, so the common ones are worth recognizing without a lookup:

Type ID	Reference	Carries
1	M_SP_NA_1	Single-point information, no time tag
13	M_ME_NC_1	Measured value, short floating point
30	M_SP_TB_1	Single-point with CP56Time2a time tag
45	C_SC_NA_1	Single command
100	C_IC_NA_1	General interrogation command

The naming convention itself decodes the rest: M types travel in the monitor direction and C types in the control direction, the middle letters name the information kind, and the time-tagged variants sit at different numbers from their plain siblings. Once the pattern is familiar, an unfamiliar type in a trace narrows to a family before the documentation is even open.

Normalized, Scaled, or Float: Picking a Measured Encoding

The three measured-value encodings trade precision, bandwidth, and configuration risk differently. Normalized values express the measurement as a fraction of a full range that both ends must agree on out of band - the value on the wire is meaningless without the engineering range, and a range mismatch between outstation and master produces numbers that look plausible and are silently wrong. Scaled values carry integers with an agreed scaling factor and share the same coordination burden. Short floating point carries engineering units directly, which removes the range-agreement risk at the cost of a larger information element.

Counters get their own family: the integrated-totals types carry an accumulating count with a sequence number, designed for energy and flow totalization where losing or double-counting an increment matters. Mapping a totalizer as a measured value instead of an integrated total is a classic mistake - it works until a rollover or a missed report quietly corrupts the accumulated figure downstream.

Proving the Mapping at Commissioning

A point list on paper is a hypothesis; commissioning tests it. The efficient sequence is to start with a general interrogation and check that every static point arrives with the expected type, address, and a sensible value. Then exercise events: drive field points and confirm they arrive spontaneously with the right type - especially that time-tagged types actually carry plausible timestamps, since a wrong plain-type mapping shows up here as events with no time attached. Finally exercise each command type end to end, watching the full confirmation lifecycle complete.

The protocol helps you find mismatches: an outstation that receives a type it does not support mirrors the ASDU back with an error cause, and reading those replies against the cause of transmission table identifies exactly which field was rejected. Working through a trace this way is the core skill of troubleshooting IEC 104, and it turns a vague complaint that points are not updating into a specific mapping fix.

Reading an Interoperability List Before You Map

Every conformant device ships an interoperability list: the standard's own checklist with each type, cause, and option marked as implemented or not. Read it before building the point map, with three questions in mind. Which measured-value encodings does the device offer, and do they match what the master expects? Are the time-tagged variants supported for the points that need event-time accuracy? Which command types are implemented, and in which modes - direct operate, select-before-operate, or both?

Where the master's list and the outstation's list disagree, the overlap is what you can actually use, and finding that overlap on paper costs minutes while finding it during commissioning, ASDU by rejected ASDU, costs days. Keep the annotated list with the project documentation: months later, when a new point must be added, the annotations answer instantly whether the device can carry it as a float with a time tag or whether the addition means a conversation with the manufacturer.

Frequently Asked Questions