IEC 61850 Log Control Blocks: LCB and LOG Explained

Reporting pushes data to a client. Logging stores it in the IED and waits for someone to ask.

That difference sounds small and isn't. A report control block needs a client — no association, no reports, and with an unbuffered block, no record that anything happened. A log control block records regardless. The IED writes to its internal LOG whether or not anyone is connected, whether or not the station bus is up, whether or not the SCADA system exists yet. Retrieval is a completely separate activity that happens later, on the client's schedule.

This article is part of the broader IEC-61850 series. If you're new to this protocol family, start with What Is IEC 61850? The Language of Power System Functions.

This guide covers the LCB and the LOG it writes to: what each attribute does, how entries are identified and queried, and where logging is the right answer instead of reporting.

Why logging exists as a separate model

The standard is unusually explicit about the requirements that forced a separate model, and each one explains a design decision:

Logging is independent of associations. Even if communication is lost, events still occur and still get logged. This is the whole point.

Storing and retrieving are asynchronous. The IED writes at its own pace; the client reads at its own pace. Neither waits for the other.

Records can be generated faster than communications can carry them. A busy IED during a fault can produce entries faster than any client could consume reports. The log absorbs that.

Clients retrieve subsets, not everything. A client maintaining its own historical database asks for what it's missing, not the whole log.

The source may be external. An IED can act as a central store for values it didn't produce.

Records need ordering. Entries carry sequence identity, not just timestamps.

Two application categories drive all of this: periodic recordings — what metering people call profiles — and event-triggered sequence-of-events data. If you've built SOE infrastructure on buffered reporting alone, the log model is the mechanism you were probably working around.

LOG and LCB: storage and the thing that fills it

The split matters. A LOG is the storage. An LCB is a control block that watches a data set and writes entries into a LOG when triggers fire.

They're not one to one. One LOG can be written by multiple LCBs, each feeding it from a different data set. That's how an IED maintains a single consolidated event log while separate control blocks monitor status points, measurements, and protection signals with different trigger settings and different integrity periods.

An LCB lives inside a logical node and its name must be unique within that scope. The LOG it targets is named by the LCB's LogRef attribute — and it can be a log in another logical device entirely.

The LCB attributes

Fewer than a report control block, and every one earns its place.

Two behaviors to know before you touch one.

Nothing is configurable while enabled. While an LCB is in the enabled state, no attribute change other than disabling is allowed. Same discipline as report control blocks: disable, configure, re-enable — but with a shorter attribute list to get wrong.

LogEna may come up TRUE by itself. A server is permitted to set LogEna TRUE automatically at startup. So a log can be filling before any client has ever connected, which is exactly the behavior you want and occasionally a surprise when you find entries predating commissioning.

TrgOps: four triggers, not five

The LCB uses the same trigger conditions as reporting — data-change, quality-change, data-update, integrity — with one firm exception: general-interrogation is not supported for logging. The standard states it directly, and the LOG class reinforces it: a general-interrogation reason code shall never appear as TRUE in a log entry.

That makes sense once you think about what GI is for. General interrogation exists so a client can refresh its own picture on demand. A log has no picture to refresh — it records what happened, and "a client asked" is not something that happened to the power system.

OptFlds: one bit

Reporting has eight optional fields. Logging has one: reason-for-inclusion. Set it TRUE and each entry stores the ReasonCode that caused it; leave it FALSE and you store values without causality. An LCB that doesn't support the option rejects the attempt with a negative response.

Enable it. The storage cost is trivial and the analytical value is high — knowing whether an entry exists because the value changed, the quality changed, or an integrity scan fired is often the difference between a readable event log and a list of numbers.

Inside the LOG

The LOG class carries four status attributes and the entries themselves:

Those four are what GetLogStatusValues returns, and they're the first thing a retrieving client should read: they tell you the window of history the IED currently holds, so you know whether the data you're missing still exists before you go looking for it.

Each entry contains a TimeOfEntry, an EntryID, and one or more EntryData items — each a DataRef, a Value, and optionally the ReasonCode.

Circular storage, linear view

Here's the design detail worth internalizing. Implementation-side, the LOG is a circular buffer that overwrites the oldest values. Client-side, it looks linear. That illusion is maintained by how entries are identified:

EntryID is a counter that rolls over at its maximum — but the standard requires the counter to be larger than the maximum number of entries the LOG can hold, so no two entries in a log ever share an EntryID.

TimeOfEntry is when the entry was added.

Together they uniquely identify an entry, and a client can query by either. The practical consequence: a client tracking its position by EntryID can always resume cleanly, and if the log has wrapped past that point, the status attributes tell you so rather than silently handing back wrong data.

Retrieving: three services

Clients read logs with three services, and choosing the right one is most of the work.

GetLogStatusValues returns the four status attributes. Cheap, and the correct first call in any retrieval cycle — it tells you the available range before you request anything.

QueryLogByTime retrieves entries within a time range. Use it for time-anchored investigations: everything around a fault at a known instant.

QueryLogAfter retrieves entries following a given point, identified by EntryID and TimeOfEntry together. This is the one for continuous collection: a historian stores the last EntryID it processed and asks for whatever came after, cycle after cycle, with no gaps and no duplicates.

Note what's missing from that list: there is no delete, no purge, no client-side log management at all. Ageing is the IED's business.

Logging or reporting?

They're not competitors — most substations run both — but the choice per data set has a clear logic.

Use reporting when a client needs to know promptly: SCADA displays, alarm handling, anything driving an operator decision or an automatic response. Buffered reporting covers short connection losses well.

Use logging when the record matters more than the latency: sequence-of-events for post-fault analysis, metering profiles, long-term histories, anything that must survive an extended outage of the client system. Logs also handle burst rates that would overwhelm a reporting path.

Use both on the same data when the record is important and prompt notification is too — one report control block and one log control block, both pointed at the same data set. That's a normal configuration, not a redundant one.

A practical way to decide: ask what happens if the client is down for a day. If the answer is "we lose data we needed," you want a log. If the answer is "we catch up on the current state," reporting is enough.

Field notes

Log entries exist that predate your client. LogEna can come up TRUE at startup. Read the status values before assuming your retrieval covers everything.

A wrapped log looks like missing history. OldEntr and OldEntrTm tell you where the record actually begins. If your last processed EntryID is older than OldEntr, the gap is real and permanent.

Reconfiguring means disabling. No LCB attribute can be changed while enabled — check LogEna before wondering why a SetLCBValues failed.

One log, several feeders. If entries are appearing that your LCB shouldn't produce, another LCB is writing to the same LOG. Check LogRef on all of them.

No general interrogation. If a client expects to trigger a log entry with a GI, it will wait forever. Logs record events, not requests.

Capacity is a local matter. How many entries a LOG holds and how it ages them aren't specified by the standard. Read the IED documentation, then verify by watching OldEntrTm move under realistic load.

FAQ

What's the difference between a log and a buffered report? A buffered report control block queues reports for one client and delivers them when that client returns. A log stores entries in the IED independently of any client, and any authorized client can query them afterward. Buffering serves delivery; logging serves history.

Can several clients read the same log? Yes. Unlike report control blocks, which are owned exclusively by one client at a time, the LOG is queried through services and multiple clients can retrieve from it. The LCB that writes it is protected by access control.

Can one LCB write to several logs? No — an LCB names exactly one LOG in LogRef. The other direction works: several LCBs can feed one LOG.

How does a client avoid duplicates when polling a log? Track the last EntryID and TimeOfEntry processed, then use QueryLogAfter with that pair. Entries are uniquely identified, so retrieval resumes exactly where it stopped.

Why doesn't general interrogation work with logging? Because it isn't an event. GI exists to refresh a client's current picture on demand; a log records what occurred. The standard excludes GI from log trigger options and forbids the GI reason code from appearing in entries.

Can I delete entries from a log? Not through the standard's log services. There is no purge equivalent to the BRCB's PurgeBuf. Logs age by overwriting the oldest entries when full.

Are logs defined in SCL? The LCB and its LOG are part of the IED's configuration like any other control block, so yes — they appear in the IED's configuration files, and log capacity is an implementation characteristic of the device.