Automation Glossary • Exception vs Compression Deadband

Exception vs Compression Deadband

Merobix Engineering • • 5 min read

A historian filters data twice, not once, and the two filters use deadbands that sound alike but do different jobs. The exception deadband decides what a collector even bothers to pass along; the compression deadband decides what the archive keeps for good. Confusing the two leads to endless trouble, because tightening the wrong one either starves the archive of data or fails to shrink it at all. This page pulls the two stages apart.

Back to Blog

Exception vs Compression Deadband in one line: The exception deadband is the first filter, applied at the collector or interface, that decides whether a new reading is different enough from the last one to be worth reporting at all; readings inside it are dropped before they ever reach the archive. The compression deadband is the second filter, applied at the archive, that decides which of the reported readings are actually written to permanent storage. Data must pass the exception test to become a snapshot, then pass the compression test to be archived.

Two Stages, Two Deadbands

Data moving into a historian passes through a pipeline: the field device or collector reads a value, an exception test decides whether that value is worth sending, the surviving value becomes the current snapshot, and a compression test then decides whether the snapshot deserves a permanent slot in the archive. The exception deadband governs the first gate and the compression deadband governs the second, and they operate at different places for different reasons.

The exception deadband lives close to the source, at the collector or interface. Its job is to cut traffic before it travels: if a new reading is within the exception deadband of the last reported reading, the collector simply does not report it, saving bandwidth and processing on everything downstream. This is the filter that matters most on constrained links, because a value that fails the exception test never even reaches the historian server.

The compression deadband lives at the archive, inside the historian. It only ever sees values that already survived the exception test and became the current snapshot. Its job is different: decide which of those snapshots are structurally necessary to reconstruct the trend, typically using a swinging door style corridor, and discard the rest so the archive stays small. Passing exception gets you to the snapshot; passing compression gets you into permanent history.

Why the Distinction Trips People Up

The confusion comes from both stages being called deadbands and both discarding data that looks insignificant, so operators reasonably assume they are the same knob in two places. They are not. The exception deadband controls what is reported and therefore what the historian can ever know about; the compression deadband controls what is retained from what was reported. A value dropped by exception is invisible to compression forever, because compression never sees it.

This ordering has a practical consequence that surprises people: the exception deadband should always be tighter than or equal to the compression deadband. If exception is set wider than compression, the collector filters out data the archive would have wanted to keep, and no amount of tuning the compression deadband can recover it. The archive can only be as faithful as the stream feeding it, and that stream is shaped by the exception test first.

The classic symptom of getting this backwards is a trend that looks strangely coarse no matter how tight the compression setting is turned. Engineers chase the compression deadband down expecting more detail, and nothing changes, because the missing detail was thrown away upstream at the exception stage. The fix is to look at the collector, not the archive, whenever tightening compression fails to produce the resolution you expect.

The Two Deadbands in Field Monitoring

In a distributed oil and gas operation the two stages map cleanly onto physical reality. The exception deadband belongs out at the wellsite or the collector, where it decides how much a cellular or satellite link has to carry back. The compression deadband belongs at the central historian, where storage cost and query speed are the concern. Tuning them separately lets an operator save bandwidth in the field and storage at the center without one setting undermining the other.

Getting the split right matters most on remote sites with expensive or intermittent connectivity. There the exception deadband is doing real work every minute, keeping the collector from paying to transmit noise, while the compression deadband keeps years of returned data affordable. An operator who understands both can loosen exception to save airtime on tags that only need to look right, while keeping it tight on the tags that feed allocation and compliance.

Merobix exposes both stages so the field and the archive can be tuned independently: an exception setting near the source controls what each remote device reports over its link, and a compression setting in the cloud controls what is retained long term. Because the two are visible and separate, a Merobix operator who sees a coarse trend knows to check whether the value was filtered out at the collector or merely compressed at the archive, and can fix the right stage instead of guessing.

Frequently Asked Questions

What is the difference between exception and compression deadband?

The exception deadband is applied at the collector and decides whether a reading is different enough to be reported at all, filtering data before it reaches the historian. The compression deadband is applied at the archive and decides which of the reported values are permanently stored. Exception controls what the historian ever sees, while compression controls what it keeps.

Should the exception deadband be tighter or wider than the compression deadband?

The exception deadband should generally be tighter than or equal to the compression deadband. If exception is wider, the collector filters out data the archive would have kept, and that data cannot be recovered by any compression setting. The archive can only be as detailed as the stream that survives the exception test.

Why does tightening compression sometimes not add detail to a trend?

Because the missing detail was probably dropped earlier at the exception stage, before it ever reached the archive. Compression can only retain values that survived the exception test and became snapshots. If a trend stays coarse no matter how tight compression is set, the fix is usually to tighten the exception deadband at the collector, not the compression deadband at the archive.

From Definitions to a Live Dashboard

Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.

Request a Free Demo +1 (903) 307-7300
More in Automation Glossary
Interpolated vs Stepped Tags  •  Linear Interpolation  •  Time-Weighted Average  •  Downsampling Time-Series Data  •  Data Rollup  •  Historian Backfill  •  All Automation Glossary →
Free SCADA operator training
Merobix University - 70 video lessons & 261 quiz questions, from first login to compliance reporting. No demo call required.
Start free →