ICCP Object Models: Indication Points and Control Points

Every value an ICCP link carries is an instance of an object model from IEC 60870-6-802:2014. When two control centers negotiate a bilateral agreement, a large part of the technical work is agreeing, point by point, which of these models and which type variant each point uses — because the type determines exactly what crosses the wire: value alone, value plus quality, plus timestamp, plus change counter.

This article covers the models that matter in current practice: IndicationPoint for monitoring data, ControlPoint for commands and setpoints, and ProtectionEquipmentEvent for protection events. All of it verified against the 2014 edition.

IndicationPoint: the monitoring workhorse

An IndicationPoint represents an input point — read-only from the client’s perspective. Its first decision is the PointType, one of four:

REAL — a 32-bit floating point value. Analog measurements: MW, Mvar, kV, Hz. The standard’s guidance: use REAL when the server has already scaled and normalized the value.

STATE — a two-bit coded state. The recommended type for single and double status points with up to three meaningful states: breakers, disconnectors, auto/manual, local/remote.

DISCRETE — a 32-bit integer. Three jobs: status points with more than three states, counter values, transformer tap positions — and raw unscaled analogs when the receiving side does the engineering-unit conversion.

STATESUPPLEMENTAL — a state value packed with tagging information and an expected state. When the expected state disagrees with the actual state, the provider is signaling a potential issue. Less common in the field, but it’s the type that lets a server share not just where a device is, but where it should be.

The two-bit state codes

For STATE points, the standard fixes the semantics of the four possible codes per device class. The pattern to internalize:

The same value tables are defined for DISCRETE (0 through 3) when it’s used for single/double point information. If you’ve worked with double-point information in IEC 60870-5-101/104, this is the familiar idea — intermediate, off, on, invalid — carried into the control center exchange.

The quality model

Quality is where ICCP earns its keep in multi-organization exchange, because the receiving center needs to know not just the value but how much to trust it. Four attributes:

Validity — VALID, HELD (previous value held over), SUSPECT (questionable), NOTVALID. The standard explicitly leaves the interpretation of HELD and SUSPECT local, which means their precise meaning belongs in the bilateral agreement, not in assumptions.

CurrentSource — where this value came from right now: TELEMETERED, CALCULATED, ENTERED (manual), or ESTIMATED (state estimator). This is the attribute that answers the operator question “is that a real measurement or an estimate?”

NormalSource — where the value normally comes from. The pair CurrentSource/NormalSource is quietly powerful: a point whose normal source is TELEMETERED currently showing ENTERED tells the remote center that someone is manually overriding telemetry — worth knowing before you dispatch against it.

NormalValue — NORMAL or ABNORMAL relative to the configured normal state for the point. A breaker that should be closed, reported open, carries ABNORMAL without the receiving side needing to know the configuration.

One subtlety carried over from the transfer sets article: a quality change is a change. An RBE transfer set reports a point whose value never moved but whose validity flipped — correct behavior, by design.

What actually crosses the wire

The models map to a family of MMS types, and the naming follows a strict pattern: a base type, then Q (with quality flags), then QTimeTag (quality plus timestamp), then Extended (quality, timestamp, and COV counter). So an analog point can travel as Data_Real, Data_RealQ, Data_RealQTimeTag, or Data_RealExtended, and the same ladder exists for State, Discrete, and StateSupplemental. Which rung each point uses is part of the point’s type in the bilateral agreement.

The quality flags ride in a single byte, Data_Flags, with a fixed bit layout: validity in bits 2–3, current source in bits 4–5, normal value in bit 6, timestamp quality in bit 7, bits 0–1 unused.

Except for STATE points — and this is the encoding trick worth knowing. Data_State uses that same byte but puts the two-bit state value in bits 0–1. State and quality share one byte. The consequence shows in the structures: Data_StateQTimeTag and Data_StateExtended have no separate Value component at all — the component named “Flags” is the state plus its quality. Engineers reading raw captures or writing parsers trip over this constantly: for real and discrete points, value and flags are separate components; for state points, they’re one byte, and a structure that looks like it’s missing its value isn’t.

Two more wire facts that matter for integration work: the COV counter is a 16-bit unsigned value that increments every time the owner sets a new value — so it wraps, and consumers should treat it as a change detector, not a lifetime total. And command values, setpoint discretes, and the SBO check-back value are all 16-bit integers, while DISCRETE indication values are 32-bit. Mixing those widths up is a classic gateway configuration error.

Timestamps

Two resolutions exist. TimeStamp is GMT-based with a minimum resolution of one second; TimeStampExtended adds millisecond resolution. Both record when the point’s value last changed, set at the earliest possible time after collection from the end device — meaning the timestamp travels with the data through the chain, it isn’t the time of the ICCP report.

Each timestamped type carries a TimeStampQuality flag: VALID only when the timestamp genuinely reflects the last change, INVALID otherwise. Check it before doing sequence-of-events analysis across a link; a server that can’t vouch for the time says so here, in bit 7 of the flags byte.

GMT-based is worth underlining for commissioning: ICCP timestamps carry no local time, no DST. If displayed times look shifted by your UTC offset, the link is fine and a display layer is helpfully “correcting” what was already correct.

ControlPoint: commands, setpoints, SBO, and tags

A ControlPoint represents an output — write-only, except for the attributes the server reports back. Its structure answers four questions:

What kind of control? COMMAND (a 16-bit integer) or SETPOINT, the latter split into REAL (32-bit float) and DISCRETE (16-bit integer). Command semantics are fixed by the standard the same way state codes are: 0/1 as Trip/Close or Open/Close or Off/On for switches, Lower/Raise for transformers.

Select first, or direct? DeviceClass is SBO or NONSBO. An SBO point carries three extra attributes: the selection State (SELECTED/NOTSELECTED), the Timeout — the maximum time the point may remain selected before operation, after which it falls back — and the CheckBackName. That last one is the SBO safety feature: a value identifying the physical object under control, agreed in the bilateral table and returned to the client on Select, so the operator can verify the right device is armed before operating. (IEC 60870-6-503 calls the same agreed value the CheckBackID; on the wire it’s a 16-bit integer.) The Select itself travels as an MMS Read returning a small structure of the timeout and selection state — the read-to-arm pattern covered in the Wireshark guide.

Is it tagged? Taggable points carry a Tag with three levels — NO-TAG, OPEN-AND-CLOSE-INHIBIT, CLOSE-ONLY-INHIBIT — plus a free-text Reason up to 255 characters. This is inter-center work-protection semantics: a center can tag its neighbor’s view of a device (“close inhibited — line crew on section 12”) and the reason text travels with the tag. On the wire, tag flags and reason move together as one structure.

What state is the control machinery in? The point exposes IDLE or ARMED — the two states of the select-before-operate cycle that the [SBO article] will walk through in full.

ProtectionEquipmentEvent: the 60870-5 immigrant

The third model reports protection operations — start (pickup) and trip events — and the standard says plainly that it’s based on IEC 60870-5-101. The heritage is visible in every attribute: SINGLE events carry a state, duration, and time; PACKED events carry per-phase start flags (general, phases 1–3, earth, reverse) or per-phase trip flags with relay operation timing; and the quality set is the 101 family’s — Blocked, Substituted, Topical, EventValidity, plus elapsed-time validity.

Two practical notes. These events are transient information — they report an occurrence, not a standing state, so they belong on event-triggered transfer sets, not integrity scans. And support is optional in the conformance tables on both client and server side; plenty of links don’t implement the model at all, passing protection information as ordinary status points instead. If per-phase protection detail across an ICCP link matters to your application, put the object explicitly in the agreement and the PICS check.

Choosing types in the bilateral agreement

The type ladder is a bandwidth-versus-information dial, and the right setting differs per point class. A pattern that serves well: Extended types (quality, timestamp, COV) for status points where sequence and change history matter; QTimeTag for important analogs; plain Q for bulk analogs where the report timestamp is good enough; and the bare base types almost never — a value without quality is a value the receiving center has to trust blindly, which is exactly what the quality model exists to avoid.

Whatever the choice, it must be identical on both ends per point. Type mismatches don’t negotiate and don’t degrade gracefully; they reject. When a freshly configured point fails while its neighbors work, comparing the agreed type variant character by character — RealQ versus RealQTimeTag — resolves it more often than anything else.

FAQ