Engineering

Report control blocks: buffered, unbuffered, and how many you actually need

2026-10-29 · 9 min read

Reporting is the mechanism that makes IEC 61850 usable at scale, and the part most often configured by trial and error. The choices are narrow — buffered or not, which triggers, which optional fields, how big a dataset — but each one changes what the master can reconstruct after a link failure, which is exactly when you need the data.

What buffering actually guarantees

An unbuffered report exists only while the association is up. The moment the link drops, the events that would have been reported are gone — the master gets a discontinuity and must resynchronise.

A buffered report keeps a bounded queue of events across association loss, and replays them when the client returns. Bounded is the important word: when the queue overflows, the oldest entries are lost and the device must tell the client that it has. A client that does not check for overflow will believe it has a continuous history when it does not.

Triggers and optional fields

Configure the smallest set that answers the operational question. Each optional field is bytes on the wire, multiplied by every event, on every report control block:

• Data change is the workhorse. Data update is for cyclic refresh of values that change continuously.
• Quality change and data-set change matter for diagnostics and almost never for control.
• Integrity is the periodic full snapshot; it is what rebuilds state after a failure without issuing a general interrogation, and it is worth its bandwidth.
• Reason code and sequence number make a capture readable. Timestamps are non-negotiable if you want sequence-of-events behaviour.

Sizing: an honest example

Take our published StationCore figure — a master client handling 200 IEDs with 10,000 attributes each. That is two million attributes. If half of them are subscribed per IED, and a busy bay changes 2% of its points per second, you are looking at thousands of events per second arriving at one process.

The number that matters is not how many attributes you can read; it is how many events per second your process can consume, in order, without dropping, while still answering controls. Measure that before promising anything.

• Prefer more, smaller datasets over one enormous one: a single dataset change invalidates the whole report.
• Keep the report control block count within what the device declares, and remember each enabled RCB costs memory on the server.
• Set the buffer size from the expected outage duration times the change rate, not from a default.

The five defects that appear after a link failure

• Reporting is re-enabled but no general interrogation is issued, so the master keeps the pre-outage snapshot for unchanged points.
• Buffer overflow is not checked, so the master reports a continuous history that has a hole in it.
• Entry identifiers are not tracked, so replay after reconnect duplicates events the master already processed.
• The integrity period is longer than the outage, so the rebuild only happens hours later.
• Ownership is not re-established, and the RCB stays disabled while the master believes it is enabled.

A configuration that works

For a protection or bay controller with a few hundred points:

• Two buffered RCBs — one for the fast status/trip events, one for measurements — and one unbuffered for diagnostic values.
• Integrity period set to something an operator would find acceptable as a worst-case staleness, not to the default.
• Optional fields limited to reason, sequence number and timestamp, plus data-set reference on integrity reports.
• Buffer size measured in events, sized from a stated outage assumption that is written down in the manual.

Questions that come up

Do we need buffered reporting for measurements?

Usually not. Measurements refresh continuously and the integrity report repairs them. Buffering matters for events you cannot afford to lose — status changes, protection operations.

How many report control blocks may a client enable?

As many as the server declares and can sustain. Enabling every RCB on a large device to "see everything" is a common way to overload both ends and then blame the protocol.

What does the client do with a discontinuity?

Treat it as "state unknown": issue a general interrogation, mark values stale until it completes, and log it. Silently continuing is how a control room ends up acting on pre-failure data.

Keep reading