IEC 61850 Buffered vs Unbuffered Reporting

Back to Blog

The Decision in One Paragraph

Choose by whether missing an event during a disconnect is acceptable. Protection operations, trips, alarms, and any sequence-of-events data must survive a client dropout, so they belong on a buffered report control block, which holds a queue of events in the IED and replays it - with the events' original timestamps - the moment the client reconnects. Live indication that is only meaningful right now, like a real-time status a wallboard shows, can use unbuffered reporting, which sends current values and simply forgets whatever happened while nobody was listening.

Buffering is not free: the IED holds a finite event queue, and a long enough disconnect can overflow it, after which the oldest events are lost and an overflow indication is set. So buffered reporting improves integrity but does not make it infinite - it buys time across normal reconnects, not indefinite storage.

Comparison and Configuration Notes

Both types are just modes of the report control block, so the dataset, trigger options, and optional fields are configured the same way; buffering is the added behavior. Reporting over MMS is the client-server path, distinct from the fast peer-to-peer GOOSE service. When events do not arrive after a reconnect, check whether the client reserved a BRCB rather than a URCB - a common cause of missing sequence-of-events data.

EntryID and Resynchronizing After a Dropout

The buffered report control block does more than queue events - it numbers them. Each buffered entry carries an EntryID and a time of entry, and the block maintains sequence numbering across reports. When a client reconnects, it can present the EntryID of the last report it processed, and the IED resumes delivery from the next entry onward, so the client receives exactly the missed portion of the backlog rather than a full replay. If the client's EntryID is no longer in the buffer - because the outage outlasted the queue - the device starts from the oldest entry it still holds, and the client should treat that as notice of a possible gap.

Two related mechanisms matter in practice. PurgeBuf lets a client deliberately clear the buffer, which is occasionally useful at commissioning but dangerous as a routine habit, since it discards exactly the history buffering exists to protect. And the buffer-overflow indication (BufOvfl) is the block's confession that events were lost; a client that ignores it will happily present an incomplete sequence-of-events record as if it were complete. A SCADA master's driver should surface both conditions, not swallow them.

Reservation and Serving More Than One Client

A report control block instance serves one client at a time. Buffered blocks support reservation, so a client can claim an instance and hold that claim across reconnects - which is what makes the resynchronization story work, since the buffer is being kept for that specific client. The consequence is an engineering rule: every client that needs its own event stream needs its own instance. A typical station allocates separate instances for the primary SCADA master, a backup master, and a local engineering client, each with the dataset it needs.

Instance shortages surface as mysterious integration failures: the second master cannot enable reporting because the only instance is already reserved by the first. The number of instances is fixed in the device configuration, so count the clients early, during system design, and check the capability of each intelligent electronic device against that count per the manufacturer's documentation.

Keeping the Buffer for What It Is Good At

Buffer capacity is finite and device-specific, so what you put on a buffered block determines how much outage it can absorb. Discrete events - trips, alarms, status changes - are rare and small, and a buffer holds a long history of them. A chatty analog on a data-change trigger is the opposite: it generates entries continuously and can fill the buffer quickly, evicting the very trip records the block was supposed to protect. The sound pattern is to keep buffered blocks for event-class data, apply sensible deadbands to any analog that must be buffered, and let routine analog telemetry ride an unbuffered block or periodic integrity reports instead.

It is equally important to know what the buffer is not: it is transit protection, not storage. Once events are delivered, they leave the queue; the buffered block is not a historian and cannot be re-read later. Durable sequence-of-events archiving belongs in the station's event recorder or the upstream historian - the buffered block only guarantees the events survive the trip there. That division of labor is consistent with the rest of the IEC 61850 design, which separates real-time reporting services from long-term records.

A Commissioning Test Worth Running

Before a site is accepted, prove the buffering actually works end to end:

1. Verify the dataset contents against the SCL engineering file, and confirm the configuration revision (ConfRev) the client expects matches what the device reports - a mismatch means the dataset changed after the client was configured.
2. Reserve and enable the buffered block from the production client, then generate test events and confirm they arrive with correct timestamps.
3. Disconnect the client - pull the cable or drop the tunnel - and generate more events while it is dark.
4. Reconnect and verify the backlog arrives, in order, with the original event timestamps rather than the reconnection time.
5. Confirm the client's handling of BufOvfl and of a purged buffer, so an overflow some future night produces an alarm rather than silent data loss.

Frequently Asked Questions