Historian Architecture

The three layers

Collectors

Software that reads values from a source and sends them to the archive: an OPC or a native driver reading the SCADA tag database, a driver reading controllers directly, a calculation engine producing derived tags, a manual entry interface for lab results. Each collector runs where it can see its source and buffers what it reads until the archive acknowledges it.

The archive

The time-series store: for each tag, a sequence of timestamp, value, and quality, compressed and indexed by time. Not a general relational database, although some historians sit on one; the access pattern, append at the end and read ranges by time, is what the store is built for.

The server

The service that answers queries: raw values in a range, interpolated or sampled values at an interval, aggregates such as averages and totals, and event frames. Trend clients, reports, spreadsheets, and analysis tools all talk to it, and it is the layer that is exposed to users.

Where it sits

In the Purdue and zone models the historian is a control zone system, because it reads from controllers and SCADA and because its data is operational. Business users need the data too, and they do not get into the control zone to read it. The standard arrangement is a primary historian in the control zone collecting everything, and a replica or a relay in the industrial DMZ that the primary pushes data to, which the business network reads. The DMZ copy is read-only, holds whatever subset the business needs, and can be rebuilt from the primary. The push is outbound from the control zone, never a pull from the DMZ, and the DMZ design page explains why.

Collecting at the source

A historian can collect from the SCADA tag database, which is convenient, because every tag is already there with its description and scaling. It inherits every gap SCADA has: a driver outage, a SCADA server failover, a tag that SCADA polls slowly, a value SCADA clamps or rounds. For the tags that matter most, compliance values, flow totals, and anything analyzed later, a collector reading the controller directly, with its own poll and its own buffer, is more complete. Many utilities collect the bulk through SCADA and the critical few at the source; the data collection page covers rates and deadbands.

Redundancy and backup

The historian archive is the utility memory: the compliance record, the trend that explains an incident, the year of data behind a capacity decision. Its redundancy decision is separate from the SCADA redundancy decision. Options range from a single server with nightly backups of the archive files, which loses a day on a disk failure, through a mirrored pair of historians fed by the same collectors, to the tiered design where the central historian is the backup for each site. Whatever the choice, the archive files are on the backup list, the backup is restored on a test schedule, and the restore is timed.

Sizing

The archive grows by the number of values stored per day, which is the tag count times the rate at which each tag changes enough to be stored, times the bytes per value after compression. A utility with 5,000 tags, most on deadband collection storing a few values a minute, stores on the order of a few hundred megabytes a day and a hundred gigabytes a year, which fits on ordinary disks for a decade. The numbers move fast with collection rate: 5,000 tags at one-second full collection is fifty times that. The design sets the rate per tag from what the value is for, keeps the compliance tags at the rate the rule requires, and plans the disk for the retention policy plus growth.