A stale-data alarm fires when a tag's value has not been updated within the interval you expect it to update, flagging that the number on the screen, however valid it looks, is no longer fresh. It catches a specific and sneaky failure mode: the communications link is nominally up, the value passes range checks and looks perfectly reasonable, but the source behind it has quietly stopped refreshing it, so the operator is looking at an old reading that no longer reflects what is happening in the field. Because nothing about the value itself looks wrong, this failure hides from ordinary quality and comms checks. This page defines the stale-data alarm as a freshness check on live data, distinguishes it from a comms-fail alarm and a field-side frozen transmitter, and explains where in the data path it belongs.
Stale-data alarm in one line: A stale-data alarm fires when a tag has not updated within an expected time window, indicating the value has stopped being refreshed even though it may still look valid. It works by watching the age of the value's last update against a timeout, so a value that stops changing because its source froze is caught even when comms are nominally up. It differs from a comms-fail alarm, which detects a dropped link, and from a field-side frozen transmitter, which is a sensor fault rather than a data-freshness problem.
The failure a stale-data alarm is built to catch is one where every obvious indicator says the data is fine. The communications are connected, the tag has a value, that value is within its normal range and would pass any plausibility check, and the display shows a believable number. The only thing wrong is that the number is old: the source that should be updating it has stopped, and the value has been sitting unchanged for longer than it ever should under normal operation. An operator glancing at the screen sees a healthy-looking reading and has no reason to distrust it, which is exactly what makes this failure dangerous. Decisions get made on a value that no longer reflects reality, and nothing flags the problem because nothing about the value looks abnormal.
A stale-data alarm surfaces this by watching not the value but its freshness, the age since it last updated. Every time the value is refreshed, the clock resets; if the value goes too long without a refresh, exceeding a configured maximum age, the stale-data alarm fires. It is fundamentally a timeout on updates rather than a check on the value's magnitude. This is why it can catch a failure that range checks and comms status miss entirely: those look at whether the value is plausible and whether the link is connected, while the stale-data alarm looks at whether the value is still alive, still changing when it should be, still being renewed by whatever is supposed to renew it.
The reason a value can go stale while everything else looks healthy is that data passes through many hands on its way to the operator, and any of them can stop passing it forward while leaving the last value in place. A polling engine might stop polling one point while the connection stays open, a gateway might keep serving a cached value after its upstream source went quiet, a data source might hang in a way that stops it updating a register without dropping the link. In all these cases the last good value simply persists, frozen, with a healthy connection wrapped around it. The stale-data alarm is the check that notices the persistence and calls it out, turning a silent freeze into a visible alarm.
It is important to separate a stale-data alarm from a communications-failure alarm, because they detect different problems and firing the wrong one leads the operator to the wrong diagnosis. A comms-fail alarm detects that the link itself is down, that the poll timed out, the connection dropped, the device stopped responding. When comms fail, you usually get no new data at all and the system knows the source is unreachable. A stale-data alarm detects the opposite-looking situation: the link is up, data is nominally flowing or at least available, but one value inside that healthy connection has stopped refreshing. A stale-data alarm without a comms-fail alarm is a strong signal that the pipe is fine and the problem is specifically that the source behind one tag has gone quiet, which points the investigation somewhere very different from a dropped link.
It is equally important to distinguish a stale-data alarm from a field-side frozen transmitter, which is a sensor fault rather than a data-path problem. A frozen or stuck transmitter is a physical instrument that has stopped responding to the real process, holding its output constant because the sensor plugged, the electronics failed, or the reading locked up, even though it keeps transmitting that constant value faithfully. That is a field failure, diagnosed and fixed at the instrument. A stale-data alarm, by contrast, is about the data path in the control and monitoring system: the value is not updating because something in the software chain stopped delivering updates, not necessarily because the instrument in the field is faulty. The two can look similar on a trend, a flat unchanging line, but they live at opposite ends of the system and call for different fixes.
These distinctions matter operationally because they route the response. A comms-fail alarm sends someone to look at the link, the radio, the network. A frozen-transmitter suspicion sends a technician to the field instrument. A stale-data alarm points at the data path in between, the polling engine, the gateway, the server, the integration layer, where a value can freeze without the instrument being at fault or the link being down. Having a distinct stale-data alarm rather than lumping everything into a generic bad-quality indication is what lets the operator or engineer skip straight to the right layer, instead of chasing a field instrument that is actually reporting fine into a data path that has silently stopped moving its value forward.
Because data can freeze at several points along its journey, where you place the freshness check determines how much of the path it protects. A stale-data alarm placed close to the source catches a freeze early but sees only the segment upstream of it; one placed close to the operator, at the point where the value is actually consumed and displayed, catches a freeze anywhere along the whole chain, because it verifies that the value arriving at the point of use is fresh regardless of where along the way it stopped updating. The general principle is that freshness is most meaningful when checked where the data is trusted and acted upon, since that is where a stale value does its damage, so a check near the consuming end guards against the widest set of failure points.
The check itself depends on having a meaningful update time to age against, which is where the design of the data path matters. If each value carries a timestamp of when it was genuinely produced or last changed, the freshness check is straightforward: compare that timestamp's age to the allowed maximum. If values arrive without a trustworthy source timestamp, the monitoring system may have to infer freshness from when it last saw the value change or last received a new sample, which is weaker because a source that keeps re-sending the same value can look like it is updating even though the underlying reading is frozen. The most robust freshness monitoring is built on timestamps that reflect real production of the value, so that re-sending a stale number does not fool the age check.
This is a place where a cloud SCADA platform has a natural advantage, because it sits at the consuming end of long, multi-hop data paths from many remote sites and can watch the freshness of every incoming tag centrally. A platform such as Merobix receives values from remote gateways and field devices over links that can degrade in subtle ways, and monitoring the last-update age of each tag lets it distinguish a site whose link has dropped, which it flags as a comms failure, from a site whose link is fine but whose values have quietly stopped refreshing, which it flags as stale. Setting a sensible maximum age per tag, based on how often that value is genuinely expected to update, turns the platform into a continuous freshness monitor across the whole fleet, so a frozen value at an unmanned site raises an alarm instead of silently misleading everyone who trusts the number on the screen.
A comms-fail alarm detects that the link itself is down, so no new data is arriving and the source is unreachable. A stale-data alarm detects the opposite-looking case where the link is up and data is nominally available, but one value has stopped refreshing inside that healthy connection. So a stale-data alarm firing without a comms-fail alarm tells you the pipe is fine and the specific source behind that tag has gone quiet, which points the investigation somewhere very different.
No. A frozen or stuck transmitter is a field instrument fault, where the physical sensor has stopped responding to the process but keeps transmitting a constant value, and it is fixed at the instrument. A stale-data alarm is about the data path in the software chain, where a value stops updating because a polling engine, gateway, or server stopped delivering updates, not necessarily because the instrument is faulty. They can look identical as a flat line but live at opposite ends of the system and need different fixes.
Freshness is most meaningful checked where the value is actually trusted and acted upon, typically near the consuming end such as the SCADA or cloud platform that displays and uses the data, because a check there catches a freeze anywhere along the whole chain. It works best when values carry a timestamp reflecting when they were genuinely produced, so the age check compares against real update time rather than being fooled by a source that keeps re-sending the same stale number.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.