What Is the ICCP Protocol? TASE.2 (IEC 60870-6) Explained

ICCP is the protocol utility control centers use to talk to each other. Not to substations. Not to RTUs. To other control centers: the neighboring utility, the regional transmission operator, the power pool, an independent generator’s dispatch center.

Its official name is TASE.2, the Telecontrol Application Service Element 2. The standard behind it is the IEC 60870-6 series, and the core document is IEC 60870-6-503:2014, which defines the TASE.2 services and protocol. Almost nobody in the field says “TASE.2.” Everyone says ICCP. Both names refer to the same thing, and this guide uses them interchangeably.

If you run an EMS or SCADA system at transmission level, you almost certainly have ICCP links in service right now. They carry the tie-line measurements, breaker states, and interchange data that let neighboring grids operate as one system.

ICCP at a glance

Item	Detail
Official name	TASE.2 (Telecontrol Application Service Element 2)
Common name	ICCP (Inter-Control Centre Communications Protocol)
Defining standards	IEC 60870-6-503 (services and protocol), IEC 60870-6-702 (functional profile), IEC 60870-6-802 (object models)
Current editions	6-503 Ed. 3.0 (2014), 6-702 Ed. 2.0 (2014), 6-802 Ed. 3.0 (2014)
Scope	Control center to control center data exchange over WANs
Foundation	MMS (ISO 9506) client-server model
Transport	OSI upper layers over TCP/IP via RFC 2126 (ITOT); IPv4 mandatory
Access control	Bilateral tables enforced by the server
Typical data	Real-time measurements, status indications, device controls, operator messages, scheduling data
Security	Base protocol has none; IEC 62351-4 adds authentication and TLS

The problem ICCP solves

A single control center sees its own network through its own SCADA. But power systems don’t stop at ownership boundaries. Utility A’s state estimator needs the MW flow on the tie-line that Utility B meters. The regional operator needs breaker states from every member. A generation dispatcher needs setpoints delivered from the balancing authority.

Before ICCP, every one of those links was a custom job. Two utilities would agree on a proprietary protocol, or worse, exchange data through modem links and manual processes. Every new interconnection partner meant a new integration project.

ICCP standardized this. Per the introduction of IEC 60870-6-503, it allows data exchange over wide area networks between a utility control center and other control centers, other utilities, power pools, regional control centers, and non-utility generators. The exchanged data covers real-time and historical monitoring and control data: measured values, scheduling data, energy accounting data, and operator messages.

One protocol, one integration approach, any number of partners. That’s the pitch, and after roughly three decades in service, it has held up. ICCP remains the dominant protocol for inter-control-center links worldwide.

Where ICCP lives in the IEC 60870-6 series

IEC 60870-6 is the branch of the 60870 family built on ISO protocols and ITU-T recommendations. That distinguishes it from the 60870-5 branch, which gave us IEC 101 and IEC 104. Different lineage, different design philosophy, different job.

Three documents define TASE.2:

IEC 60870-6-503 is the heart of it. It defines the TASE.2 model, the objects, the operations and actions, and how everything maps onto MMS services. When someone asks what ICCP actually does, the answer is in this document.

IEC 60870-6-702 is the functional profile. It nails down the exact protocol stack: which MMS services are required, which are excluded, what the presentation and session layers must support, and how the whole thing rides on TCP/IP. It also contains the conformance tables that implementations get tested against.

IEC 60870-6-802 defines the object models: the structure of indication points, control points, quality codes, and timestamps that give the transferred data its meaning.

You need all three to build an implementation. You need mainly 6-503 to understand one.

ICCP is an MMS application

This is the single most important thing to understand about ICCP’s design. TASE.2 does not define its own wire protocol. It sits on top of MMS, the Manufacturing Message Specification (ISO 9506), and describes a standardized way of using MMS services.

MMS gives you generic client-server operations: read a variable, write a variable, define a named variable list, receive an unsolicited information report. What MMS does not give you is power-system semantics. MMS will happily read a variable for you, but it has no concept of “send me this data set only when a value changes, buffered over two seconds, with an integrity refresh every ten minutes.”

That’s what TASE.2 adds. In the words of 6-503, TASE.2 enhances MMS by specifying structured data mapped to MMS objects and assigning specific semantics to it. Every ICCP operation ultimately becomes an MMS service call. Get Data Value becomes an MMS Read. Create Data Set becomes DefineNamedVariableList. A transfer report arrives as an MMS InformationReport. The standard defines this mapping operation by operation.

The practical consequence: if you understand MMS from IEC 61850 work, ICCP will feel familiar fast. Same client-server model, same named variables, same reporting concept. Different object semantics.

The protocol stack

The functional profile in IEC 60870-6-702 fixes the stack as follows, from top to bottom:

At the application layer, three elements work together: TASE.2 itself, MMS, and ACSE (the Association Control Service Element, which handles establishing and releasing the application association). Below that sit the OSI connection-mode presentation and session layers. Below that, RFC 2126, known as ITOT, carries the ISO transport service over TCP. Then ordinary TCP/IP. The profile makes IPv4 support mandatory.

Yes, that is a full OSI upper-layer stack running over the internet protocol suite. It looks archaic in 2026, and the ASN.1 encoding at the presentation layer is a genuine source of implementation complexity. But it works, it’s stable, and it’s the same upper-layer arrangement IEC 61850 MMS uses, which is why the two protocols often share library code inside vendor products.

One stack detail matters operationally: ICCP associations are designed to be long-running. Per 6-503, an association is established when two TASE.2 instances start and remains in place as long as both are running and the underlying connection holds. 6-702 goes further and notes there is no requirement for either party to ever terminate an association. A healthy ICCP link stays up for months. If your link is bouncing, something is wrong.

Core concepts

Client, server, and the Virtual Control Centre

ICCP uses the MMS client-server model. The client asks; the server answers. A real control center usually plays both roles at once over the same link, because data flows both ways: you serve your tie-line values to your neighbor while pulling theirs.

The server side presents itself as a Virtual Control Centre, or VCC. The VCC is an abstract model of the real control center: only the data and behavior that the outside world is allowed to see. Behind the VCC there might be an EMS with forty servers and three databases. The remote client doesn’t know and doesn’t care. How real data maps into VCC objects is explicitly a local implementation matter, outside the standard’s scope.

Operations and actions

TASE.2 splits its services into two kinds. Operations are initiated by the client: get a value, create a data set, start a transfer, select a device. Actions are performed by the server on its own initiative: monitoring transfer conditions, sending a transfer report, signaling that a device operation succeeded or failed. Two services, Conclude and Abort, can be invoked from either side.

This split matters because it explains ICCP’s efficiency. The client sets things up once with operations. From then on, the server pushes data through actions, unsolicited, only when the agreed conditions occur. Nobody polls.

Bilateral agreements and bilateral tables

This is ICCP’s access control model, and it’s unusual enough to deserve attention.

Two control centers that want to exchange data first sign a bilateral agreement: an actual paper document listing exactly which data elements each side will provide to the other. All state-estimated MW, Mvar, and kV for substations X, Y, and Z, say. The list of what Center A gives Center B is separate from what B gives A.

The computer representation of that agreement inside the ICCP server is the bilateral table. Its internal format is a local matter, but the standard defines what it must contain: the client control center designation, a version identifier, the domain name, the permitted application references, and the lists of data value, data set, transfer set, and device objects with their access control specifications.

Enforcement is entirely the server’s job. Every incoming client request is validated against the bilateral table before being satisfied. When an association is initiated, the server checks the client’s control center identifier to confirm a bilateral agreement exists at all. After that, every operation goes through the general validity check: every identifier referenced must be covered by the agreement.

Two practical notes. First, there is no ICCP protocol for exchanging or synchronizing bilateral tables; both sides maintain their tables independently, which is why mismatched tables are the classic cause of ICCP commissioning pain. Both centers must agree on the table version out of band, and the Bilateral_Table_ID variable exposed by the server lets the client verify the version in service. Second, Edition 3.0 of 6-503 added a semantic model for bilateral tables based on CIM classes from IEC 61970-452, giving utilities a standard format for exchanging table contents as engineering data. That’s a topic for its own article.

Domains

Each remote partner’s view of your server is organized into a TASE.2 domain, an MMS domain that scopes that client’s objects. VCC-scope objects are visible to all authorized partners; ICC-scope (domain-specific) objects belong to one particular partner relationship. Your bilateral table with partner A governs A’s domain; partner B never sees it.

The ICCP object model

Everything ICCP transfers is modeled as an object. The main ones:

Data Value objects represent individual control center data items: an analog measurement, a breaker status, a structured point. The real data behind them is invisible; the remote client only ever touches the VCC representation. Four operations exist for them: Get Data Value, Set Data Value, Get Data Value Names, Get Data Value Type. The concrete types, IndicationPoint for monitoring data and ControlPoint for commands, are defined in IEC 60870-6-802, complete with quality flags and timestamp variants.

Data Set objects are ordered lists of data value identifiers held by the server. They exist so a client can handle hundreds of points as one unit. A data set can be created by the client at runtime or predefined by the server. Six operations manage them, from Create Data Set through Get Data Set Element Names.

Transfer Set objects are the workhorse. A transfer set binds a data set to transmission parameters: when to report, how, and with what guarantees. The current edition supports one normative type, the Data Set Transfer Set. Three older types (Time Series, Transfer Account, and Information Message transfer sets) were deprecated in Edition 3.0 and moved to informative annexes. The transmission parameters include the start time, report interval, integrity check interval, a report-by-exception flag, a critical flag that demands client acknowledgment, and a buffer time that coalesces rapid event bursts into a single report.

Information Message objects carry free-form text or binary content between operator applications. A header identifies source and purpose; the InfoStream carries the body, printable or not.

Device objects represent controllable equipment and come in two classes: direct control, and select-before-operate. SBO devices implement the two-step pattern every protection engineer knows: the client Selects, the server checks availability and returns a CheckBackID agreed in the bilateral table, the device sits in the ARMED state, and the client must Operate within the agreed timeout or the selection drops back to IDLE. The server then reports Success or Failure of the actual command as a separate action, because a positive Operate response only confirms the device received the command, not that it executed.

Special transfer objects ride along inside transfer reports to describe the report itself: the transfer set name, the conditions that triggered it, a timestamp, and an event code. Include them in a data set and every report for that set carries its own provenance.

How data actually moves: the four transfer patterns

The standard defines four mechanisms, and real ICCP links use all of them.

One-shot data. The client reads current values on demand with a Get operation. Typical use: a state estimator pulling a fresh snapshot before a run.

Periodic data. The client creates or picks a data set, grabs an available transfer set with Get Next DSTransfer Set, and issues Start Transfer with a report interval. The server then reports the full data set on that cycle until the client issues Stop Transfer. This is the classic fixed-rate ICCP feed, tie-line values every four seconds.

Event data. Same setup, but the trigger is a condition rather than a clock: a status change, an analog deadband violation, a quality change, a tag change, an operator request, or an agreed external event. The buffer time parameter lets a burst of related changes produce one report instead of twenty.

Exception data. Report-by-exception. Only values that changed since the last report are included. The integrity check interval forces a full refresh of everything on a slower cycle, so the client’s database can’t drift. If no integrity scan is configured, the client is responsible for fetching initial values itself with a one-shot read. Miss that detail and you’ll stare at empty points after a restart wondering why.

Most production links run a mix: exception reporting for the bulk of points, a short periodic set for critical values, one-shot reads at application startup.

Conformance blocks: what a server actually supports

ICCP capability is packaged into numbered conformance blocks. When a vendor says their gateway “supports blocks 1, 2, and 5,” this is what they mean.

Block	Function	Status in the 2014 editions
1	Basic services: associations, data values, data sets, DS transfer sets	Mandatory
2	Extended condition monitoring (RBE, integrity, buffering)	Optional
3	Blocked (compact-encoded) transfers	Optional
4	Information messages	Optional
5	Device control, including SBO	Optional
6	Program control	Out of scope
7	Event reporting	Out of scope
8	Accounts / additional user objects	Out of scope
9	Time series	Out of scope

The 2014 revision cut deep. Blocks 6 through 9 were removed from scope because, per the foreword of 6-702, they were seldom used and their capabilities are typically implemented by other means. The related object models were downgraded to informative. So if a datasheet still advertises block 8 support, that’s a feature the current standard no longer even tests.

A server advertises its live capability at runtime through the Supported_Features named variable, a bit string the client can read right after connecting. Real-world links overwhelmingly run blocks 1 and 2, add 5 where remote control is in the agreement, and use 4 for operator messaging.

Security: assume none, then add IEC 62351-4

The base protocol was designed in the 1990s for trusted private networks. Native ICCP has no authentication beyond the bilateral table check of the claimed control center identity, and no encryption at all. The bilateral table is authorization, not authentication: it decides what a claimed identity may access, but does nothing to prove the identity.

Two things address this. First, the 2014 edition of 6-702 deliberately shrank the attack surface by excluding every MMS service TASE.2 doesn’t need. MMS defines over 86 services; the profile marks the unnecessary ones as excluded, meaning an implementation shall behave as if they don’t exist. The standard states plainly that this was done for security.

Second, IEC 62351-4 defines the security profile for MMS-based protocols, adding application-layer authentication through ACSE and transport-layer protection with TLS. The 6-702 conformance tables include it as an optional feature of association management. In practice, adoption is uneven: many ICCP links still run in the clear over private or MPLS networks, with security provided by network isolation and, increasingly, by regulatory pressure. If you’re specifying a new link, require 62351-4 support and current TLS. The protocol hooks are standardized; the excuse not to use them is gone.

ICCP compared to its neighbors

ICCP vs IEC 61850. Both ride on MMS, which causes endless confusion. The split is by job: IEC 61850 models substations and the devices inside them; ICCP models control centers and the data exchanged between them. A breaker in 61850 is a logical node with a full data model; in ICCP it’s a data value or a device object whose meaning was fixed in a bilateral agreement. The two meet inside utilities constantly, 61850 hauling data up from substations, ICCP passing the aggregate sideways to neighbors, but they don’t overlap.

ICCP vs IEC 60870-5-104. IEC 104 is a master/outstation telecontrol protocol, built for a control center supervising field sites. Some utilities do press it into center-to-center service, and it works for simple point lists. What it lacks is everything ICCP was designed around: named objects instead of point numbers, client-managed data sets, bilateral-table access control per partner, and a standard device selection model between peers. For a link between two organizations that don’t share an engineering database, names and agreements beat address maps.

ICCP vs DNP3. Same story as IEC 104, North American edition. DNP3 dominates field telemetry there, and ICCP dominates the links between balancing authorities, reliability coordinators, and utilities.

Practical realities of running ICCP links

A few things the standard says quietly and operations experience says loudly.

Associations should stay up. The protocol expects long-running connections, and the standard even permits associations that never terminate gracefully, ending only if the underlying connection is lost. Monitor association state as a first-class alarm.

Redundancy lives below TASE.2. The standard’s network model shows WAN and mesh topologies with redundant routing between centers, but path failover is the network’s job. Most utilities run redundant ICCP servers and dual WAN paths; the protocol itself just needs a TCP connection that works.

QOS by association. When different traffic classes need different treatment, the model is one association per QOS level, with priority agreed between the centers in advance and handed to the transport layer. The client picks the association matching the operation’s priority.

Commissioning is table reconciliation. The protocol part of a new ICCP link usually works in an afternoon. The weeks go into aligning two independently maintained bilateral tables: object names, types, deadbands, scan classes, and the agreement paperwork behind them. Check Bilateral_Table_ID on both sides before you check anything else.

FAQ