Designing a SCADA Historian That Doesn't Become Useless in Two Years

Tag naming, retention policy, and compression settings decided during commissioning that determine whether your historian is still queryable later.

A SCADA historian is easy to stand up and surprisingly easy to render useless within two years through small decisions made during commissioning, under deadline pressure, by whoever happened to be configuring tags that week. The data is technically still there; nobody can find or trust it.

The two-year problem

The pattern is consistent across audits: a historian configured during a rushed commissioning, with inconsistent tag names, default compression settings nobody reviewed, and zero metadata connecting a tag to what it physically represents. Two years and two staff turnovers later, nobody on site can confidently say what `PV_2241B` measures, whether the compression settings are silently discarding the transient spikes that actually matter for troubleshooting, or whether the retention policy already deleted the data from the incident everyone wants to investigate.

Tag naming conventions

A tag naming convention only works if it's enforced from the first tag, because retrofitting tens of thousands of historian tags later is a project nobody ever actually staffs. The convention that's held up best across our projects follows an area-equipment-measurement structure, e.g. LINE2.FILLER.TEMP_PV rather than a flat, unstructured name like TT_104 that requires institutional memory to decode.

• Area/line prefix: makes filtering by production area trivial in any client tool
• Equipment identifier: matches the P&ID or equipment list, not an internal PLC address
• Measurement type suffix: distinguishes process value (PV), setpoint (SP), and output (OUT) consistently

Retention and compression tradeoffs

Historian compression (commonly exception-based or swinging-door algorithms) trades storage size against fidelity, and default settings are rarely right for every tag. A slow-changing tank level tag can tolerate aggressive compression with no real loss; a fast pressure transient on a safety-relevant loop cannot — compressing it too aggressively can silently discard exactly the spike an incident investigation needs six months later.

Retention policy needs the same deliberate treatment: raw high-resolution data for a defined recent window (commonly 30–90 days), with automated rollup to lower-resolution averages for longer-term trending, and an explicit, documented decision about how long raw data for safety-relevant or quality-relevant tags is retained relative to your regulatory and insurance requirements — not whatever the historian's default happened to be.

Adding context, not just data

Numbers without context don't answer the questions people actually ask a historian two years later. A useful historian configuration also captures: equipment metadata linking tags to a maintenance/asset ID, units and engineering range stored alongside the tag (not just in a separate spreadsheet someone will lose), and event/annotation logging so operators can mark a batch start, a changeover, or a known anomaly directly on the timeline rather than relying on a paper logbook nobody cross-references later.

Commissioning-time checklist

1. Lock a tag naming convention before configuring the first tag, and document it somewhere more durable than one engineer's memory
2. Review compression settings per tag type, not as a single platform default
3. Set retention policy deliberately, with raw vs. rolled-up windows matched to actual investigation and compliance needs
4. Attach units, engineering range, and equipment ID metadata to every tag at creation time
5. Build in event/annotation capability from day one so operational context isn't lost