What Is an IEC 61850 Report Control Block?

Back to Blog

What the Control Block Controls

MMS reporting in IEC 61850 is not polling - the IED pushes reports to a client when something the client cares about happens. The report control block is the configuration that makes this work. It points at a dataset (the collection of data attributes to watch), it is reserved by and enabled for a specific client, and it carries trigger options that decide when a report fires: on data change (dchg), on quality change (qchg), on data update, on a periodic integrity timer, or in response to a general interrogation request from the client.

The optional fields, set in the RCB, control what each report message actually contains - sequence number, timestamp, reason for inclusion, dataset reference, data reference, and so on. A client typically wants the reason-for-inclusion and timestamp so it can tell why a value arrived and when it was captured. Getting the trigger options and optional fields right is the difference between a clean, informative event stream and either a silent client or a link saturated with integrity traffic.

Buffered vs Unbuffered, and Where It Fits

The report control block comes in two flavors. A buffered report control block (BRCB) queues events in the IED while the client is disconnected and delivers them, with their original timestamps, when the client reconnects - which matters for sequence-of-events integrity. An unbuffered report control block (URCB) sends only what is happening now; events during a disconnect are simply lost. Protection and event data that must not be dropped uses buffered reporting; live indication that is only useful in the moment can use unbuffered.

Reporting is the client-server workhorse of IEC 61850, distinct from the fast peer-to-peer GOOSE messaging used for trips and interlocks. If you are choosing between mechanisms, the trade-offs sit alongside the Sampled Values stream on the process bus. For the buffered-versus-unbuffered decision specifically, the reservation and integrity-timer details deserve their own read.

The Client's Sequence: Read, Reserve, Configure, Enable

Getting reports flowing follows a fixed order. The client browses the IED's model to find the RCB instance it will use, reads its attributes, and reserves it - through the reservation attribute for unbuffered blocks or the reservation time attribute for buffered ones - so no other client can modify it. It then writes its configuration: which trigger options to enable, which optional fields each report should carry, the buffer time, and the integrity period. Only then does it set the report-enable attribute true, at which point the IED starts pushing reports over the MMS association.

Two attributes in that sequence deserve deliberate thought rather than defaults. Buffer time defines a short coalescing window: after the first triggering event, the IED waits that long, gathering any further changes into the same report before sending. A longer buffer time means fewer, fuller messages; zero means every change ships alone, which on a chattering point can flood the association. The integrity period sends the complete dataset on a timer regardless of changes - a safety net against missed events, but on a wide dataset over a constrained link it can become the dominant traffic on the wire.

After an interruption, buffered and unbuffered blocks resume differently. A URCB client simply re-enables and moves on. A BRCB client presents the entry identifier of the last report it processed so the IED resumes delivery from that point; asking instead for a buffer purge discards the history deliberately. Getting the resume step wrong either replays events the client has already handled or drops the very events buffering existed to protect.

ConfRev: the Attribute That Catches Silent Re-Engineering

The configuration revision attribute increments whenever the dataset behind the RCB changes - members added, removed, or reordered. A careful client records the ConfRev it commissioned against and compares it on every reconnect. A mismatch means the IEC 61850 dataset no longer contains what the client's point map assumes: positions in the report now decode to different data attributes, and values land on the wrong tags while everything appears healthy.

This is not a theoretical hazard. Substation IEDs get re-engineered - a protection engineer adds a point to a dataset during an outage, the configuration file is updated, and every client that decodes reports positionally is now wrong until it reloads its map. Treat a ConfRev change as a stop condition: halt processing, reconcile the dataset against the current configuration, and re-verify a handful of points end to end before trusting the stream again.

A Commissioning Checklist for Reporting

1. Confirm the dataset exists on the IED and every member resolves to a real data attribute.
2. Reserve the RCB and confirm a second client is refused while the reservation holds.
3. Write the trigger options deliberately - data change and quality change for event data, integrity only where the link can afford it - and read them back.
4. Cause a field change and verify the report arrives with the expected reason-for-inclusion and timestamp.
5. Break the association, generate events, reconnect, and confirm a buffered block delivers the missed events in order with their original timestamps.
6. Record the report identifier, dataset reference, and ConfRev in the commissioning record.

The quality-change trigger earns a note: enabling it means every excursion of a quality attribute - test, invalid, questionable - generates a report, which is exactly what a SCADA client needs to trust its data and exactly what an over-filtered client silently misses. Verifying it during commissioning means forcing a quality change, for instance by putting a function into test per site procedure, and watching for the corresponding report to arrive.

Frequently Asked Questions