What is an Industrial Historian? The Historian Database for Process Data

A historian stores process data: the values of simple data points, often called tags, recorded continuously or on change, each value with a timestamp. With industrial sources, a third field comes along: the quality, which says whether the value can be trusted. From these series, the state of a plant can be analyzed over time.

Three techniques shape what ends up in a historian, and they act at different points:

A deadband is a tolerance band around the last value transmitted. A new value is passed on only when it leaves the band, and the band then re-centers on the new value. Compression, by contrast, is a property of the historian itself, and each vendor decides how it works.

A historian is explicitly not the place where current values are distributed. That is the job of a Unified Namespace; how values get into it and back out is covered in Connecting to a Unified Namespace. A Unified Namespace does not replace long-term history; that history typically lives in a historian, a time-series database or a data lake which, according to pronubes, reads from the namespace. A buffer that keeps only the last message per topic is not a historian either.

The two answer different questions, and many plants run both side by side.

The difference lies mainly in relationships. Related records carry references to an order, a batch or a material, and that is what a relational database is built for. A time series stored there shows up in the write load: indexes speed up queries but slow down every insert, and indexed columns that are updated often become fragmented. Whether that becomes a problem is a question of volume. According to the use-case overview on opc-router.com (page dated August 2026), two automotive suppliers in Turkey stored their production data in a SQL database, and both cases explicitly mention historical data collection. The basics of the query language are covered in What is SQL?, and non-relational stores in NoSQL in Industry 4.0.

A SCADA server takes care of data handling, alarm logic and history, and operator panels can keep histories of their own. The trend in a SCADA system serves the current shift: it shows what has just happened. A historian collects across many sources and over years.

In practice a second question matters: can other systems get at the data? A SCADA system that keeps its trends internal cannot be read from outside. A historian is built to be read. An aggregated value from the history is computed from the stored values, so it is a calculation, not a measurement. What is SCADA? goes into both points. This article covers the step before reading: what has already been condensed by the time a value arrives in the historian?

It reads from PLCs, OPC servers and SCADA systems and delivers to analytics, MES and the cloud. In the automation pyramid it is therefore less a level of its own than a store that several levels use. The OPC Foundation’s ISA-95 specification (OPC 10030) lists historians under Level 3. Whatever was condensed or dropped on the way in is no longer there. A historian at plant level is also called an operational historian; an enterprise historian collects a subset of the data from several plants for business functions.

The market ranges from classic industrial historians to general-purpose time-series databases. The list below describes; it does not rank.

• AVEVA PI System, formerly OSIsoft PI: a historian widely used in the process industries.
• Proficy Historian: stores process and production data across the enterprise and offers a REST API for retrieval.
• Canary Historian: a standalone industrial historian.
• InfluxDB: a time-series database, not limited to industry.
• TimescaleDB: an extension for PostgreSQL that keeps time series in a SQL database.
• Ignition includes history as one of its modules.
• Kepware Server (KEPServerEX up to version 6.18) lists “Local Historian and OPC HDA” among its plug-ins, plus a DataLogger that writes values to ODBC databases.

Through a connection that reads from the PLC, the OPC server or the SCADA system and stores the values through whatever interface the historian offers for writing. Which values reach the historian at all is determined by the trigger.

On change, the Data Change trigger sends a value when it changes, optionally only above a percentage or absolute difference. As a group, the Multi-Datachange trigger evaluates every data point in an OPC UA group with its own deadband and produces fewer, leaner transfers. On a schedule, the Cron trigger reads at fixed times, combined with OPC Batch Read when there are many similar addresses. Where every event has to be captured, the PLC needs a handshake with a counter.

As a target, the OPC Router writes to InfluxDB with its plug-in, to relational databases and to a table it creates itself if needed, using the DB Log Table transfer object. For other historians, the route depends on which interface they offer for writing. The OPC Router’s MQTT Data Storage is not a target of this kind: it keeps only the last message per topic, so no history builds up there. According to the use-case overview on opc-router.com (page dated August 2026), users who ran the OPC Router together with InfluxDB or a historian include the following:

• A Spanish dairy manufacturer collected data from an OPC server and used it to supply its PI systems.
• A global manufacturer of beverage packaging, listed under Belgium in the overview, picked up triggers from the shop floor and sent them to the historian.
• A manufacturer of home products in the US fed data from OPC servers into InfluxDB and standardized the connection with dynamic templates within and between plants.
• A Canadian university logged the energy use of its buildings to InfluxDB, with more than 80 connections.
• An insulating material manufacturer, listed under Japan in the overview, replaced a DCS historian with InfluxDB, relaying more than 10,000 data points every few seconds.
• An Austrian chemical company used the OPC Router as a data hub in several plants, with the InfluxDB plug-in among others depending on the site.

Writing to InfluxDB or a SQL table loses the quality unless it is written as a field of its own. With “Output Metadata”, the Data Change trigger outputs it together with the timestamp, and Quality-String and Quality-ID can be stored next to the value in the database.

How much one instance can handle is shown in two of the measurement series in the manual, run with an earlier version of the OPC Router and KEPServerEX on servers with 4 cores. Values were read by Batch Read from two KEPServerEX simulators, written to MQTT and InfluxDB at the same time, and checked after 30 minutes of running: 320,000 data points every 30 seconds all arrived in InfluxDB, at 640,000 it was more than 99 percent. In the second series, with the Multi-Datachange trigger, about 28,500 data points per second went to MQTT and InfluxDB, and there the OPC server was the limit. Both series are documented, with their project files, in the performance analysis section of the OPC Router manual. The manual contains no newer measurements of this kind.

In three ways, depending on what the historian offers.

Via OPC UA Historical Access. The OPC HA Read transfer object reads from an OPC UA historian, raw or processed. For periodic reports, the time syntax is useful: -1month day(1) means the first day of the previous month, -1year month(1) day(1) the first day of the previous year. The server has to support Historical Access as defined in the OPC UA specification. What that requires of the server and how the raw and processed read modes differ is covered in What is SCADA?; What is OPC UA? explains Historical Access itself.

Via an API. Proficy Historian can be queried through its REST API; the OPC Router does this with the REST plug-in, as the five REST API examples show.

Via SQL. When the history sits in a relational database, a select with a filter reads it. Grafana reads directly from InfluxDB and SQL databases. Power BI reads the SQL database directly but needs an additional connector or driver for InfluxDB. No middleware is needed on this route.

A connectivity layer decouples analysis and data extraction here. According to the use-case overview (page dated August 2026), the Spanish dairy manufacturer could change its data analysis systems without changing the way it extracted data from the process. The case is also described in What is SCADA?

The settings on the way into a historian are each defensible on their own. They take effect only in combination, and the consequence shows up somewhere other than where the setting was made. Another cause lies in the target itself: if the historian cannot be reached, the values from that period are missing unless the connection buffers them and passes them on later (Store and Forward). What is SCADA? covers how to recognize such a gap.

Condensed twice: deadband at the connection, compression in the historian

The historian shows a flat line for hours without a single sample point, and extreme values that appear in the control system are missing in the historian. The flat line can be a steady value, or a source that has stopped delivering. A connection that writes only on change also writes nothing when the source stops; “no new value” and “no value” look the same. The missing peaks were already dropped by the deadband before they reached the historian’s compression. Together, the two produce a resolution that was never set on purpose.

The operator owns the process decision on the deadband per variable. It has to match the compression configured in the historian; if the two are set separately, the data is condensed twice. On top of that comes the deadband the OPC server itself may already apply; What is a Distributed Control System? covers it. The analysis also has to take into account that a flat line inside the deadband can hide a change.

In the OPC Router, the deadband can be set in several places in the flow: on the Data Change trigger as a percentage or absolute difference, in the Change Gate, which runs downstream steps only on a relevant change, as an absolute or percentage threshold, and on the Multi-Datachange trigger per data point in the “Trigger Behavior per Data Point” tab, where it can be set differently for each part of the plant under “Exceptions for Subtrees”. This per-data-point evaluation is held in memory and starts over after a connection loss. “At least every” transfers the current value after the interval expires even if it has not changed, which provides a sample point.

That sample point shows that the connection is alive, not that the value is fresh: with a frozen source, it keeps writing the frozen value. For that, the source timestamp or quality has to be written as well, which “Output Metadata” provides. The Data Change Missing trigger fires when a data point does not change within a check period. The Change Gate discards values that arrive during its lockout time. With “Catching up on blocked openings” enabled, it passes on the last of those values, not the most conspicuous one, and only once the next cycle arrives after the lockout time.

Pre-aggregated is not time-weighted

In phases with rapid changes, the average in the historian drifts from the one the historian would have computed from raw data, and in quiet phases rows are missing. The values were averaged beforehand in the middleware, to take load off the historian: with one reading per second, one value per 15 minutes instead of 900 individual ones. An arithmetic mean over values written on change weights them by count, not by time. A value that held for ten minutes counts as much as one that lasted a second, so a phase with rapid changes pulls the mean toward itself. More on this in the SCADA article. In addition, a time window closes only with the first write after its end, and a window without a write returns no new value. That is the case when a deadband upstream holds back a steady value.

The operator owns the decision on which average applies, and it follows the analysis: time-weighted for state variables such as a temperature, arithmetic for counted events. It also has to be decided whether the raw values go into the historian as well.

A pre-aggregated value cannot be broken down again later.

In the OPC Router, metrics can be computed per time window. They are set up in the variables plug-in, in the edit dialog of a global variable with persistence: enable “Aggregation”, set the “Window duration” and pick the metrics. The options include Average, the arithmetic mean, and TimeAverage, which weights values by how long they were held, plus Total as a time integral and Count. Writing Count alongside makes thin windows visible. The windows sit on a fixed UTC grid. The metric is read with the variable trigger, because a time trigger is not aligned with the window grid and may still read the previous window. Two identical windows in a row do not fire the trigger.

Written in batches, lost one by one

The flow is green, yet values are missing in the historian. This shows up only in the log and by comparing the number of values written with the number read. For throughput, data is written in batches, and an error in a batch can then no longer be traced to a flow. Depending on the setting, null values can be discarded without a message, and close to the load limit not every value arrives.

The operator owns the decision on where throughput matters more than per-flow error tracking, and the log has to be watched there. The operator also decides whether a missing number should show up as a gap or may be replaced, and plans the load with headroom below the measured limit.

In the OPC Router, the option “Use batch and delayed/asynchronous inserts” in the InfluxDB 2.0/3.0 & Cloud plug-in switches on batch writing. According to the manual, flows then stay green even when inserts fail; the errors are logged. With batch writing, the “Timestamp Source” in the transfer object should not be “InfluxDB”. InfluxDB then stamps values only on receipt, and values it processes within the same nanosecond can be merged. The manual warns of data loss in this case and recommends “OPC Router (UTC)” or a timestamp passed in dynamically. Null handling is a default in the plug-in and can be set per transfer object: “Error” aborts the transfer, “Insert Discard” drops the value without an error message, and “Omit value” and “Replace Value” complete the choice. For more load, the connections can be spread across several instances.