An industrial data historian is software that collects time-stamped values from plant equipment, stores them compactly for years, and gives them back quickly when someone asks what happened. On an energy site those values are things like export power, grid frequency, cell temperatures, breaker positions and alarm states, usually read from PLCs, meters and controllers once a second or faster.
The idea is old. Process plants have run historians since the 1980s because operators kept asking the same questions: when did this start, what else moved at the same time, and was it like this last month? What has changed is the scale. A 20 MW battery site can have 2,500 signals, which is more than many refineries had when the first historians were written.
What a historian does
Every historian does three jobs.
- Collect. It connects to the plant's controllers over industrial protocols such as OPC UA and Modbus TCP, and receives each signal's value with a timestamp and a quality code.
- Store. It writes those values to disk in a form built for time series: compressed, ordered by time, and safe against power cuts and restarts.
- Serve. It answers questions about the past quickly: a trend over the last hour, the average over a month, the raw values around a trip, an export for a spreadsheet or a report.
Most also add alarms, calculations (daily energy, run hours), reports and a viewer, but those three jobs are the core. If any of them is weak, the rest does not matter.
Historian, SCADA or database?
People often ask why a site needs a historian when the SCADA already draws trends, or when a general database is free.
| SCADA or HMI trends | General database | Data historian | |
|---|---|---|---|
| Main job | Operate the plant now | Store any kind of record | Keep the plant's time series for years |
| Typical history | Days to weeks, often at reduced resolution | As long as someone designs it for | Years, at full resolution |
| Collection | Built in | Needs a separate collector | Built in |
| Quality and gaps | Varies | Up to whoever builds it | Stored with every value |
| Who looks after it | The SCADA vendor or integrator | Someone with database skills | Designed to run unattended |
SCADA trends are made for operators watching the plant now. Many keep a few weeks, roll over, and average old data. A general-purpose database can store anything, but it does not know what a quality code or a gap is, and someone has to build and maintain the collection, retention and backups around it. A historian does that one job as its whole purpose.
Why the details matter on energy sites
On a battery or generation site, the stored data is often evidence. It shows whether a frequency response was delivered, why a rack tripped, whether degradation is inside warranty and what the site did during a grid event. That changes what you need from it.
- Resolution. One-second data or faster. Five-minute averages hide exactly the events that cause disputes.
- Honest gaps. If the link to the PLC dropped for two minutes, the record should say so. A trend that joins the line across the outage shows a response that was never measured. We cover this in why trends draw lines across outages.
- Ownership. Data held only in an equipment supplier's cloud portal is not the operator's record. Data on site, in open formats, is.
- Unattended running. Sites are remote. The historian has to start with the PC, survive power cuts and say clearly when something is wrong.
How historians store so much
A naive store of one value takes about 17 bytes: 8 for the timestamp, 8 for a double-precision value and one for quality. At 2,500 signals a second that is over 3.6 GB a day. Historians cut this in two ways.
Lossless compression keeps every value exactly. Timestamps that arrive at regular intervals compress to almost nothing with delta-of-delta encoding, and slowly changing values compress well with XOR or decimal encoding. Vault's measured figure is between about 2 and 7 bytes per sample on disk, depending on the signal mix.
Lossy compression throws values away. A deadband stores a new value only when it moves by more than a set amount; swinging door drops values that lie close to a straight line. Both save a lot of space on slow signals. Both can hide short events, so a good historian lets you choose per signal and states in every export which rule was in force.
What to check before you choose one
Whatever you are considering, these questions separate a historian you can trust from one you will regret.
- What happens in a power cut? Ask how much data can be lost, and how the vendor knows. A write-ahead log with a stated sync interval is a good answer. "Nothing is lost" is not.
- What happens when a source drops? Pull the network cable on a test bench and look at the trend and the export afterwards. You want a marked gap, not a straight line.
- How is it licensed? Per tag, per server or per site. Per-tag pricing can be reasonable for 200 signals and painful for 5,000.
- What else has to be installed and maintained? A separate SQL server, a platform, a Linux box, a cloud subscription?
- Can you get all the data out? In formats such as CSV and Parquet, without paying for an export module.
- Who supports it, and how fast? On a site with a commercial obligation, "the community forum" is not a support plan.
Where Vault fits
Vault is our historian. It is built for exactly this case: one site, one Windows PC already in the panel, thousands of signals over OPC UA and Modbus TCP, records that must hold up as evidence, and nobody on hand to look after a database. It keeps every value with its quality, writes gaps into the record, seals each day's file with a hash and is licensed per site with no tag limit. The product tour shows how it looks, and how Vault is tested shows what has been proven so far.