The compression deviation limit is the single setting that decides how much a tag's value must move before the historian stores a new point, and getting it right per tag is what separates a lean, faithful archive from one that is either bloated with noise or quietly hiding real changes. Tuning it well is not guesswork; it follows from the instrument's noise, the fidelity the trend needs, and a check against real data. This page lays out a practical, repeatable workflow for setting the deviation limit on flow, pressure, and temperature tags, starting from what the instrument actually does and ending with a validated result you can trust.
Compression deviation limit tuning in one line: To tune a compression deviation limit, start from the instrument's noise band so ordinary jitter does not force stores, set the limit as a percent of the tag's span sized to the trend fidelity you need, then test it against captured raw data and check the reconstruction error before committing. The limit should sit above the noise but tight enough that real process changes are still recorded. Tuning is done per tag because flow, pressure, and temperature signals behave differently.
There are two failure modes, and each has a recognizable signature. A limit set too tight, below or into the instrument's noise, shows up as under-compression: the tag stores far more points than it should, its compression ratio collapses toward zero, and the archive fills with what is essentially captured jitter rather than real process movement. On a trend, an under-compressed tag looks busy and fuzzy, and it consumes a disproportionate share of storage for a signal that is not actually doing much. A single noisy tag with a too-tight limit can quietly become one of the largest consumers in a historian.
A limit set too wide produces the opposite and more insidious symptom: over-compression. The tag stores almost nothing, its compression ratio pins near total, and the trend looks unnaturally smooth because genuine excursions have been swallowed by the oversized deviation band. This is the dangerous case, because it fails silently. The archive is small and the trend is tidy, but a pressure spike or a flow dip that a person needed to see has been compressed out and cannot be recovered later. A tag that ought to show normal process variation but reads as a nearly flat line between distant points is the classic warning sign.
The goal of tuning is to land between these two failures: a limit high enough that ordinary instrument noise is filtered away, so the tag is not storing jitter, but low enough that any change the process genuinely makes, and that anyone might need to see later, is still captured faithfully. Recognizing which failure a tag is exhibiting is the starting point, because it tells you which direction to move the limit and how far, rather than adjusting blindly.
Begin with the instrument's noise band, because the deviation limit must sit above it. Look at the raw signal when the process is steady and observe how much the value jitters purely from measurement noise, not real change. The deviation limit should be set comfortably above that noise amplitude, so that ordinary jitter never crosses it and forces a store, but not so far above it that real movement is masked. Setting the limit at or below the noise band is the direct cause of under-compression, so this first step, understanding what the instrument does when nothing is happening, anchors everything that follows.
Next, express the limit in a way that scales sensibly, which usually means a percent of the tag's span rather than a raw engineering value. A limit stated as a small percentage of the calibrated range travels well across similar instruments and makes the setting easy to reason about, because a pressure transmitter and a flow meter can be given comparable relative tolerances even though their absolute values differ wildly. From that percent-of-span starting point, adjust for how much trend fidelity the tag genuinely needs: a fiscal or safety-relevant measurement demands a tighter limit so fine detail survives, while a slow, non-critical utility signal can tolerate a wider band. This is where tag-by-tag judgement matters, because flow, pressure, and temperature signals differ in noise character and in how much detail their trends must preserve.
Then test the candidate limit against captured raw data rather than trusting the number in the abstract. Take a period of high-resolution raw values for the tag, apply the proposed deviation limit to it, and see both how many points would have been stored and how the reconstructed trend compares to the raw. This closes the loop before the setting ever touches production: you can see directly whether the limit filters noise without erasing real events, and iterate if it does not. Repeating this for representative tags of each type builds a set of sensible defaults you can apply confidently to the rest.
The final check is reconstruction error: the largest gap between the line the historian would draw between stored points and the actual raw signal it was meant to represent. A well-tuned limit produces a reconstruction that stays within an acceptable band of the raw data everywhere, meaning the compressed trend never misleads a reader by more than a tolerable amount. If replaying the raw data through the candidate limit shows the reconstruction departing from reality by more than the tag can afford, the limit is too wide and must be tightened, regardless of how attractive the storage savings looked. Validating against reconstruction error is what turns tuning from an educated guess into a defensible setting.
Tuning is not a one-time act, because instruments drift, processes change, and a limit that was right at commissioning can become wrong over time. A tag that develops more noise, perhaps from a failing sensor, will start under-compressing, while a process that becomes more dynamic may find its once-adequate limit now too wide to capture the new behaviour. Periodically revisiting deviation limits, driven by the compression ratio as a triage signal, keeps the archive faithful as conditions evolve rather than letting settings ossify at whatever was chosen years earlier.
Across a large SCADA estate with many field sites, tuning deviation limits one tag at a time by hand does not scale, so the practical approach is to establish good percent-of-span defaults per instrument type, validate them on representative tags, and then watch for the outliers that need individual attention. A cloud monitoring platform such as Merobix helps here by surfacing which tags have drifted into under- or over-compression, so tuning effort concentrates on the handful of tags actually misbehaving rather than on the whole fleet. Combining sensible defaults, per-tag validation against raw data, and ongoing monitoring of the ratio keeps a historian both compact and trustworthy without demanding constant manual attention to every point.
No. Setting the limit at or below the instrument's noise band causes under-compression, because ordinary jitter constantly crosses the limit and forces a store on nearly every scan, filling the archive with captured noise rather than real movement. The limit should sit comfortably above the observed noise amplitude so steady-state jitter never triggers a store, while still being tight enough that genuine process changes are recorded.
Stating the limit as a small percentage of the tag's calibrated range makes it easy to reason about and lets you apply comparable relative tolerances across different instruments, even when their absolute values differ widely. From that percent-of-span starting point you adjust for the fidelity each tag needs, tightening it for fiscal or safety-relevant measurements and relaxing it for slow, non-critical signals. It gives a consistent basis for tuning many tags.
Validate it against reconstruction error by replaying captured raw data through the candidate limit and comparing the reconstructed trend to the actual signal. If the reconstruction stays within an acceptable band of the raw data everywhere, the limit is safe; if it departs from reality by more than the tag can afford, the limit is too wide and must be tightened. This check catches over-compression before the setting ever affects production data.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.