IEC 61850 Reporting and Logging: BRCB, URCB and Log

Short answer

In IEC 61850 the server sends changes to the client through reports. The buffered report (BRCB) stores events if the link goes down and delivers them on reconnection; the unbuffered report (URCB) sends them immediately and loses them if there is no connection. A log control block stores events inside the IED so they can be queried later. The trigger options are data change, quality change, data update, integrity and general interrogation.

What a report is and what it is for

Short answer. A report is the message with which an IED tells a client, such as the SCADA or a gateway, that something changed in a data set. It is generated on its own, without the client having to ask, and that is why it is the normal way to update a supervisory system.

Part 7-2 of IEC 61850 favors reports over repeated querying (polling): the report transmits the event immediately, minimizes network load and sends only when a condition is met. The standard adds two adjustment mechanisms: a low-frequency integrity scan, and a general interrogation that the client can request at any time. With them the client synchronizes its database with the state of the logical node.

The report reads a data set and is controlled by a report control block. The standard configures it in the server and limits access to one client at a time, which becomes its owner and receives its reports. For several clients, several instances are offered.

Buffered and unbuffered

	Buffered report (BRCB)	Unbuffered report (URCB)
If there is no connection	Keeps storing events, within a practical limit	Does not store; events may be lost
On reconnection	The client enables it again and receives the pending ones	Must request a general interrogation
Typical use	A defined client, such as the SCADA that needs sequence of events	Several instances visible so several clients receive the same; the client takes one that is free
Who owns it	Configured instances; once enabled, nobody else can change its parameters	Reserved with its own attribute or on enabling; if the connection is lost, the server disables it

The buffered report delivers the sequence of events (SOE): events arrive in the order in which they occurred. Each report carries a sequence number that starts at 0 when the block is enabled and grows by one, and an entry identifier to locate it in the queue. On reconnection, the client reports the last identifier it received correctly and the block continues from the next one. If it gives none, the block uses the first available. The server can indicate in the first following report that the buffer overflowed. When to use buffered and when unbuffered reports, and how they are recovered with EntryID, is in Buffered and Unbuffered MMS Reports.

Only the same client can receive what was stored: the standard restricts the view of the block so that it is received by whoever had it enabled.

What triggers a report

The list of conditions, which the client enables separately, is this:

Data change. The value of a data set member whose attribute declares it a trigger changed.
Quality change. The quality changed, such as going from good to invalid. It is explained in quality and time stamp.
Data update. An update event even though the value does not change, such as a statistic calculated every period or a frozen counter.
Integrity. A period set by the client: when it expires, the block reports all members. With value 0 there are no integrity reports.
General interrogation. The client sets the attribute to true, the block sends all the values and returns it to false.

The buffer time (BufTm) allows events that occur within a window to be gathered in a single report, up to one hour and in steps of 1 ms; with 0 each event generates its own report. If a second change of the same status member arrives within the window, the block immediately sends what has accumulated and restarts the window.

Recovery of a client using a buffered report

The link goes down. The block keeps its parameters and keeps storing events
The client reconnects. Opens a new association with the server
Indicates the last EntryID received. The block will continue from the next entry
Enables the block. The stored reports are delivered, without sequence gaps
Requests general interrogation. Optional: verifies that its picture matches the current state

What a report contains

The report always carries the block identifier and the values of the members that triggered it. Through optional fields, the client also requests: sequence number, report time stamp, reason for inclusion, data set name, data reference, buffer overflow flag, entry identifier and configuration revision. If a block does not support an option, it rejects the request.

There are two different times: the time of entry into the buffer and the time of the event. The time stamp of the report can differ from the time stamp of the data, which is the instant of the occurrence.

When the data set does not fit in a single message, it is sent in sub-reports with a subsequence number. If a change occurs while an integrity or general interrogation report is being transmitted, it can be sent in between with a higher sequence number; the client must use that number so as not to replace new data with old data from the earlier report.

In the mapping to MMS (part 8-1), the report travels as an information report with a variable list created, sent and deleted immediately.

The IED log

The log control block stores in the IED itself the values of the data set when the conditions of data change, quality change, update or integrity are met. General interrogation is not allowed for the log. The log works as a circular queue that overwrites the oldest entries, but for the client it is linear: each entry has an identifier and an entry time, and it is queried by time range or identifier range. The identifier keeps growing even if entries are overwritten.

The log covers another need: querying afterward what happened, without depending on a client being connected. For fault analysis it is complemented by oscillography; see event reports and sequence of events and how to read an oscillography.

What it means in practice

If the SCADA shows stale data after a communications outage, check which type of block each signal uses and whether the client requests general interrogation on reconnection.
If events are lost, check that the block is enabled by the right client, that another client has not reserved it and that the triggers include data change and quality change.
If traffic grows, the buffer time and the integrity period are the parameters that moderate it. A traffic storm has other causes.
When making settings changes, a change in the data set associated with a buffered block empties its buffer; plan it outside a critical operation.

For the case of an IED that does not deliver data, see IED not communicating over IEC 61850 MMS, and for the summary of the protocol, IEC 61850 MMS. How a value is replaced by a manual one (subEna, subVal) and what the quality flags is covered in Data Substitution in IEC 61850.

IEC 61850 reporting with Tiza Group

Does your SCADA lose events after each communications outage, or fail to rebuild the sequence properly? At Tiza Group we review and configure reports with our IEC 61850 engineering, at medium, high and extra-high voltage, in substations and industry, and we test link recovery in the commissioning tests. Field work is done in Colombia, or elsewhere on request, and configuration reviews can be done remotely, worldwide. Downloading fault records with GetFile is explained in File Transfer in IEC 61850.

References

IEC 61850-7-2 (edition 1, 2003): clause 14, report control block (BRCB and URCB) and log (LCB and LOG) models.
IEC 61850-8-1 (edition 1, 2004): clause 17, mapping of reports and logs to MMS.
IEC 61850-7-3 (edition 1, 2003): trigger options of data attributes (change, quality, update).

Frequently asked questions

What happens to events when the link to the SCADA goes down?

It depends on the type of block. The buffered report keeps storing events while there is no connection and, when the same client reconnects and enables it indicating the last entry identifier received, it continues from there without gaps. The unbuffered report stores nothing: whatever happened during the outage is lost, and the client must request a general interrogation to resynchronize.

Is the integrity period the same as general interrogation?

No. Both send the values of all members of the data set, but the integrity period is triggered by the server at regular intervals and the general interrogation is requested by the client when it needs it, for example at startup or on reconnection.

Why can the same event arrive with a different reason for inclusion?

Because each report indicates which trigger produced it: data change, quality change, data update, integrity or general interrogation. A change that meets two conditions, for example value and quality, is preferably sent in a single report.