How to Plan IEC 60870-5-104 ASDU and IOA Addressing
Every point in an IEC 104 system lives at a two-part address: the common address identifying the station, and the information object address identifying the point within it. Both are just numbers, the standard imposes almost no structure, and that freedom is exactly why unplanned systems drift into address chaos - collisions, mystery gaps, and IOA conventions that differ per RTU vendor. An hour of addressing design before commissioning prevents years of archaeology. This guide is that design session.
IEC 104 ASDU and IOA Plan in one line: To plan IEC 104 addressing, assign each logical station one common address from a documented fleet-wide scheme, then structure each station's IOA space into reserved ranges by signal kind - single-point indications, double points, measured values, commands, and diagnostics - with deliberate gaps for growth. Both ends and any gateway must implement the same table exactly, because every disagreement surfaces later as an unknown-address rejection or, worse, a value landing on the wrong tag.
What You Need
You need the full signal list per station, the interoperability profiles of the devices involved (which say how many octets the addresses use - IEC 104 conventionally carries a two-octet common address and three-octet IOA), and the fleet inventory: how many stations exist today and how many the scheme must survive. Address plans fail by success - the scheme that fit twelve stations collapses at the fortieth - so plan against the fleet you expect, not the one you have.
You also need to know each vendor's IOA quirks before finalizing anything: some RTUs fix IOA ranges per point type, some derive IOAs from internal slot numbering, and gateways often have their own remapping tables. The plan must accommodate the least flexible device in the chain, and discovering that device after the scheme is published means republishing the scheme. The protocol context sits in the IEC 60870-5-104 explainer.
Assign Common Addresses Fleet-Wide
The common address identifies the logical station within the protocol - and since the TCP connection already identifies the physical endpoint, the common address is what distinguishes multiple logical stations behind one connection, a normal pattern for gateways fronting several RTUs. Assign common addresses from a single fleet-wide registry rather than per-project improvisation: unique per logical station, grouped meaningfully (by region, by substation, by gateway), with ranges reserved for growth.
Resist encoding too much meaning into the number - a scheme where the address encodes region, voltage level, and bay type reads elegantly until the first reorganization falsifies the encoding. A registry mapping address to station name, kept authoritative and versioned, ages better than a semantic numbering scheme. And never reuse a retired station's address while any historian still holds its data under that identity.
Structure Each Station's IOA Space by Ranges
Within a station, carve the IOA space into contiguous ranges per signal kind: one block for single-point indications, one for double-point indications, one for measured values, one for setpoints and commands, one for diagnostics and housekeeping. Leave generous unallocated gaps between blocks - address space is free, renumbering is not. A structured space means a capture or log line is half-interpreted by its address alone, and a new signal lands in an obvious place instead of the next free number.
Keep command IOAs deliberately separated from their monitored counterparts, and document the correspondence explicitly (command at this IOA operates the device reported at that IOA). Some organizations offset command ranges by a fixed constant from the corresponding indications - a readable convention, as long as it is written down. The one rule the protocol does enforce: IOAs are unique within their common address across all types, so two blocks may not overlap even though they carry different ASDU types.
Align Both Ends and Every Gateway
The plan only exists where it is implemented identically at every hop: outstation, gateways, master. Gateways deserve particular attention because remapping is their job - an elegant field scheme can arrive at the SCADA renumbered by a converter's table nobody exported. Make the address table a controlled document per station: signal name, type, IOA, common address, direction, and the gateway translations if any, version-controlled alongside the point map.
Misalignments announce themselves at commissioning as unknown-address rejections - the outstation explicitly refusing an unknown common address or unknown IOA, causes 46 and 47 in the COT vocabulary covered in the cause of transmission explainer. Those rejections are the friendly version of the failure; the hostile version is two tables that disagree yet overlap, where values arrive successfully at the wrong points. The rejection you can chase in an afternoon; the silent crossover waits for an operator to act on the wrong tank level.
Verifying the Result
Verify by interrogation and comparison: run a general interrogation per station and reconcile every returned address against the table - nothing unexpected, nothing missing, every value plausible for its documented signal. Then walk a sample of critical points end to end, field to master, confirming the physical signal and the addressed tag correspond; address-table crossovers survive interrogation checks because the addresses are valid, just wrongly bound.
Institutionalize the discipline: every future signal addition goes through the registry and the table, not straight into a device. The plan's value compounds with fleet size - integrators onboarding the fortieth station into a documented scheme move in days rather than weeks, which is the economics behind the onboarding pattern described in connecting IEC 60870 stations to cloud SCADA.
Frequently Asked Questions
Are IOAs unique per ASDU type or per station?
Per station - the information object address space is shared across all types within one common address, so a measured value and a command may not hold the same IOA. Vendors differ in how strictly they enforce this, which is precisely why relying on lax enforcement is dangerous: the configuration that works against a permissive RTU fails against a strict one, usually during a device replacement.
Can one TCP connection carry several common addresses?
Yes - that is the standard pattern for a gateway or data concentrator fronting multiple RTUs: one connection, multiple logical stations distinguished by their common addresses. The master must be configured for each, and the interrogation and addressing logic runs per common address. It is also why the common address must be planned fleet-wide rather than assumed to be always 1 as single-station bench setups suggest.
What IOA numbering convention works best?
Any convention that is contiguous by signal kind, gapped for growth, documented in a controlled table, and implementable by your least flexible device. Beyond those properties the choice is taste: offset-linked command ranges, per-bay sub-blocks, and decimal-readable boundaries are all common. The failure mode is never the convention itself - it is the undocumented exception added under time pressure that the next integrator cannot predict.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.