IEC 60870 Engineering Wiki

Learn IEC 60870 from protocol evidence, not memorized byte tables.

This is a practical learning center for engineers working with IEC 60870-5-101, IEC 60870-5-103, and IEC 60870-5-104. It explains the protocol family, how frames are shaped, what healthy sessions look like, what usually breaks in the field, and how to turn raw TX/RX traffic into defensible evidence.

Source and legal scope

This page is a field guide, not a replacement for the IEC standards.

IEC standards are licensed publications. This wiki uses public descriptions, the ARIEC60870 implementation model, and practical engineering explanations. It intentionally does not reproduce protected normative tables. For formal conformance work, buy and use the official IEC publications.

Beginner primer

If you are new to IEC 60870, start with the SCADA picture.

IEC 60870 is not a screen protocol. It is a field communication family used so control centers, gateways, RTUs, and relays can exchange status, measurements, events, and control commands in a predictable way.

Control center / master

The master initiates communication, polls data, sends commands, and expects proof. In IEC-101 and IEC-103 this often means controlled serial polling. In IEC-104 it means TCP session control plus ASDU exchange.

RTU / outstation

The RTU or outstation exposes field points: breaker status, alarms, analog values, counters, and command targets. It may answer only when polled, or it may advertise pending high-priority data.

Protection relay / IED

A relay is not just another RTU. It can provide protection events, disturbance-related data, relay timestamps, and relay-specific FUN/INF addressing that must be mapped carefully.

Point list and mapping

The protocol tells you addresses and raw values. The project point list tells you what those points mean in the substation. Friendly signal names must come from user-owned mapping data, not guesses.

Plain-language flow

What happens when a SCADA engineer says "test the protocol"?

  1. ConnectOpen the serial or TCP path and prove that the remote device answers at the communication layer.
  2. Identify addressingConfirm the link address, Common Address, IOA or FUN/INF, and profile settings match the project point list.
  3. Build the snapshotRun General Interrogation or background polling to learn the current state of the station.
  4. Watch eventsDrain high-priority data when the device advertises it and keep relay/device timestamps when available.
  5. Prove commandsShow command request, confirmation, feedback, timeout, and termination evidence before calling it successful.
  6. ReportExport the evidence so another engineer can understand what happened without sitting beside the test PC.

Protocol map

Where IEC 101, IEC 103, and IEC 104 fit.

IEC 60870 is a telecontrol standards family. In daily SCADA and protection work, the names engineers meet most often are 101, 103, and 104.

Protocol Typical job Transport shape Evidence you inspect Common field failure
IEC 60870-5-101IEC-101 RTU/outstation telecontrol for serial links. Asynchronous serial, FT1.2 style link framing, balanced or unbalanced procedures depending on profile. Link control bits, Class 1/Class 2 polling, ASDU Type/COT/CA/IOA, GI and commands. Wrong CA/IOA, bad polling policy, endless Class 1 requests, missing ACTCON, incomplete GI.
IEC 60870-5-103IEC-103 Protection relay communication and event/measurand exchange. Serial relay link using IEC-103 ASDUs and relay-oriented FUN/INF addressing. Reset/link state, relay event timestamps, Type/COT, FUN/INF, generic service evidence. Mapped names guessed from vendor behavior, relay timestamp ignored, event drain confused with polling.
IEC 60870-5-104IEC-104 Network access to IEC-101-style application data over TCP/IP. TCP session with APCI control, U-frames, I-frames, S-frames, and ASDUs. STARTDT/STOPDT/TESTFR, send/receive sequence counters, ASDU CA/IOA, GI and command lifecycle. TCP connected but STARTDT not confirmed, sequence counter mismatch, CA mismatch, idle TESTFR symptoms.

Mental model

Read every IEC 60870 problem from the outside inward.

Do not start by interpreting one hex byte in isolation. Establish the session, link, address, ASDU, object, quality, and timing evidence in order.

01Physical or TCP reachability

Serial parameters, RS-485 direction, modem behavior, TCP port, firewall, latency, and idle disconnects.

02Link or APCI session health

IEC-101/103 link control and FCB/FCV behavior; IEC-104 STARTDT, STOPDT, TESTFR, and sequence counters.

03Application addressing

Type identifier, Cause of Transmission, Common Address, IOA or FUN/INF, and profile-specific address lengths.

04Process meaning

Single or double indications, measurands, commands, protection events, timestamps, quality, and project mapping.

05Operator evidence

What changed, what failed, what proof supports it, and what the next engineering action should be.

Frame anatomy

Understand the building blocks before chasing symptoms.

Exact field sizes depend on protocol mode and profile settings. The learning goal is to know which layer a field belongs to and what question it answers.

IEC-101 / IEC-103 serial frame

  1. FT1.2 envelopeStart, length, checksum, and end bytes prove frame integrity.
  2. Control and link addressDirection, primary/secondary role, ACD/DFC, FCB/FCV, and station selection.
  3. ASDU headerType, VSQ, COT, and Common Address describe application intent.
  4. Information objectIOA for IEC-101 or FUN/INF for IEC-103 identifies the point or relay function.
  5. Payload and timeValue, quality, command qualifier, or relay timestamp becomes engineering evidence.

IEC-104 APDU

  1. APCI start and lengthThe TCP stream is split into IEC-104 application protocol data units.
  2. U-frameSTARTDT, STOPDT, and TESTFR control the data-transfer session.
  3. I-frameCarries ASDU data and send/receive sequence counters.
  4. S-frameAcknowledges received I-frames without carrying process data.
  5. ASDU bodyShares IEC-101-style application concepts: Type, COT, CA, IOA, value, quality, and time.

Normal sequences

Healthy communication has a recognizable rhythm.

When the rhythm breaks, ARIEC60870 should show the missing step and keep the raw frame proof beside the explanation.

IEC-101 startup

Open serial link, optionally reset link, establish FCB state, optionally synchronize time, activate GI, receive confirmation and data, then return to controlled Class 2 polling.

Study GI startup

IEC-101 event drain

Poll Class 2 normally. When a response advertises ACD=1, request Class 1 in a bounded drain until no data, GI completion, ACD clear, DFC busy, timeout, or configured max drain.

Study Class 1/Class 2

IEC-104 session start

Open TCP, receive or send STARTDT activation, confirm data transfer, exchange I-frames/S-frames, use TESTFR for liveness, and close intentionally with STOPDT or TCP close.

Study IEC-104 session

IEC-103 relay evidence

Reset link/state, read identification or measurands as needed, drain Class 1 relay events, preserve relay timestamps, and map FUN/INF only through user-owned profile files.

Study IEC-103 events

Learning path

Use this order if you are learning IEC 60870 seriously.

The order below avoids the usual trap: memorizing type numbers before understanding session state, addressing, polling, and evidence.

1. Addressing first

Learn the difference between link address, Common Address, IOA, and IEC-103 FUN/INF before debugging values.

Read addressing guide

2. Startup and GI

GI is the clearest first proof that the outstation can deliver a usable process snapshot.

Read GI guide

3. Polling policy

Understand Class 2 background polling, ACD-driven Class 1 drain, DFC busy, and why uncontrolled Class 1 loops are bad evidence.

Read polling guide

4. Commands

Do not call a command successful until confirmations, feedback, termination, and quality/timing evidence make sense.

Read command guide

5. IEC-104 sessions

TCP connect is only the first layer. STARTDT, TESTFR, sequence counters, and I/S/U frame roles decide protocol health.

Read IEC-104 guide

6. IEC-103 relay events

Use relay timestamp when available, preserve raw FUN/INF, and avoid inventing vendor semantics without a mapping profile.

Read relay guide

Troubleshooting matrix

Turn symptoms into proof instead of guesses.

A good report does not say only "communication failed." It states the symptom, the evidence, likely cause, and next action.

Symptom Proof to capture Likely layer Start here
Port/TCP is open but no values arrive. Startup frames, GI activation/confirmation, returned ASDUs, timeout evidence. Session, polling, or addressing. GI incomplete
Device answers but values look wrong or empty. ASDU Common Address, IOA/FUN/INF, Type/COT, selected-frame decode. Application addressing or mapping. CA mismatch
Master repeats Class 1 requests with no useful data. ACD/DFC bits, request class, no-data responses, drain limit. Polling policy. Class 1/Class 2
Command was transmitted but not accepted. Command ASDU, ACTCON/ACTTERM, select/execute state, timeout, feedback event. Command lifecycle. ACTCON missing
IEC-104 connects but data transfer does not start. STARTDT activation, STARTDT confirmation, TESTFR, I/S/U frame sequence. APCI session control. STARTDT/TESTFR
Relay events appear at wrong time. Relay ASDU timestamp, PC arrival time, raw event frame, mapping profile. Event semantics or reporting. IEC-103 relay events

Glossary for frame reading

Terms that appear in real traces.

Use these terms as a practical decoder when reading frame trace, Smart Findings, and PDF evidence.

ASDUApplication Service Data Unit. The application payload carrying type, cause, address, object, value, quality, and time data.
COTCause of Transmission. Explains why a value or command response was sent: cyclic, spontaneous, activation, interrogation, and similar reasons.
CACommon Address. The application station identity inside an ASDU. It is not the same thing as the link address.
IOAInformation Object Address. The point address used by IEC-101/104 data and commands.
FUN / INFIEC-103 relay-oriented function type and information number. Keep raw values visible even when a mapping profile provides friendly names.
ACDAccess Demand. A secondary response can advertise that high-priority Class 1 data is waiting.
DFCData Flow Control. A busy signal; the master should back off and preserve the busy evidence.
GIGeneral Interrogation. Startup or operator-triggered process snapshot request.
ACTCONActivation confirmation. One important proof point in command execution.
CP56Time2aCommon timestamp format often seen in IEC-101/104 event data. Relay/event time should not be replaced by PC arrival time when the protocol timestamp exists.
I/S/U frameIEC-104 frame families: I carries ASDUs, S acknowledges sequence, U controls data transfer and tests.
QualityStatus flags that qualify a value or event. Bad, invalid, substituted, blocked, or overflow evidence can matter more than the value itself.

How ARIEC60870 helps

Use the tester as a protocol tutor and evidence recorder.

ARIEC60870 is built around an operator-first evidence hierarchy: readable meaning, current values, relay events, frame trace, findings, and report output. Raw hex stays available, but it is not the only language the engineer sees.

For learningRead the selected-frame explanation beside the raw TX/RX frame and connect fields to protocol meaning.
For FAT/SATKeep frame proof, decoded values, events, and findings in one evidence trail.
For support escalationExport a report that shows symptom, proof, likely cause, and next action without hiding raw frames.