In IEC 61850 each client receives IED changes through MMS reports. The buffered report serves a client that cannot lose events, such as a gateway or a database; the unbuffered report serves a real-time application that prefers the current value. This guide explains how to choose, how each block is reserved, how many instances exist per client and how a client recovers after an outage.
Two report types, two different clients
Short answer. The buffered report (buffered) is meant for a client that must receive all events in order, even if the link drops. The unbuffered report (unbuffered) is meant for a real-time application that only needs what happens while it is connected. The choice is not a matter of taste: it depends on what the client does with the data.
The general mechanics (triggers, integrity, general interrogation, report contents) are in IEC 61850 reports and logs. This guide covers what comes next: which type to assign to each client, how the block is reserved and how it is defined in the SCL file.
Which type for which client
| Way of getting the data | Delivers the event instantly | Can lose information | Several clients on the same block | Typical client |
|---|---|---|---|---|
| On-demand query (polling, GetDataValues) | No | Yes | Yes, it is a read | A browser or an engineering tool |
| Unbuffered report | Yes | Yes | No | Real-time application, such as an HMI |
| Buffered report | Yes | No, up to the buffer limit | No | Concentrator, gateway or event database |
The practical rule: if the client builds a history or a sequence of events, use a buffered report. If it only draws the current state on a screen, the unbuffered report is enough and takes no buffer in the IED. Many implementations use the buffered report for digital signals (positions, trips, alarms) and the unbuffered report for analog measurements, which lose value as soon as the next one arrives.
How each block is reserved
IEC 61850-7-2 defines the ownership rules for each type of block:
- Buffered. The client configures the block and enables it (
RptEna). While it is enabled, other clients can only read its attributes, except to disable it or request a general interrogation. If the association is lost, the block keeps storing events in the buffer. - Unbuffered. The
Resvattribute exists: when true, the block is reserved exclusively for the client that set it and nobody else can change its attributes. If the client does not reserve it, enabling the block reserves it implicitly. If the association is lost, the server disables the block (RptEnaset to false).
That difference explains a very common symptom: after a communications outage, a client with an unbuffered report reconnects and receives nothing until it enables the block again. It is not an IED fault: the standard defines it this way.
One definition, several instances
In the SCL file (IEC 61850-6) the block is declared with the ReportControl element. The buffered attribute indicates whether it is buffered; its default value is false. Inside it there can be an RptEnabled element with the max attribute, which says how many clients can use it at the same time.
The standard clarifies that this definition is a type, not an instance. The real name of the block is formed from the declared name plus a two-digit number, from 01 up to max. With max="5" and the name PosReport, the IED offers PosReport01 to PosReport05. If clients are declared with ClientLN, the order of the list defines the number: the first client uses instance 01. In unbuffered blocks preconfigured with ClientLN, the Resv attribute is set to true together with RptEna.
This settles a frequent question: two SCADA systems that want the same events do not share a block; each takes its own instance.
What to adjust in the buffered block
The attributes that matter most in the field, according to IEC 61850-7-2:
- DatSet. Reference to the monitored data set. Changing this value has the same effect as clearing the buffer.
- ConfRev. Counts how many times the configuration of the data set changed (members deleted or reordered). It does not return to zero when the IED restarts. The client compares it with the value it expected: if it changed, its data mapping may be out of date. The value 0 is reserved.
- BufTm. Time, in milliseconds, that the block waits before sending, in order to group events.
- OptFlds. Optional report fields: sequence number, report time stamp, reason for inclusion, data set name, data reference, buffer overflow flag, EntryID and configuration revision.
- PurgeBuf. When set to true, the block discards the events it has not yet sent and the attribute returns to false.
- EntryID. Identifies an entry in the event sequence. It is used to acknowledge receipt and to resume sending.
For the EntryID and the entry time to arrive in the report, the client must enable both optional fields; the standard delivers them only if both are active.
- Open a new association. The previous one closed when the link dropped
- Configure the block. Optional fields, triggers and integrity period
- Write the last EntryID received. Without this value, the block starts from the first entry
- Enable the block (RptEna). The IED sends what was stored, after that EntryID
- Compare ConfRev. If it changed, review the data set mapping
Errors that keep repeating
- Two clients on the same block. The second one cannot enable it. Check how many instances the IED declares with
maxand which client each one is assigned to. - Gateway with an unbuffered report and gaps in the history. Move the event signals to a buffered report.
- Stale data after changing the data set. A change of
DatSetclears the buffer and changes ConfRev; the client must reread the configuration. - Reports that do not arrive even though the block exists. The block is disabled (
RptEnafalse) or the triggers do not include data change and quality change.
To see which fields each report carries on the network, the Wireshark capture shows the report identifier, the sequence number, the EntryID and the reason for inclusion.
MMS reports with Tiza Group
Is your SCADA losing events, or are two systems fighting over the same report block? At Tiza Group we configure and test reports with our IEC 61850 engineering and verify link recovery in the commissioning tests.
Related guides
- IEC 61850 reports and logs: BRCB, URCB and log
- IEC 61850 MMS: reports, SBO controls and files
- Data sets in IEC 61850
- IEC 61850 SCL files
- Causes of a rejected IEC 61850 control command
- GOOSE vs MMS
References
- IEC 61850-7-2 (edition 1, 2003): clause 14, buffered and unbuffered report control blocks; attributes RptEna, Resv, DatSet, ConfRev, OptFlds, BufTm, PurgeBuf and EntryID.
- IEC 61850-6 (edition 1, 2004): ReportControl, RptEnabled and ClientLN elements; formation of instance names.
- IEC 61850-8-1 (edition 1, 2004): mapping of reports to MMS (InformationReport service).
Frequently asked questions
Can one report control block serve two clients at the same time?
No. Each instance of a report control block, buffered or unbuffered, is used by a single client. To serve several clients, the IED must offer several instances of the same block, one per client.
Why does my gateway lose events when it uses an unbuffered report?
Because the unbuffered report only sends while the block is enabled by an active association. If the link drops, the IED stops sending and does not store what happened. Signals that cannot be lost use the buffered report.
What does the client do when it reconnects with a buffered report?
It opens the association, writes into the block the last EntryID it received correctly and enables the block. The block resumes with the next entry. If it writes no EntryID, the block starts from the first available entry.