Why Your Historian Missed the Pump Trip: Exception vs Periodic Collection
Exception and periodic collection store different truths. Picking per tag so a 300 ms interlock survives, and proving the choice during commissioning.
The trend was flat. The pump had tripped.
Six weeks after startup, someone pulls up the historian to explain a downstream upset. The discharge pressure trend is a clean, boring line. But the operator swears the pump kicked out and restarted on its own. Both are right. The pump did trip — for about 400 ms — and the run-feedback tag was on a 5-second periodic sample. The historian never looked during the window the bit was low.
A historian doesn't store "the plant." It stores the samples you told it to collect, and the collection method quietly decides what you're allowed to prove later. Two systems wired to the same PLC will disagree about history if one polls on a fixed clock and the other stores on change. Neither is wrong. They answer different questions.
So stop applying one collection template to every tag. Pick the method per tag, and pick it based on what someone will ask that tag to answer, not on how many tags you have to configure before Friday.
Periodic is honest about being blind
Periodic sampling writes a value on a fixed interval — every 1 s, 10 s, 60 s — whether or not anything happened. Its virtue is that timestamps line up across tags, so table reports and cross-correlation are trivial. Its vice is that it is completely blind between samples, and honest about it: a 300 ms interlock, a pressure spike, a bounce on a limit switch all vanish if they fall between ticks.
Use it for things that move slower than your interval: tank level, room temperature, cooling-water header pressure, any value where a fixed-interval average is genuinely what the report wants. I'll happily put a jacket temperature on a 30-second periodic. I will not put a safety-interlock bit there, because the whole point of that bit is the brief moment it changes.
The other trap is the opposite one — a fast periodic rate on a value that barely moves. A flow that sits at 42.0 m³/h all shift doesn't need a 1-second archive; you're paying storage and PLC/OPC poll load to record "still 42" three thousand times an hour.
Exception stores meaning, if you set the deadband honestly
Exception collection writes a new value only when the source moves enough. For a discrete, "enough" is any state transition. For an analog, it's a deadband — and this is where people get careless.
The deadband can be absolute (0.5 barg) or percent of span. In OPC UA that's spelled out in the spec: the DataChangeFilter (Part 4) carries a DeadbandType of None, Absolute, or Percent, where Percent is a percentage of the node's EURange (Part 8). So a 1% percent-deadband on a 0–10 bar transmitter suppresses moves under 0.1 bar. Pick the number from the sensor, not from a round figure that looks tidy: if the transmitter is ±0.25% of span, a deadband tighter than that is just archiving instrument noise, and a deadband ten times looser than that is throwing away real process movement to save disk.
One distinction that trips people up: on many platforms, exception and compression are two separate stages, and setting only one gives you a false sense of safety. OSIsoft/AVEVA PI is the clearest example — the interface applies an exception test (ExcDev/ExcMax/ExcMin) to decide what leaves the interface, and the archive then applies compression (CompDev/CompMax/CompMin, a swinging-door algorithm) to decide what actually gets stored. A tight exception deadband buys you nothing if compression downstream throws the change away. Check both, or you'll tune one and swear the historian is broken.
Where exception earns its keep: motor run/stop feedback, valve open/closed, permissives and interlocks, operator setpoint and mode changes, counters where every increment and rollover has to stay in order. The failure modes are the mirror image of its strengths — a deadband set for storage savings becomes the root cause in a quality investigation, and a genuinely noisy tag can flood the archive with thousands of "changes" that are all sensor hash.
Match the method to what the tag has to prove
Start from tag intent, not tag count:
| Tag type | Preferred approach | Field note |
|---|---|---|
| Slow analog process value | Periodic, or exception with a sensor-based deadband | Confirm ramps and operating limits still show |
| Fast analog with short spikes | Faster periodic plus min/max, or exception with a tight threshold | Trend the known disturbance during commissioning |
| Motor run feedback | Exception on change | Store both the start and the stop transition |
| Alarm active state | Exception on change, separate from the alarm journal | Historian timing should agree with the alarm record |
| Operator setpoint | Exception on change, with user/audit context if available | Don't compress away small but valid setpoint moves |
| Production counter | Exception on change, or periodic with explicit rollover handling | Record reset, rollover, and manual-correction behavior |
| Quality / comms status | Exception on change plus a periodic heartbeat | A long flat "Good" must not hide a dead collector |
The heartbeat row matters more than it looks. If a communication-status tag only stores on change, a collector that dies silently leaves a flat "Good" forever — the absence of change looks identical to healthy. A periodic heartbeat on that one tag is the difference between "we lost data at 02:14" and "we have no idea when we lost data."
Prove short events before the first incident review
Don't discover during a downtime meeting that the historian missed the event everyone's arguing about. Build a five-minute commissioning test while you still have the plant in your hands.
For a discrete tag: force a known on-off-on sequence through the actual driver path, and include one pulse near the shortest duration you care about — if the interlock can fire for 250 ms, test 250 ms. Then confirm the historian stored each transition in the right order and that its timestamps agree with PLC diagnostics or the alarm journal.
For an analog: drive a normal operating ramp, then inject one change just above the deadband and one just below it. The trend should show the real move and swallow only the noise.
Do this against the live collector, not an import file. A CSV import proves the archive can hold data; it proves nothing about the scan class, the driver queue, or store-and-forward ordering — which is exactly where short events get lost.
Scan rate, deadband, and compression fail together
These settings are chained, and a mistake anywhere upstream can't be recovered downstream. A tight deadband can't resurrect an event the collector never scanned. A fast scan rate is wasted if compression later discards the change. So look at them as one group per tag:
- PLC task period for the source value
- SCADA driver poll rate, or OPC UA subscription publishing/sampling interval
- Historian exception threshold / deadband
- Compression rule, if it's a separate stage (see PI above)
- Minimum and maximum time between archived samples
- Behavior on bad quality, disconnect, and backfill
The classic trap: a tag looks perfect on the live HMI because the screen refreshes every 500 ms, but the historian collector is assigned to a 10-second scan class. The operator saw the event with their own eyes. The historian was asleep.
One more thing before you go big on deadbands
Big deadbands are tempting because storage is a line item and bad history isn't — until an incident, an audit, or a warranty claim turns it into one. Storage is cheap; a year of data that can't answer the question people are actually asking is not.
Keep raw transitions for critical discretes instead of trusting a sampled trend to catch them. Add min/max or short-interval summaries where peaks carry meaning. Push old high-resolution data into a retention tier rather than over-compressing today's data. And review your high-sample-count tags a week after startup — most of the offenders are wiring noise, unstable scaling, or a quality flag flapping, not real process movement.
Whatever you settle on, leave the next engineer a one-line note per important tag: method, scan/subscription interval, deadband and compression, archive interval, bad-quality behavior, and the commissioning evidence that short events, ramps, and rollovers actually made it in. Historian configuration is part of the control-system design. Treat it as a storage afterthought and the site ends up with years of data that can't answer the one question someone finally asks.