ICCP vs IEC 61850: Two MMS Protocols, Two Jobs

The confusion is understandable. Both protocols are built on MMS. Both use the same OSI upper-layer stack. Both listen on TCP port 102 and 3782. Both show up in Wireshark labeled “MMS,” decoded by the same dissector. Vendors often implement them with shared library code.

And yet they solve completely different problems, and no project ever chooses between them. A utility that runs both is normal; a utility that replaces one with the other has misunderstood something.

This article explains what they actually share, where they diverge, and how they fit together in a real utility.

The one-line answer

IEC 61850 models the substation. ICCP moves data between control centers.

61850 exists so that a protection relay, a bay controller, and a station HMI from three vendors can share one data model inside a substation — and so protection functions can exchange trip signals in milliseconds. ICCP exists so two organizations, with completely separate SCADA systems and no shared engineering database, can exchange agreed data over a WAN under a signed agreement.

Vertical versus horizontal. Inside a facility versus between companies.

Side by side

What they genuinely share

The common ground is real, not superficial. Both are MMS applications in the strict sense: they define named variables and use MMS services — Read, Write, InformationReport, GetNameList, the named variable list operations — to move them. Both ride the same stack: ACSE for association control, OSI presentation with ASN.1 BER encoding, OSI session, and ITOT (RFC 2126) carrying it all over TCP. Both use ports 102 and 3782, and both are secured by the same IEC 62351 parts.

That shared foundation has practical consequences worth knowing:

Engineers who can read one can read the other. The Wireshark technique is identical, including the presentation-context fix needed when the capture misses association setup. The distinguishing signal is the variable names — 61850’s $-separated hierarchical references versus ICCP’s flat 32-character identifiers.

Vendor products reuse code. A gateway supporting both usually has one MMS stack underneath, which is also why a stack-level bug can surface in both protocols at once.

Skills transfer, concepts don’t. Knowing MMS gets you the plumbing. It gets you nothing about logical nodes or bilateral tables, which is where the actual work lives.

Where they diverge

The data model is the fundamental difference

61850’s model is standardized and self-describing. A circuit breaker is XCBR with a Pos data object; a three-phase measurement is MMXU; an overcurrent function is PTOC. Every relay from every vendor uses the same names, and a client can browse an IED and discover its structure — that’s the whole point, and it’s covered in the logical nodes reference.

ICCP’s model is agreed and flat. A point is SUBST_X_MW because two utilities wrote that name into a bilateral agreement. The object models standardize the containers — indication points, control points, quality flags, timestamps — but never the names or what they represent. Semantics live in a document signed by two companies, not in the protocol.

That’s not a deficiency. It’s a design response to a different problem. Inside a substation you can mandate a data model, because one organization engineers the whole thing. Between two utilities with independent EMS platforms, decades of legacy naming, and no shared authority, a mandated model would be unenforceable. Bilateral agreement is what works when nobody can impose a schema on anybody.

Configuration: SCL versus bilateral tables

61850 has SCL — a formal XML language describing the entire substation, exchanged as ICD, SCD, and CID files, processed by system configuration tools.

ICCP has no equivalent in the protocol. The bilateral table format is explicitly a local matter, and there is no protocol for exchanging tables. Both sides build their own from a shared paper agreement — which is exactly why the CIM-based ICCPBLT01 exchange model was added, giving utilities a standard file format for the same job SCL does inside a substation. The parallel is striking: both domains eventually concluded that engineering data needs a machine-readable exchange format, and each grew one.

Reporting: same idea, different plumbing

Both push data on change rather than polling. 61850 uses report control blocks with trigger options and buffered reporting. ICCP uses transfer sets — data set plus transmission parameters, with RBE, integrity intervals, buffer time, and a critical flag.

The concepts rhyme. The details don’t transfer: 61850’s buffered reports guarantee delivery across a connection loss, while ICCP’s guarantee comes from the Critical flag plus the integrity refresh cycle, and its TLE parameter will deliberately discard stale data — a design choice that surprises people from the substation world.

Control: two select-before-operate models

Both implement SBO, and the differences trip people up in exactly one direction.

In 61850, select is a write to SBO or SBOw, and the model offers direct-with-normal-security through select-before-operate-with-enhanced-security, with the enhanced variants adding CommandTermination — a positive confirmation that the command actually completed.

In ICCP, select is a read whose response carries the CheckBackID for device verification, operate is a write, and — as the device control article explains — the standardized completion signal maps to MMS services the profile excludes, so actual confirmation arrives through the associated indication point in the next transfer report.

Engineers moving from 61850 to ICCP consistently expect a write to arm and a termination message to confirm. Neither happens.

The parts 61850 has that ICCP doesn’t

GOOSE and Sampled Values have no ICCP counterpart, and shouldn’t. Both are raw Layer 2 Ethernet, engineered for millisecond and sub-millisecond determinism within a substation LAN. Neither concept survives a routed WAN between two companies, and inter-control-center data exchange has no need for them: the data arriving from the field is already seconds old by the time a control center is ready to share it.

Conversely, ICCP has bilateral tables — per-partner, server-enforced access control with rate limits and control scoping. 61850 has access control models, but nothing shaped like a two-party agreement, because inside a substation that problem doesn’t arise.

How they work together

In a modern utility the two chain rather than compete:

Field devices publish GOOSE and Sampled Values on the station bus and serve MMS to the station level. The substation gateway aggregates, and reports upward to the control center EMS — often over IEC 60870-5-104, sometimes over 61850 MMS directly, increasingly over 61850 for new builds. The EMS processes, estimates, and stores. Then ICCP carries an agreed subset sideways to neighboring control centers, regional operators, and market systems.

61850 goes up. ICCP goes across. A tie-line measurement can pass through all of it: sampled by a merging unit, reported by a relay, aggregated by a gateway, delivered to the EMS, state-estimated, then handed to a neighboring utility as an ICCP indication point with a quality flag saying ESTIMATED rather than TELEMETERED — a distinction the quality model exists to carry.

Choosing between them (the rare case)

Nearly always the domain decides. Two situations create genuine questions:

A control center reading directly from substations. 61850 MMS can do this, and for new-build utilities with 61850 end to end, it’s increasingly the answer. ICCP is the wrong tool: it has no substation data model, and its bilateral-table machinery is overhead when both ends belong to the same organization.

Two control centers where one proposes 61850 MMS instead of ICCP. Technically possible, occasionally proposed, rarely wise. You’d lose per-partner access control, the transfer set model tuned for WAN reporting, and the shared vocabulary every EMS vendor already implements for inter-center links — and you’d gain a data model neither side’s control center database is shaped like. ICCP exists for this case because this case is genuinely different.

FAQ