ICCP Conformance Blocks: What Servers Actually Support

Every ICCP datasheet says the same thing: “supports blocks 1, 2, and 5” or some variation. Conformance blocks are how TASE.2 capability is packaged, sold, tested, and written into bilateral agreements. They’re also where datasheets, the wire protocol, and the standard itself quietly disagree.

This article decodes each block, explains why nearly half of them were deleted from the standard, and walks through the oddities in IEC 60870-6-503 and IEC 60870-6-702 that you should know about before you write “block X required” into a procurement spec.

Why blocks exist at all

TASE.2 was designed to scale. A small distribution utility exchanging fifty points with one neighbor shouldn’t need the same implementation as a regional operator running device control across twenty links. The standard solves this by cutting the service set into conformance building blocks: a simple TASE.2 implementation requires only a simple MMS implementation underneath, and capability grows block by block.

Block 1 is the floor. Everything else is negotiated — technically in the conformance statement, practically in the bilateral agreement between the two centers.

The server tells you itself: Supported_Features

Before trusting any datasheet, read one variable. Every TASE.2 server exposes a VMD-scope MMS named variable called Supported_Features, a bit string that declares its live capability. Its layout in the 2014 edition:

Bit position	Name	Meaning
0	Block1	Always 1 — basic services are mandatory
1	Block2	Extended condition monitoring
2	reserved	See the Block 3 oddity below
3	Block4	Information messages
4	Block5	Device control
5–9	reserved	Former blocks 6–10 territory
10	Block11	Named but not defined — see below
11	Block12	Named but not defined — see below

Reading this variable is step one of any interop session. It settles what the remote server claims to be, live, over the actual link — no PDF required.

The living blocks

Block 1 — Basic services (mandatory)

The foundation every implementation must have: association management (Associate, Conclude, Abort), data value operations (get, set, names, types), data set operations, and the Data Set Transfer Set with its baseline reporting conditions. Per the conformance tables in IEC 60870-6-702, block 1 covers interval-based reporting — start time, interval, IntervalTimeOut — plus operator-requested and externally triggered reports.

Translated to operations: with block 1 alone you get periodic full-set reporting and on-demand reads. That’s a working ICCP link. Plenty of simple feeds run exactly this.

Block 2 — Extended condition monitoring

Block 2 is where ICCP gets efficient. The 6-702 conformance tables assign it the condition set that makes event-driven exchange work: ObjectChange as a reporting trigger, IntegrityTimeout, report-by-exception (RBE), the Critical flag with client acknowledgment, Buffer Time for coalescing bursts, TLE (time limit for execution), and the integrity check interval.

In field terms: block 1 sends everything on a clock; block 2 sends what changed, when it changed, with a slow full refresh as a safety net. Almost every serious production link runs blocks 1+2, and the bandwidth difference on large point counts is dramatic.

Block 3 — Blocked transfers

Not “blocked” as in prevented — blocked as in packed. With the Block Data attribute set on a transfer set, the server encodes the report as a compact MMS octet-string instead of fully-typed MMS data, following defined blocking rules. The trade: less bandwidth and encoding overhead, against loss of per-value MMS typing on the wire.

Block 3 mattered more when ICCP links ran over thin WAN circuits. On modern networks it’s rarely enabled, and it carries a signaling oddity covered below.

Block 4 — Information messages

Free-format message transfer between control centers: a header identifying source and purpose, and an InfoStream carrying text or binary content. The classic use is operator-to-operator messaging and scheduled document exchange — outage notes, dispatch instructions — over the same secure link that carries the telemetry.

Block 5 — Device control

Remote control across the link: ControlPoint objects and the Device model, including select-before-operate with CheckBackID verification, timeouts, and tagging. Block 5 is the one to treat with respect. It’s the difference between a monitoring link and a link that can trip your neighbor’s breaker. Bilateral agreements scope it hard, and many utilities deliberately don’t enable it even when both ends support it.

Related conformance detail worth knowing: the SBO protection actions — Timeout Action, Success Action, Failure Action — are tied in the 6-702 tables to a separate conformance marker beyond plain block 5. When specifying device control, spell out the full SBO behavior you expect rather than writing “block 5” and hoping.

The dead blocks: 6, 7, 8, 9

The 2014 editions removed four blocks from scope entirely:

Block 6 (Programs) let a client start, stop, and kill programs on the remote server. Block 7 (Events) provided event enrollment and notification through the MMS event model. Block 8 (Accounts) carried energy accounting and scheduling objects — transfer accounts, profiles, curves. Block 9 (Time Series) transferred historical data series.

The stated reason for the removal: these blocks were seldom used, and their capabilities are typically implemented by some other means. Which matches field reality — energy accounting moved to market systems and flat-file exchanges, historical data to dedicated historian links, and remote program control was always a hard sell between organizations.

The removal was thorough. The object models went from normative to informative annexes, the related MMS services were excluded outright in the 6-702 profile, and the corresponding transfer set types (Time Series, Transfer Account, Information Message transfer sets as distinct objects) were deprecated. The old definitions survive only in informative annexes documenting the TASE.2 (2002) model for legacy reference.

The practical consequence: a datasheet still advertising block 8 or block 9 support is describing capability the current standard neither requires, tests, nor even signals — the bit positions are reserved. Legacy systems in the field may still use these features between themselves, but don’t specify them for anything new.

Three quirks worth knowing before an interop session

Reading the 2014 documents closely turns up three inconsistencies. None breaks anything, but each has confused a commissioning session somewhere.

Block 3 has no bit. Bit position 2 — where Block3 should sit — is marked reserved in the Supported_Features type, yet blocked transfers remain a live optional capability in the 6-702 conformance tables, and the Block Data attribute still exists on transfer sets. Meaning: you cannot discover block 3 support by reading Supported_Features. It has to be agreed in the bilateral agreement and confirmed in the vendor’s PICS. If you enable Block Data against a server that doesn’t support it, expect a rejected Start Transfer, not a graceful fallback.

Blocks 11 and 12 are ghosts. The bit string names them at positions 10 and 11, but nowhere in the 2014 edition are their features defined — and the type definition’s own cross-reference for block features points at a clause that now contains the CIM integration use cases instead. They’re reserved positions carried in the type. If a vendor claims block 11 or 12 support, ask them to define it, because the standard doesn’t.

The version number disagrees with itself. The introduction of 6-503:2014 states the TASE.2 version as 2001-08, while the normative definition of the TASE.2_Version variable in the same document says 2000.08. The normative variable definition is the one implementations expose, so expect major version 2000, minor 08 on the wire. If two implementations report versions that don’t match each other, check whether one vendor followed the introduction instead of the variable definition before assuming a real incompatibility.

Specifying and verifying blocks in practice

For a procurement spec or a new bilateral agreement, the workable pattern:

Require blocks 1 and 2 always — block 1 is mandatory anyway, and block 2 is what makes the link efficient. Add block 4 if operators or applications will exchange messages. Add block 5 only if remote control is genuinely in the agreement, and when you do, specify the SBO behavior in full: select timeout, CheckBackID handling, success/failure reporting. Treat block 3 as a special case requiring explicit PICS confirmation on both ends. Reject any requirement referencing blocks 6 through 9 for new systems.

Then verify in order: read the vendor PICS (the conformance statement 6-702 obliges every implementation to provide), read Supported_Features on the live server, and read TASE.2_Version and Bilateral_Table_ID while you’re there. Ten minutes with an MMS client answers what weeks of email threads won’t. The bilateral tables article covers the version-checking side of that handshake.

FAQ