What Is Last Observation Carried Forward (LOCF)?

How LOCF Fills a Gap

LOCF works on one principle: the best available estimate of a missing value is the last value you actually observed. When a query walks along a time axis and reaches a timestamp with no stored sample, it does not leave a blank and it does not guess a trend - it simply reuses the previous known value. It keeps reusing that same value for every empty slot until a new real sample arrives, at which point the fill jumps to the new value and the process repeats. The result on a trend is a flat line that holds level and then steps, the same staircase shape you get from step interpolation, which is why the two are often confused. The distinction is intent: interpolation fills between two points you already have, whereas LOCF is a fill rule you apply forward when the next point may be missing, late, or not coming at all.

This makes LOCF the obvious partner for data that is naturally sparse because it only changes occasionally. Report-by-exception telemetry, where a device transmits only when a value moves past a deadband, deliberately leaves long stretches with no new sample precisely because nothing changed. Carrying the last value forward across those stretches reconstructs exactly what the device meant: the value stayed where it was. The same is true for setpoints, operating modes, batch identifiers, and equipment states, all of which hold a fixed value until something deliberately changes them.

LOCF is also the workhorse behind aligning sparse series onto a common grid. If you need a value for every tag at each five-minute mark but the tags updated at different, irregular times, forward-filling each one gives every grid slot a defined, most-recent value to work with. That is often the only sensible way to line up tags that were never sampled together, and it is why LOCF shows up whenever irregular data has to be made regular before a calculation.

When Carrying Forward Masks a Stalled Sensor

The danger of LOCF is precisely its strength turned against you: it makes a missing value look like a held value, and for a live measurement those are not the same thing. Imagine an analog level transmitter that freezes - its signal path fails but the last number it sent was 4.2 metres. If the historian applies LOCF, the trend shows a perfectly flat 4.2 metres for hours, indistinguishable from a tank that genuinely sat still. An operator glancing at the screen sees a calm, steady level; a report averaging the tag sees a stable process. Nothing signals that the instrument stopped reporting, so a real fault hides behind a plausible flat line, and decisions get made on a number that has been dead since the failure began.

This is why LOCF should almost never be applied blindly to fast-moving analog process variables, and why it should always be bounded. A safe implementation carries a value forward only for a limited staleness window - if no fresh sample has arrived within some maximum age, the fill stops and the data is marked stale, gone bad, or explicitly null rather than being extended forever. Pairing carry-forward with the sample's quality or timestamp lets a downstream reader tell a real held value from a stale one, so an alarm or a report can react to a sensor that has gone quiet instead of trusting the ghost of its last reading.

The rule of thumb is to match the fill to the tag's nature and to bound it by age. Discrete states, setpoints, and genuinely exception-based tags are good candidates for LOCF because holding is what they actually do, though even these benefit from a staleness cap that catches a device that has gone entirely silent. Continuously varying analog signals are poor candidates, because their whole point is that they move, so a long flat fill is far more likely to be a fault than a fact. When in doubt, prefer an explicit gap over an invented hold, because a visible hole prompts investigation while a carried-forward value invites false confidence.

LOCF in SCADA Historians and Remote Field Data

LOCF is woven into how SCADA historians present remote field data, because that data is sparse and interrupted by design and by circumstance. Bandwidth-conscious sites send report-by-exception updates, cellular and radio links drop and recover, and remote instruments occasionally stall, so a historian is constantly reconstructing values for timestamps where no fresh sample exists. Carry-forward is the default that keeps a wellpad or station trend continuous and keeps grid-aligned calculations fed, but on a distributed network of unattended sites it is also exactly where a quietly failed sensor can hide for the longest.

A cloud SCADA platform such as Merobix has to walk both sides of this line: fill gaps so operators and reports get continuous, usable data, without letting a carried-forward value disguise a site that has gone silent. The practical answer is to keep the fill honest by keeping the metadata with it - the age of the last real sample and its quality - so a value being held forward can be distinguished from a value that was freshly measured. That lets a held setpoint read as intended while a level transmitter that has not reported in hours surfaces as stale rather than as a comfortable flat line, and it lets a communications-loss condition be alarmed instead of masked.

For field operations spread across many remote sites, this bounded carry-forward is what makes centralized monitoring trustworthy. An operator watching dozens of unattended locations cannot personally verify that every flat trend represents a real steady state, so the platform has to do it for them by capping how long any value is carried and by flagging staleness. Done well, LOCF gives a clean continuous view of a fleet without ever letting a dead sensor pretend it is alive, which is the whole reason to be careful about a rule that otherwise looks like nothing more than repeating the last number.

Frequently Asked Questions