Values Frozen at Last-Good Across a Site: Diagnose
Every tag from a site is showing a plausible number, but none of them is changing - they are all holding whatever value they last reported. This is the quietly dangerous version of a site outage, because the screen looks populated and normal until you notice nothing moves. This page is a symptom-first tree for a whole-site last-good freeze: why the feed stopped while the last frame stayed on screen, how to tell it from a genuinely steady site, and how the quality flag and timeout behavior expose it.
Values Frozen at Last-Good in one line: When a whole site's values are frozen at last-good, the feed stopped delivering new values while the system held the last ones it received. This is a communication or poll loss showing its held frame, not a set of steady processes. The tell is that every tag stopped changing at the same instant and, after the configured timeout, the quality goes stale. Check the stop timestamp and the quality flag, then work it as a whole-site comms loss.
First Checks: Confirm It Is a Freeze, Not Steadiness
The first job is to prove the site is actually frozen and not just quiet, because a plausible unchanging number is exactly what a stopped feed and a calm process both look like at a glance. Check whether every tag stopped at the same instant: a whole site freezing together at one timestamp is a feed loss, since independent processes do not all go perfectly still in unison. If different tags last changed at different natural times and are simply slow-moving, the site may be genuinely steady. The synchronized stop is the signature of a held frame rather than a calm plant.
Read the quality flag and how long the values have been held. Many systems hold the last-received value and keep it Good for a grace period, then transition it to stale, last-known-value, or bad once a timeout elapses without a fresh update. If the site's tags have gone stale, the system is telling you plainly that the feed stopped and it is showing you old numbers. If they are still Good but frozen, you may be inside the grace period before the timeout fires, and the stale flag is about to appear. Understanding the last-known-value hold behavior explains why plausible numbers can persist on screen after the feed dies.
Verify against the historian, which records independently of the display. If the historian also went flat at the same instant, the collection stopped and this is a real feed loss. If the historian is still recording changing values while the display is frozen, the collection is healthy and only the client session froze, which is a different and milder problem confined to the display. This single comparison - live view versus recorded history - separates a genuine site-wide feed loss from a frozen client, and it is the fastest way to know whether the field is actually unreachable.
Why the Frame Stays While the Feed Stops
Understanding why a frozen frame appears at all is what keeps you from being fooled by it. When a poll stops getting answers, the SCADA does not usually blank the tags immediately; it holds the last values it successfully read, because a brief gap should not wipe the screen. Those held values are real numbers from the last good poll, so they look entirely plausible - a level that was 60 percent stays at 60 percent, a pressure that was normal stays normal. The display is faithfully showing the last frame it received, which is the correct behavior but is easy to mistake for a live feed if you do not notice the timestamps have stopped advancing.
The freeze becomes a bad-quality event once the timeout fires. A well-configured system marks the held values stale or bad after a defined interval without an update, converting a silent frozen frame into an explicit quality flag that operators, alarms, and reports can see and respond to. This is why the quality flag matters so much for this symptom: it is the mechanism that turns a deceptively normal-looking frozen site into a visible fault. A site whose tags have all gone stale together is a site whose feed has been confirmed stopped for longer than the grace period, and that is a whole-site comms loss to be worked as such.
From here the diagnosis rejoins the broader comms-loss tree, because a whole-site last-good freeze is one presentation of a site that stopped reporting. The question becomes the familiar three-way fork of power, comms, or device: did the site lose supply, its link, or its controller. The frozen-frame symptom simply tells you that the loss was a clean stop of the feed rather than, say, an explicit device fault response, which slightly favors a poll or link interruption over a controller that would more often return errors. Reading the freeze as an entry point into the dark-site triage keeps the diagnosis systematic rather than mesmerized by the plausible frozen numbers.
Verifying the Diagnosis and Restoring the Feed
Verify that the feed is truly stopped by attempting to reach the site independently of the frozen display - ping the gateway, check the poll engine's status for that site, or look at whether the device answers a direct read. A site that does not respond confirms the freeze is a real feed loss and moves you to restore the link or the device. A site that does respond while the display stays frozen redirects you to the client session, because the field is fine and only the view is stuck. The verification is aimed at distinguishing a dead feed from a dead display, which are fixed in completely different places.
Restore the feed by working whichever layer the dark-site triage convicts, and confirm success by watching the frozen tags start moving again and their quality return to Good. When the poll resumes or the link recovers, the held frame comes alive: values that were pinned begin to change, timestamps advance, and stale flags clear. If the process moved while the site was frozen, be aware the recorded history has a gap that may need backfilling, and check whether the system reconstructed it. A restored feed is proven by motion returning, not merely by the site answering a ping.
In a cloud SCADA such as Merobix, a whole-site last-good freeze is unmasked quickly because every value carries a timestamp and a quality flag, so an engineer sees that the site's tags all stopped advancing at one instant and went stale together rather than being lulled by their plausible numbers. Comparing the frozen view against the independently recorded history separates a dead feed from a frozen client in one look. The platform makes the freeze visible as a timed, flagged event instead of a silently stale screen, which is what keeps a frozen frame from being trusted as live data.
When to Escalate
Escalate as a whole-site comms loss once the freeze is confirmed to be a real feed stop - synchronized stop, stale quality, and no response to a direct reach. From there it is the dark-site dispatch decision: convict power, comms, or device, and send the matching response. Do not escalate a frozen client, where the historian kept recording, to the field at all, because the field is healthy and only the display session needs reconnecting.
Escalate with the stop timestamp, the current quality state, and the historian comparison, because those three facts prove the freeze is a feed loss rather than a calm process or a stuck display, and they tell the responder how long the site has actually been dark. A frozen site that still shows plausible numbers is the easiest outage to underestimate, so passing along the evidence that the feed genuinely stopped is what ensures it is treated with the urgency a dark site deserves.
Frequently Asked Questions
Why are all my site's values frozen at plausible numbers that never change?
Because the feed stopped delivering new values and the system is holding the last frame it received. When a poll loses its answers, the SCADA holds the last successfully read values rather than blanking the screen, so they stay plausible - a normal pressure stays normal - even though nothing is updating. The tell is that every tag stopped changing at the same instant and, after the configured timeout, the quality goes stale or bad. Confirm against the historian: if it also went flat, the feed truly stopped and this is a whole-site comms loss.
How is a frozen site different from a site that's just steady?
A genuinely steady site shows tiny natural movement and fresh, advancing timestamps on its tags, while a frozen site shows perfectly unchanging values whose timestamps stopped advancing at one common instant. Independent processes do not all go perfectly still in unison, so a synchronized stop across every tag is a held frame, not a calm plant. The quality flag settles it: a steady site keeps Good, advancing data, while a frozen site's tags go stale together once the timeout fires. Comparing against the independently recorded historian is the fastest confirmation.
The values are frozen but still read Good quality. Is the site fine?
Not necessarily - you may be inside the grace period before the timeout fires. Many systems hold the last value and keep it Good for a defined interval, then mark it stale or bad once too long passes without an update, so a freshly frozen site can still show Good while it is actually dark. Check whether the timestamps are advancing: frozen timestamps with Good quality means the stale flag is about to appear. Verify by reaching the site directly; if it does not respond, the feed has stopped regardless of the current quality flag.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.