The short answer
How to Configure a Historian
To configure a historian, start with a tag list grouped into classes, process values, equipment status, setpoints, and compliance tags, and give each class a collection rule: an interval and a deadband for analogs, on change for discretes, every change for setpoints and compliance values; size the storage from the expected sample rate and the retention the plant needs, which for compliance data is years; enable store-and-forward buffers at every collector with enough capacity for the longest outage; point every source, collector, and server at one time source; and then test by trending each class through a known event, retrieving a value from a week ago, and pulling a collector cable to prove the buffer. Back up the configuration and the archive files on the schedule, and give the operators a trend that works before the historian is declared done.
Key points
- Classes of tags with collection rules per class; not every tag at one interval.
- Deadbands and intervals from the process: fine enough to see a cycle, coarse enough to fit the disk.
- Store-and-forward at every collector, sized for the longest outage.
- One time source for sources, collectors, and servers.
- Test collection, retrieval, and the buffer; back up the configuration and the archives.
What you need
- The tag list with a class for each tag
- The historian server with storage sized and the collectors installed
- The retention and compliance requirements from the permits and the plant
- A time source reachable by every component
- The backup system and a place for offline copies
Procedure
- 1
Classify the tags
Process analogs, equipment status, setpoints and commands, calculated values, compliance values, and system health. Each class gets a collection rule.
- 2
Set the collection rules
Analogs: a scan interval and a deadband so that a real change is stored and noise is not; a level at ten seconds with a small deadband, a tank at one minute. Discretes: on change. Setpoints: every change with the user. Compliance: fine interval, no compression beyond a tight deadband.
- 3
Size the storage
Estimate samples per day from the rules and the tag counts, multiply by the retention, and add margin; check the vendor sizing tool. Compliance data is retained for years; everything else per the plant policy.
- 4
Configure the collectors
Each collector with its sources, its tags, and its store-and-forward buffer sized for the longest outage at the collection rate; the buffer on disk, not memory.
- 5
Set the time
Every source, collector, and server on the same network time source; store in universal time and display local; alarm on time drift.
- 6
Set retention and archives
Archive files created ahead of need, retention per class, and an archive location with space monitoring and an alarm.
- 7
Build the calculations
Totals, daily values, normalized values, and runtimes computed in the historian or the controller and stored as tags, with the formula documented.
- 8
Test collection
Trend each class through a known event: a pump cycle, a setpoint change, a discrete transition. The samples should show what happened at the resolution expected.
- 9
Test retrieval and the buffer
Retrieve a value from a week ago through the trend tool and a report; pull a collector network cable for ten minutes, restore it, and confirm the gap fills.
- 10
Back up
Configuration export and archive files on the backup schedule with an offline copy; test a restore on a spare server.
- 11
Hand over
Operators get the standard trends and a report; engineers get the tag class rules and the sizing sheet in the engineering library.
| Class | Rule | Example |
|---|---|---|
| Fast process analog | 5 to 10 s, small deadband | Wet well level, discharge pressure |
| Slow process analog | 30 to 60 s, moderate deadband | Tank level, chlorine residual |
| Equipment status | On change | Pump run, valve open |
| Setpoint or command | Every change with user | Level setpoints, mode selections |
| Compliance value | 1 to 5 min, minimal deadband, long retention | Effluent flow, residual, pH |
| Calculated | Per calculation | Daily totals, runtime, normalized flow |
| System health | 1 to 5 min | Communication success, disk space |
Frequently asked questions
- How much history should I keep?
- Compliance data for the period the regulator requires plus margin, often five years or more; operational data for a year or two at full resolution and longer aggregated. Disk is cheap; data you deleted is gone.
- Should the historian collect from the controllers or from SCADA?
- From the controllers directly where the historian has drivers, so that a SCADA outage does not lose history; through the SCADA server where that is the only path. Either way, buffers at the collector.
- The trend shows gaps after every server reboot.
- No store-and-forward, or a buffer that is not enabled for those tags. Enable and size the buffer, and test it by pulling the cable.
- Who owns the historian?
- Someone named: a person who checks disk space, reviews the tag classes when tags are added, tests the restore, and updates the sizing. A historian without an owner fills its disk on a holiday.
Related topics
- Historian ArchitectureHow process history is collected, stored, and served: the collector, the archive, and the client layers, where the historian sits relative to SCADA and the DMZ, single-server and tiered designs for a utility, the store-and-forward buffer that survives outages, and the sizing that decides how many years fit on a disk.
- Historian Data CollectionDeciding what the historian stores and how often: polled versus exception collection, the deadband per tag, rates for control loops, levels, totals, and compliance values, timestamps at the source, quality codes, calculated tags, and the tag list review that keeps a historian from filling with noise and missing what matters.
- Historian CompressionHow historians store years of data on a disk: exception deadbands at the collector, swinging door compression at the archive, what each discards and what it keeps, the settings that turn a trend into a staircase, lossless alternatives, and how to check that the compressed data still tells the truth.
- Long-Term StorageKeeping historian data for years: a retention policy by data class that follows the record rules, tiered storage from online to offline copies, downsampling, archive management, exports that outlive the historian, and the annual proof that old data reads.
- Duplicate or Missing HistoryA historian with two records for one moment, or none: a redundant pair both collecting, a buffer that forwarded twice, a tag under two names, a daylight saving shift, or a source that resends on reconnect. Cleaning the record without inventing data.
- SCADA BackupsWhat a SCADA backup must contain to bring a system back: the project export, an image of each server, the databases, historian archives, licenses, certificates, scripts, and network device configurations, with frequency, retention, and the restore procedure.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.