Setting Historian Deadbands So Trends Aren't Noise or Lies
Picking historian deadbands and compression from the instrument and the process, not HMI decimal places, so trends keep movement without storing noise.
When the historian quietly lies to you
An operator swears the discharge pressure spiked right before the pump tripped. You pull the historian trend and it is a clean flat line at 620 kPa straight through the event. The process moved. The historian just never kept it.
That flat line is a deadband and compression problem, and it is the most common way a historian misleads people who trust it. The opposite failure is quieter but just as bad: a 0-1000 kPa transmitter archiving a point every scan because someone set a 0.01 kPa deadband, and now three years of disk holds mostly sensor noise nobody will ever trend.
Neither number should be a default copied from the last project. Pick it from the signal, the instrument accuracy, and what you actually do with the tag.
Scan, exception, compression — three different knobs
Every historian I have worked with splits this into three layers, whatever the product calls them. Getting them confused is where most bad settings come from.
| Layer | What it controls | The question it answers |
|---|---|---|
| Scan / collection rate | How often the source is read | How fast can this value matter? |
| Exception / deadband | Which changes get sent forward | Is this change bigger than noise? |
| Compression | Which received points get archived | Can I redraw the trend shape from what's kept? |
In OSIsoft PI these map straight onto real parameters: the exception layer is ExcDev (exception deviation), and the archive layer is CompDev — the swinging-door trending algorithm that drops any point falling inside a sloped corridor between the last archived value and the current one, bounded by CompMax so a dead-flat signal still writes something eventually. Other historians use boxcar-backslope or a plain archive deadband, but the shape of the decision is the same.
The order matters because the layers are destructive in sequence. If the scan rate is too slow, no amount of compression recovers detail that was never sampled. If the deadband is too wide, the historian never even sees the movement. If compression is too aggressive, the stored trend comes out smoother than the real process — the swinging door widens its corridor and quietly eats the small oscillation you were trying to diagnose. And when values arrive through an OPC UA client instead of a direct scan, the DataChange filter and deadband on that subscription strip changes before the historian's exception and compression ever run. Tune both or you will chase a ghost.
Group tags by how they behave, not by name
Copying settings from the previous project is how a totalizer ends up compressed like a noisy analog. Sort tags by behavior first:
| Signal class | Example | Starting approach |
|---|---|---|
| Slow analog | Tank level, ambient temperature | Slower scan, modest deadband |
| Fast analog | Pressure during valve movement | Faster scan, tight deadband — loosen after commissioning |
| Totalizer | Energy, flow total, production count | Store meaningful increments and resets, never a percent deadband |
| Discrete state | Running, faulted, mode | Every transition with its timestamp |
| Setpoint | Operator or recipe value | Every accepted change, no compression |
| Quality / comms | Device online, bad quality | Transitions only, not periodic repeats |
Put the class in the tag import sheet. Six months later it is the only thing that explains why two tags with nearly identical names archive differently.
Pick the number from the instrument, not the display
An HMI shows one decimal because it looks tidy. That tells you nothing about how accurate the measurement actually is. Base the deadband on the real measurement chain: sensor accuracy and repeatability, PLC scaling resolution, the engineering-unit range, normal process noise, and the thresholds an operator or a controller actually acts on — alarm setpoints, control limits, batch report boundaries.
Concrete case: a 0-1000 kPa pressure transmitter with normal noise of about ±0.4 kPa. A 0.01 kPa archive deadband just stores that noise forever. Set it near 0.5 kPa for normal operation. But if that same tag is being used for a pressure step test during commissioning, 2 kPa is already too wide to see the response — so tighten it for the test and put it back after. The right deadband is not a property of the tag; it is a property of what you are using the tag for that week.
Percent deadband is convenient and misleading
Percent-of-span is easy to apply across hundreds of tags, which is exactly why it hides problems. The same 1% means very different things:
| Range | 1% deadband | Field concern |
|---|---|---|
| 0-100 °C | 1 °C | Fine for utility water |
| 0-10,000 L/min | 100 L/min | Too coarse for flow-balance work |
| -50 to 150 °C | 2 °C of span | Hides real cold-room movement |
| 0-14 pH | 0.14 pH | Way too loose for process control |
For anything important, write the deadband in engineering units in the design notes even when the historian stores it as a percentage. The percent is for the tool; the EU value is for the next engineer.
Validate against real movement, not the smoothness of the trend
A trend that looks clean is not evidence the settings are right. After loading them, drive real or staged movement and check replay against live:
- Quiet period — is the historian writing a point every scan when nothing is happening?
- Ramp — does replay preserve the slope closely enough to read a rate?
- Step change — is the timestamp and final value acceptable?
- Alarm event — are the pre-event and post-event values both there?
- Bad quality — does replay show a gap or a quality marker, or a false frozen value?
- Unit conversion — are the trend values in the units operators actually see?
Keep the evidence: screenshots or exported values from at least one quiet period and one active movement. That is what you point to when someone asks why the settings are what they are.
Starting points to argue with
Not rules — review points. Every one of these should get challenged against the actual instrument and process.
| Tag type | Scan | Deadband idea | Notes |
|---|---|---|---|
| Tank level | 2-10 s | 0.1-0.5% of span | Tighten for custody or batch inventory |
| Motor current | 1-5 s | From normal load noise | Capture starts separately if you need them |
| Temperature loop PV | 1-5 s | Near instrument repeatability | Do not let it hide oscillation |
| Valve position | 1-2 s | 0.5-1% | Store command and feedback if both exist |
| Batch step number | On change | none | Every transition matters |
| Alarm active bit | On change | none | Preserve the exact set/clear sequence |
| Comms quality | On change | none | Do not archive good-good-good forever |
During startup, run tighter than this on critical tags until you understand the process. Review storage volume and trend usefulness before relaxing anything.
A flat line is a symptom, not a diagnosis
Flat historian trends are not always a stable process. They can also mean:
- The deadband is wider than the movement.
- Compression removed the intermediate points.
- The PLC value froze after a comms loss and the historian kept storing the last good value with no quality flag.
- The source address changed but the historian tag still points at the old one.
- The scan class is disabled or running far slower than you think.
When a flat line looks wrong, compare four things: live SCADA value, source PLC value, historian current value, and archived value. Never diagnose from the replay trend alone — the replay is the one thing your settings already shaped.
The mistakes worth naming
- One deadband applied to every analog tag.
- Archive precision set from HMI decimal places.
- Bad-quality replacement values stored with no quality marker.
- Setpoints left to compress like noisy analogs.
- Mode, recipe, batch, and equipment state not archived alongside the process values that only make sense next to them.
- Reviewing disk usage but never trend usefulness.
- Changing compression after startup and not writing down why.
Whatever you hand over, make the settings explainable: tag/archive class definitions, scan rates and deadband assumptions in EU, compression for the critical groups, the exceptions and why they differ, the quality-handling rules, a couple of validated example trends, and who owns future tuning. An engineer who can see why a tag is stored the way it is can retune it safely when the process changes. One who can't will either leave it wrong or make it worse.