Some bad readings are obvious because they land outside the possible range of a sensor, but the sneakiest ones sit comfortably inside the range and are wrong only because they arrived too suddenly. A rate-of-change limit check is a data-validation rule that watches how fast a value moves between scans and treats an impossibly fast jump as suspect, even when the number itself looks plausible. This guide explains the check as a quality gate rather than a calculation, how to set a realistic slew limit, and how it catches the noise spikes and communication glitches that a simple range check waves through.
Rate-of-Change Limit Check in one line: A rate-of-change limit check is a validation rule that flags a reading as suspect when it changes faster than the process could physically move, for example a tank level jumping fifty percent in a single scan. It compares the change between successive samples against a configured maximum slew rate, and if the jump exceeds that limit the value is treated as questionable or rejected rather than trusted, catching spikes and glitches that a static high and low range check would let through.
It is worth separating two ideas that share the words rate of change. One is a calculation that derives a genuine rate, a per-minute or per-hour trend, from a slowly changing process variable so that operators can act on how fast something is moving. The other, the subject here, is a validation rule whose only job is to judge whether the latest sample can be believed. The first produces a new number that people watch; the second produces a verdict, good or suspect, about an existing number. They can look similar because both subtract one sample from the previous one, but their purpose is different, and a system can run both at once on the same tag.
As a quality gate, the check works alongside the ordinary high and low range limits rather than replacing them. A range check asks whether the value is inside the sensor's possible band. A rate-of-change limit check asks whether the value got to where it is at a believable speed. The two catch different faults. A value can be perfectly in range yet arrive by an impossible leap, and a value can drift slowly out of range without ever tripping the rate check. Running both closes the gap between them, so a reading has to be both plausible in magnitude and plausible in motion before it is trusted.
The output of the check is usually a flag rather than a hard rejection. A value that fails the rate test can be marked questionable or uncertain and passed downstream with that warning attached, or it can be held back and replaced with the last good value until the reading settles. Which behavior is correct depends on the tag: for a control input a suspect spike is best suppressed, while for an archived measurement it may be better to keep the raw sample but stamp it so an analyst knows not to trust that point.
The heart of the check is the slew limit, the maximum change the tag is allowed to make in a given interval before the sample is judged impossible. Setting it well means knowing the physics of the point. A large storage tank cannot fill or empty by half its height in a few seconds no matter what the sensor reports, so a level tag can carry a tight rate limit. A downstream pressure at a compressor, by contrast, really can swing hard and fast during a trip, so its rate limit has to be loose enough to allow real transients through. A limit set too tight will reject legitimate fast movement and hide real events; a limit set too loose will pass the very spikes it was meant to catch.
The interval matters as much as the magnitude. A rate limit only means something relative to how often the tag is sampled, so the limit is naturally expressed as a maximum change per scan or per second and scaled to the scan class of the point. If the polling rate changes, the allowed per-scan change has to be revisited, because a slower scan gives the process more time to move legitimately between samples and a fixed per-scan delta would suddenly start rejecting normal behavior. Tying the limit to a rate per unit time rather than a raw per-sample delta makes it robust to changes in how often the point is read.
A good starting point is to base the limit on the fastest genuine transient the point can experience and then add margin, rather than on the average behavior. The goal is to draw the line just above what the real process can do, so that anything faster is by definition not the process. Where the fastest real transient is hard to characterize, historical trend data for the tag shows the largest sample-to-sample steps that actually occurred during real events, and the limit can be set a little above the biggest of those. Reviewing the limit after commissioning, once the point has seen real operating conditions, keeps it honest.
In field operations the faults this check is best at catching are the brief, violent ones that never reflect the process at all. Electrical noise coupled onto a signal cable, a loose terminal, a momentary transmitter fault, or a corrupted register read can all produce a single sample that leaps to some in-range but wildly wrong value and then snaps back on the next scan. A range check sees nothing because the spike was inside the band. A rate-of-change limit check sees it immediately, because nothing real moves that far that fast, and it can suppress the spike before it reaches a trend, an alarm, or a control loop.
Communication glitches produce a related signature. A stale or garbled read, a gateway that returns a default value for a moment, or a protocol hiccup can inject a value that is disconnected from the previous good reading. Because the check reasons about the jump between successive samples, it catches the discontinuity these glitches create even when the injected value happens to be a legal number. Pairing the rate check with a staleness and communication-status check gives a fuller picture: one flags a value that changed impossibly, the other flags a value that stopped changing at all.
For a cloud SCADA platform such as Merobix, where field data travels over cellular or satellite links from remote sites before it lands in the hosted system, rate-of-change validation is especially valuable because the path from sensor to database has more places to introduce a transient error. Applying the check as data arrives means a spike caused by a noisy remote signal or a flaky backhaul link is flagged questionable in the cloud rather than silently poisoning a trend that an engineer reads days later. Because the platform holds the history for every tag centrally, the same trend data used to review and tune each tag's slew limit is available without visiting the site, so the limits can be refined over time from real behavior across the whole fleet.
A rate-of-change calculation derives a genuine trend, such as a pressure rise per minute, that operators watch and alarm on. A rate-of-change limit check is a validation rule that judges whether the latest sample can be believed by comparing its jump against a maximum slew rate. The calculation produces a new number to act on; the check produces a good-or-suspect verdict about an existing number.
Base it on the fastest genuine transient the point can physically experience and set the limit just above that, then add margin. Express the limit as a change per unit time rather than a raw per-sample delta so it survives changes in polling rate. Where the real maximum is unclear, historical trend data shows the largest legitimate sample-to-sample steps, and reviewing the limit after the point has seen real operating conditions keeps it accurate.
It is usually flagged rather than deleted. The system can mark the sample questionable or uncertain and pass it downstream with that warning, or hold it back and substitute the last good value until the reading settles. For a control input, suppressing the suspect spike is safest; for an archived measurement, keeping the raw point but stamping it lets an analyst see and ignore the bad sample later.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.