IEC 60870-5-104 (commonly called IEC 104) is the standard protocol for SCADA communication in power utilities, water systems, and other critical infrastructure across Europe, Asia, and the Middle East.
It takes the application layer of IEC 60870-5-101 (the serial telecontrol standard) and maps it onto TCP/IP. This gives you the same proven data model — single-point indications, measured values, commands, and time-stamped events — but delivered over Ethernet and IP networks instead of serial lines.
Setting up IEC 104 involves configuring the TCP connection, ASDU addressing, information object addresses, timeout parameters, and the controlling/controlled station relationship. Get any of these wrong and you will see connection drops, missing data, or failed commands.
This guide walks you through the complete setup process, from network planning to troubleshooting.
In This Guide
1. IEC 104 Overview: How It Works
IEC 104 uses a client/server model over TCP/IP:
- The controlling station (SCADA master/control center) is the TCP client. It initiates the connection.
- The controlled station (RTU, IED, gateway) is the TCP server. It listens for incoming connections on TCP port 2404.
Once connected, both sides can send data. The controlled station sends spontaneous events (status changes, measurements) without waiting to be polled. The controlling station sends commands, general interrogation requests, and time sync messages.
This is different from Modbus where the slave never speaks unless asked. In IEC 104, the controlled station actively pushes data when events occur.
2. IEC 104 vs. IEC 101: Key Differences
| Feature | IEC 60870-5-101 | IEC 60870-5-104 |
|---|---|---|
| Transport | Serial (RS-232/RS-485) | TCP/IP over Ethernet |
| Port | COM port | TCP port 2404 |
| Topology | Point-to-point or multi-drop | IP network (LAN, WAN, VPN) |
| Link layer | FT1.2 frame format | TCP handles framing |
| Error checking | Hamming distance 4 (FT1.2) | TCP checksums |
| Addressing | Link address (1–2 bytes) | IP address + ASDU address |
| Redundancy | Not defined | Redundant TCP connections supported |
| Application layer | Identical | Identical (same ASDUs, same type IDs) |
The application layer is the same. If you know IEC 101, you already know the data types, type identifiers, and cause-of-transmission codes. IEC 104 just changes how frames are delivered.
3. Protocol Architecture: APCI, APDU, and ASDU
Every IEC 104 message is an APDU (Application Protocol Data Unit) consisting of two parts:
APDU = APCI + ASDU
- APCI (Application Protocol Control Information): The 6-byte header that manages the TCP connection — start byte (0x68), length, and control fields for sequence numbering and connection management.
- ASDU (Application Service Data Unit): The actual telecontrol data — type ID, cause of transmission, ASDU address, and information objects with their values and timestamps.
The APCI is specific to IEC 104. The ASDU is shared with IEC 101.
APCI Structure (6 bytes)
| Byte | Field | Description |
|---|---|---|
| 1 | Start byte | Always 0x68 |
| 2 | Length | Number of bytes following (APCI control fields + ASDU) |
| 3–4 | Control field 1 | Send sequence number (I-format) or receive sequence number (S-format) or U-format type |
| 5–6 | Control field 2 | Receive sequence number acknowledgment |
4. Frame Formats: I-Format, S-Format, and U-Format
IEC 104 uses three frame types, identified by the control field bits:
| Format | Purpose | Contains ASDU? |
|---|---|---|
| I-format (Information) | Carries actual telecontrol data (measurements, commands, events) | Yes |
| S-format (Supervisory) | Acknowledges received I-frames without sending data | No |
| U-format (Unnumbered) | Connection management: STARTDT, STOPDT, TESTFR | No |
U-Format Commands
| Command | Full Name | Purpose |
|---|---|---|
| STARTDT ACT / CON | Start Data Transfer | Controlling station requests data flow to begin. Controlled station confirms. |
| STOPDT ACT / CON | Stop Data Transfer | Controlling station requests data flow to stop. |
| TESTFR ACT / CON | Test Frame | Heartbeat to verify the connection is alive during idle periods. |
The connection sequence is:
- TCP connection established (3-way handshake)
- Controlling station sends STARTDT ACT
- Controlled station responds with STARTDT CON
- Data transfer begins (I-frames flow in both directions)
No I-frames or S-frames are exchanged until STARTDT is confirmed. This is a common source of confusion — the TCP connection can be up, but no data flows until STARTDT completes.
5. Network Setup and TCP Configuration
Basic Requirements
| Component | Requirement |
|---|---|
| TCP port | 2404 (IANA registered for IEC 104) |
| IP addressing | Static IPs for all stations |
| Network | Same subnet or routable via gateway/VPN |
| Firewall | Port 2404 open between controlling and controlled stations |
| Bandwidth | Minimal — IEC 104 is very lightweight (a few kbps typical) |
IP Planning
- Control center (SCADA): 10.0.0.1
- RTU site 1: 10.0.1.10
- RTU site 2: 10.0.1.11
- Gateway/router: 10.0.0.254
💡 Pro Tip: IEC 104 works well over low-bandwidth links (cellular, satellite, MPLS). But latency and packet loss directly affect timeout behavior. Always tune timeout parameters for your specific network conditions.
6. Step-by-Step: Configure the Controlled Station (RTU/IED)
The controlled station is the field device — RTU, IED, or protocol gateway — that collects data and sends it to the control center.
Step 1. Set the Listening Port
Default is TCP port 2404. Leave it unless your organization requires a different port.
Step 2. Configure the ASDU Address (Common Address)
The ASDU address identifies this station in the IEC 104 network. It is a 2-byte value (1 to 65534). Each controlled station must have a unique ASDU address.
This is equivalent to the slave address in Modbus or the outstation address in DNP3.
Step 3. Map Information Object Addresses (IOAs)
Every data point (status indication, measurement, command) needs an Information Object Address (IOA). IOAs are 3 bytes (range: 1 to 16777215).
| Data Type | Type ID | IOA Range (example) |
|---|---|---|
| Single-point indication | M_SP_NA_1 (1) / M_SP_TB_1 (30) | 1–100 |
| Double-point indication | M_DP_NA_1 (3) / M_DP_TB_1 (31) | 101–200 |
| Measured value, normalized | M_ME_NA_1 (9) / M_ME_TD_1 (34) | 201–400 |
| Measured value, scaled | M_ME_NB_1 (11) / M_ME_TE_1 (35) | 401–600 |
| Measured value, short float | M_ME_NC_1 (13) / M_ME_TF_1 (36) | 601–800 |
| Single command | C_SC_NA_1 (45) / C_SC_TA_1 (58) | 1001–1100 |
| Double command | C_DC_NA_1 (46) / C_DC_TA_1 (59) | 1101–1200 |
| Setpoint, scaled | C_SE_NB_1 (49) / C_SE_TB_1 (62) | 1201–1300 |
⚠️ Warning: IOA numbering is entirely up to the system integrator. There is no standard range. Always document your IOA map and share it with the SCADA configuration team. Mismatched IOAs are the number one cause of “data not appearing” in SCADA.
Step 4. Configure Event Buffers
The controlled station buffers spontaneous events (status changes, measurement threshold crossings) and sends them as I-frames with timestamps. Configure:
- Buffer size (number of events per type)
- Whether to use timestamps (always recommended — use CP56Time2a format)
Step 5. Set the k and w Parameters
| Parameter | Meaning | Typical Value |
|---|---|---|
| k | Maximum number of unacknowledged I-frames the sender can transmit before waiting for an S-frame acknowledgment | 12 |
| w | Number of I-frames received before the receiver must send an S-frame acknowledgment | 8 |
Rule: w must be less than or equal to 2/3 of k. If k = 12, then w should not exceed 8.
7. Step-by-Step: Configure the Controlling Station (SCADA Master)
Step 1. Add Controlled Stations
For each RTU/IED, configure:
- IP address
- TCP port (2404)
- ASDU address (must match the controlled station’s setting)
Step 2. Map IOAs to SCADA Tags
Each IOA from the controlled station must be mapped to a tag in the SCADA database. This mapping connects the raw IEC 104 data point to a named variable that operators see on the HMI.
Step 3. Configure General Interrogation
Set the controlling station to send a General Interrogation (GI) command (type ID 100) after connection establishment and periodically (every 15–60 minutes). GI forces the controlled station to send the current value of all its data points — like a full integrity poll.
Step 4. Configure Clock Synchronization
Set the controlling station to send clock sync commands (type ID 103) at regular intervals to keep RTU timestamps accurate.
8. Timeout Parameters: t0, t1, t2, t3
IEC 104 defines four timeout parameters that control connection behavior. Misconfigured timeouts are the most common cause of connection instability.
| Parameter | Purpose | Typical Range | Default |
|---|---|---|---|
| t0 | Connection establishment timeout — time to complete TCP + STARTDT handshake | 10–30 s | 30 s |
| t1 | I-frame acknowledgment timeout — time to wait for ACK after sending an I-frame | 10–60 s | 15 s |
| t2 | Acknowledgment delay — time before sending an S-frame when no I-frames arrive | 1–10 s | 10 s |
| t3 | Idle supervision timeout — time before sending TESTFR ACT to check if the link is alive | 20–300 s | 20 s |
Critical Rules
- t2 must be less than t1. A good rule: t2 < t1/2. If t1 = 15 s, set t2 ≤ 7 s.
- t3 should be greater than t1. Typically 2–4 times t1.
- t0 should allow for network latency. On VPN/cellular links, set t0 to 30–60 s.
Example Configurations
| Scenario | Network | t0 | t1 | t2 | t3 |
|---|---|---|---|---|---|
| LAN (fiber/Ethernet) | Local | 10 s | 15 s | 5 s | 25 s |
| WAN (MPLS) | Managed | 20 s | 30 s | 10 s | 60 s |
| Cellular/VPN | Public | 30 s | 45 s | 10 s | 120 s |
⚠️ Warning: If you see frequent reconnections in your SCADA logs, the first thing to check is t1. If t1 is shorter than the actual network round-trip time, the controlling station will close the connection thinking the RTU is unresponsive. Increase t1 gradually until reconnections stop.
For a deep dive into timeout tuning with diagrams and real examples, see: Adjusting Timeout Values (t0–t3) in IEC 60870-5-104
9. General Interrogation and Data Flow
Normal Data Flow
During normal operation, the controlled station sends data spontaneously:
- A status change or measurement threshold crossing occurs.
- The controlled station creates an ASDU with the new value and a CP56Time2a timestamp.
- It sends the ASDU as an I-frame with Cause of Transmission (COT) = 3 (spontaneous).
- The controlling station acknowledges with an S-frame or its own I-frame.
General Interrogation (GI)
GI is used to get a full snapshot of all data points. The controlling station sends type ID 100 (C_IC_NA_1) with COT = 6 (activation).
The controlled station responds by sending all its current data with COT = 20 (interrogated by station interrogation) and finishes with a GI confirmation (COT = 10, activation termination).
When to Use GI
- After initial connection (STARTDT confirmed)
- After a communication interruption
- Periodically (every 15–60 minutes) to catch any missed events
- After a controlled station restart
10. Time Synchronization (CP56Time2a)
Accurate timestamps are essential for event sequence analysis and fault investigation. IEC 104 uses the CP56Time2a format — a 7-byte timestamp with millisecond resolution.
How It Works
- The controlling station sends a Clock Synchronization command (type ID 103, C_CS_NA_1).
- The controlled station adjusts its clock.
- All subsequent events include CP56Time2a timestamps.
Configuration
- Set the controlling station to send clock sync every 10–60 minutes.
- For higher accuracy, use SNTP or GPS/IRIG-B on the controlled station as the primary time source, and use IEC 104 clock sync as a backup.
- Check the IV (Invalid) flag in timestamps. If the controlled station’s clock is not synchronized, it sets the IV bit to 1 — the SCADA system should flag these events as having unreliable timestamps.
11. Redundant Connections
IEC 104 Edition 2 (2006) added support for redundant TCP connections between controlling and controlled stations. This improves reliability for critical infrastructure.
How It Works
- Two independent TCP connections are established between the SCADA master and RTU, typically over two separate network paths.
- One connection is active (carrying data), the other is in standby.
- If the active connection fails, the standby connection takes over.
- The switchover uses STARTDT/STOPDT to manage which connection carries data.
Configuration
- Both connections use the same ASDU address.
- Each connection has independent sequence numbers (send/receive counters).
- Configure both paths in the controlling and controlled station.
- Test failover regularly to confirm it works within acceptable switchover time.
12. Security Considerations
IEC 104 was designed without built-in security. All traffic is unencrypted. There is no authentication. This is the same situation as Modbus TCP.
Risks
- Unauthorized access: Any device that can reach port 2404 can read all SCADA data and send commands.
- Command injection: An attacker can send control commands (type IDs 45–69) to open/close breakers or change setpoints.
- Eavesdropping: All data including measurements and commands is plain text.
- Man-in-the-middle: Traffic can be intercepted and modified.
Protection
- IEC 62351-3 defines TLS encryption for IEC 104. The secure variant uses TCP port 19998.
- IEC/TS 60870-5-7 defines security extensions specifically for IEC 101 and IEC 104, including authentication mechanisms.
- Network segmentation: Keep IEC 104 traffic on a dedicated VLAN or network.
- Firewall rules: Restrict port 2404 (and 19998 for TLS) to authorized SCADA IPs only.
- VPN tunnels: Encrypt all IEC 104 traffic crossing WAN or public networks.
- Monitoring: Deploy OT intrusion detection to watch for unauthorized connections and unusual commands on port 2404.
⚠️ Warning: Never expose TCP port 2404 to the internet. Thousands of IEC 104 devices have been found on Shodan with no protection. Always use VPN and firewall rules.
13. Troubleshooting Common Issues
| Problem | Likely Cause | Solution |
|---|---|---|
| TCP connection established but no data | STARTDT not sent or not confirmed | Check that the controlling station sends STARTDT ACT and the controlled station replies with STARTDT CON. |
| Frequent disconnections | t1 timeout too short for network latency | Increase t1. Monitor round-trip time and set t1 higher. |
| Data appears after long delay | t2 too long — S-frame ACK delayed | Reduce t2 to 3–5 seconds. |
| “Link idle” alarms | t3 too short — TESTFR triggers too often | Increase t3 to 60–120 seconds. |
| Connection fails at startup | t0 expired before TCP handshake completes | Increase t0. Check firewall and port 2404 access. |
| Data points missing in SCADA | IOA mismatch between RTU and SCADA | Verify IOA mapping on both sides. Run General Interrogation to see all available points. |
| Timestamps show invalid (IV=1) | RTU clock not synchronized | Send clock sync commands. Check if RTU has SNTP/GPS time source. |
| Commands rejected by RTU | Wrong type ID or IOA for command points | Check command type ID and IOA mapping. Verify Select-Before-Execute if required. |
| Duplicate events after reconnection | GI overlaps with buffered spontaneous events | Normal behavior — SCADA should handle deduplication based on timestamps. |
| k limit reached — data stops flowing | Receiver not sending S-frame ACKs fast enough | Check w parameter. Ensure receiver sends ACK before k limit is reached. |
Summary
IEC 60870-5-104 is a mature, well-proven protocol for SCADA communication over TCP/IP networks. It gives you spontaneous event reporting, timestamped data, general interrogation, and redundant connections — all things that simpler protocols like Modbus cannot provide.
Here is a quick checklist before going live:
- TCP port 2404 open between controlling and controlled stations
- ASDU address unique and matching on both sides
- IOA map documented and verified on both sides
- Timeout parameters tuned for your network (t2 < t1, t3 > t1)
- STARTDT/STOPDT sequence working
- General Interrogation configured at startup and periodically
- Clock synchronization active (IEC 104 and/or SNTP/GPS)
- Network segmented and port 2404 firewalled
- Redundant connections tested if configured
The protocol handles the complexity of real-time telecontrol well. When problems occur, they are almost always in the timeout tuning, IOA mapping, or network configuration — not in the protocol itself.