Not every number a sensor sends is real. A wiring fault, a failing transmitter, or a scaling glitch can produce a value that is physically impossible, and if that value flows unchecked into trends, alarms, and totals, it corrupts everything downstream. A reasonability range check is the guard that catches such values: it bounds an incoming reading against what the sensor can plausibly produce and either clamps it or flags it as bad. This guide explains reasonability checking, how over-range and under-range readings are handled, the choice between clamping and marking bad, and where this validation belongs in a data pipeline.
Reasonability Range Check in one line: A reasonability range check, also called a plausibility check, compares an incoming value against the physical range the sensor can actually produce and treats anything outside that range as suspect. Instead of passing a physically impossible reading straight through, the system either clamps it to the range boundary or flags it as bad, preventing a spurious value from poisoning trends, alarms, and totalizers.
Every sensor has a physical range it can meaningfully report. A pressure transmitter spans from its low limit to its full-scale rating; a temperature element covers a defined band; a level instrument reads between an empty and a full condition. A reasonability check encodes that knowledge as a lower and upper bound and asks a simple question of each incoming value: could this reading actually have come from this sensor. A value comfortably inside the range is accepted; a value beyond either bound is, by definition, not something the healthy sensor should produce.
The point is to distinguish a real measurement from an artifact. A pressure reading of a plausible in-range value is treated as data; a reading far above the transmitter's full scale, or below its physical minimum, is treated as a symptom of a problem rather than as a pressure. Because the check is grounded in the sensor's actual capabilities rather than an arbitrary threshold, it catches exactly the class of values that cannot be trusted, without second-guessing readings that are merely surprising but possible.
It helps to separate reasonability from process alarms. An alarm limit asks whether a genuine value has crossed an operational threshold, such as a real pressure climbing too high. A reasonability check asks something more basic, whether the value is a believable reading at all. The two work together but answer different questions: reasonability filters out data that should never be believed, so that the alarms downstream act only on values that are at least real.
Out-of-range readings come in two directions. An over-range value sits above the sensor's upper bound, and an under-range value falls below the lower bound. The two often carry different meanings. An under-range reading, especially one that drops below where a live 4-to-20 mA signal should ever sit, frequently signals a broken wire or a dead transmitter rather than a genuine low measurement, which is one reason the live signal range deliberately leaves room below its minimum. Distinguishing the direction of the excursion can therefore hint at the underlying fault.
Once a value is judged out of range, there are two broad responses, and the right one depends on how the value is used. Clamping replaces the out-of-range reading with the nearest boundary value, so an over-range input is held at the upper limit and an under-range input at the lower. This keeps a value in a sensible range for a control calculation or a display that would misbehave on a wild number. The risk is that clamping hides the problem: the trend shows a flat line pinned at the limit rather than an obviously bad reading, so the fault can go unnoticed.
Marking the value as bad takes the opposite stance. Rather than substituting a number, the system tags the reading with a bad-quality status so downstream consumers know not to trust it, and a trend can show a gap instead of a fabricated value. This preserves the truth that the measurement is currently unreliable, which matters for anything that must not act on garbage. Many systems combine the approaches, clamping for a control path that needs a number while flagging quality so operators and historians still see that something is wrong. The choice is ultimately about whether the consumer of the value needs a usable substitute or needs to know the value is not to be believed.
Reasonability checking works best applied early, close to where the value enters the system, so a bad reading is caught before it spreads. A value that is validated at ingestion never contaminates the trends, alarms, and totals that draw from it, whereas a spurious value that slips in has to be chased through every calculation it touched. Placing the check upstream is the difference between quarantining one bad reading and cleaning up after it in a dozen places, which is why validation belongs near the front of the pipeline rather than bolted on at the end.
In a cloud SCADA such as Merobix, values from field devices across oil and gas, water, power, and manufacturing arrive continuously, and a plausibility gate at ingestion protects the shared historian and the dashboards built on it. A single out-of-range spike from a failing transmitter, left unchecked, can skew a trend's scale, trip a spurious alarm, or throw off a running total, and one bad total can ripple into a report. Bounding each value against its sensor's range, and marking or clamping the exceptions, keeps those downstream artifacts honest.
The particular danger reasonability checks address is contamination of aggregates. A totalizer or an average has no memory that one of its inputs was nonsense; it simply incorporates the bad number and produces a wrong result that looks as authoritative as a right one. This is acute in measurement and accounting, where a single impossible reading folded into a volume total becomes a wrong number on a report. Catching implausible values before they reach any accumulator is what keeps totals, trends, and alarms trustworthy, and it turns an entire category of silent data-quality problems into flagged exceptions an operator can see and act on.
A reasonability check asks whether a value is a believable reading at all, by comparing it to the sensor's physical range, while an alarm asks whether a genuine value has crossed an operational threshold. Reasonability filters out data that should never be trusted, such as a reading far beyond a transmitter's full scale, so that alarms act only on values that are at least real. They work together but answer different questions.
It depends on how the value is used. Clamping replaces the reading with the nearest boundary so a control calculation or display still has a usable number, but it can hide the fault behind a flat pinned line. Flagging as bad marks the value's quality so consumers know not to trust it and a trend can show a gap. Many systems do both, clamping where a number is needed while flagging quality so the problem stays visible.
As early in the data pipeline as practical, close to where the value enters the system, so a bad reading is caught before it flows into trends, alarms, and totals. Validating at ingestion quarantines a spurious value at the source rather than forcing you to chase it through every calculation it touched. This is especially important upstream of any accumulator, since a totalizer will silently fold a bad reading into a wrong result.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.