Ask a historian for a tag's value at a timestamp that falls between two stored samples, and it has to decide what to return, because no sample exists at that exact instant. Last-known-value is the query mode that answers by reaching back to the most recent sample before the requested time and holding it forward. This guide explains how the last-known-value, or sample-and-hold, query mode works, why exception-based historians depend on it, and how it differs from linear interpolation when reconstructing a value between stored points.
Last-Known-Value (Historian Query) in one line: Last-known-value (LKV) is a historian query mode that returns, for any requested timestamp, the most recently stored sample at or before that time, holding it constant until the next sample arrives. It is also called sample-and-hold or stepped retrieval, and it treats each stored value as remaining true until a new one replaces it. This matches how exception-based historians store data - a value is only written when it changes - so between writes the last-known-value is the historian's best statement of what the tag was, in contrast to linear interpolation, which instead draws a sloped line between the two surrounding samples.
When a query asks for a tag's value at a specific instant, the historian rarely has a sample stored at exactly that time. Last-known-value resolves this by looking backward: it finds the newest sample whose timestamp is at or before the requested time and returns that. In effect it assumes the value has not changed since it was last recorded, so the answer at any moment is whatever the tag most recently reported. Query a temperature at 10:37 when the surrounding samples sit at 10:30 and 10:45, and last-known-value returns the 10:30 reading, because that is the last thing the tag actually said before 10:37.
This produces a reconstructed signal shaped like a staircase - flat segments that hold a value, then a vertical step up or down when a new sample arrives, then flat again. That stepped shape is not an approximation of some smoother underlying curve; it is a deliberate statement that, as far as the record is concerned, the value was constant between recorded changes. It is why last-known-value is often described as stepped or hold-last retrieval, and why a value queried anywhere within a flat segment returns the same number. The mode is also what a live display leans on to answer the simplest question of all - what is this tag right now - by returning the most recent stored sample rather than waiting for the next update.
Most process historians store data by exception, meaning they write a new sample only when the value has changed by more than a defined amount, rather than saving a reading on every scan. This keeps the archive compact, but it has a direct consequence for how stored values should be read: the gaps between samples are not missing data, they are periods during which the historian is asserting the value did not meaningfully change. Nothing was written precisely because nothing changed. Last-known-value is the retrieval mode that honors that assertion, because holding the last sample forward is exactly the assumption under which the sample was allowed to go unwritten in the first place.
This makes last-known-value the natural and often correct default for exception-stored data, and it is essential for tags whose values genuinely do stay constant between changes - discrete states, setpoints, mode selections, running or stopped statuses, and counters. For a pump-status tag that reads running, then stopped an hour later, the true value during that hour was running the whole time, and only last-known-value reconstructs that faithfully. Reading such a tag any other way would invent a transition that never occurred. Because exception-based storage and step-behaved signals are so common in industrial data, last-known-value is not an edge case but the query mode a great many tags should be read with.
The alternative to last-known-value is linear interpolation, which reconstructs a between-samples value by drawing a straight sloped line from the sample before to the sample after and reading off the requested point along it. The two modes answer the same question - what was the value at this instant - with opposite assumptions. Last-known-value assumes the value stayed put and then jumped; linear interpolation assumes it moved smoothly and continuously between the two known points. For the same query on the same stored data they can return quite different numbers, and neither is universally right - the correct choice depends on the physics of the signal.
That choice maps onto the nature of the tag. A continuous analog measurement that really does move smoothly between samples - a flowing temperature or a slowly filling level - is usually best read with interpolation, which estimates the intermediate glide. A discrete or held signal - a state, a setpoint, a counter - must be read with last-known-value, because it truly does hold flat and step. In a cloud SCADA such as Merobix, tags gathered from the field over Modbus, DNP3, OPC UA, and MQTT are stored once, and the query mode is applied when the data is read back, so the same historian can return a stepped reconstruction for a status tag and an interpolated one for an analog trend. Choosing the mode that matches each signal is what makes a reconstructed value between stored points a faithful account of what the tag was doing rather than an artifact of the query.
It means that when you ask for a tag's value at a timestamp with no stored sample, the historian returns the most recent sample at or before that time and holds it constant until the next sample. It is also called sample-and-hold or stepped retrieval. The reconstructed signal looks like a staircase of flat segments and vertical steps, reflecting the assumption that the value did not change between recorded samples.
Because they store a new sample only when the value changes by more than a set amount, so the gaps between samples are periods during which the historian is asserting the value stayed the same. Holding the last sample forward is exactly the assumption under which that sample was allowed to go unwritten. Last-known-value therefore reconstructs the stored data faithfully, which is why it is the natural default for exception-based archives.
Use last-known-value for signals that genuinely hold constant and then jump - discrete states, setpoints, running or stopped statuses, and counters - where inventing a smooth slope between samples would fabricate transitions that never happened. Use linear interpolation for continuous analog measurements that really do move smoothly between samples, such as a flowing temperature. The right mode depends on the physics of the tag, not on a single global setting.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.