A process historian stores years of time-series data, but it does not read field devices itself. That job belongs to the historian collector - the component that gathers tag values and feeds them in.
Historian Collector in one line: A historian collector is the software interface that reads tag values from a data source - a PLC, RTU, SCADA server, or OPC server - and streams them into a process historian for long-term storage. It handles subscription or polling, applies deadband and compression, timestamps each value, and buffers data locally so nothing is lost if the historian or network is briefly unreachable.
A historian has two halves: the archive that stores compressed time-series data, and the collectors that acquire it. The archive is passive - it stores what it is given. The collector is the active edge that connects to live data sources, reads values on a schedule or on change, and forwards them. A single historian typically runs many collectors, each pointed at a different source or protocol.
Each collector maintains its own list of tags to gather, along with per-tag settings for scan interval, deadband, and quality handling. When it reads a value it attaches a timestamp and a quality flag before sending it upstream. This separation lets an operator add a new data source by configuring a collector without touching the archive itself.
A well-built collector does not simply pass data through. It applies exception-based collection first: only values that change beyond a configured deadband are captured, which cuts the data volume dramatically before it ever reaches the archive. This is why the collector is where most of a historian's efficiency is won or lost.
The collector also buffers locally. If the link to the historian drops - common on cellular or satellite-connected sites - the collector keeps writing values to a local store and forwards them once the connection returns, preserving timestamps. Without this store-and-forward capability, a network outage would leave permanent gaps in the historical record.
In a distributed production operation, historian collectors are frequently placed close to the data - at the site RTU or an edge server - rather than centrally. Collecting at the edge means the deadband filtering and buffering happen before data crosses an expensive or unreliable WAN link, so only meaningful changes travel over cellular or radio.
Collectors are typically organized by source: one reads the OPC UA server aggregating a gas plant's DCS tags, another polls the Modbus flow computers at a tank battery, another subscribes to a fleet of RTUs. Each is tuned to the physics of its signals - fast collection for pressures that swing quickly, slow collection for tank levels that drift over hours.
The quality of long-term reporting, regulatory records, and trend analysis all depend on collector configuration. A deadband set too wide will smooth out real events; set too tight, it floods the archive with noise. Getting this right per signal type is the core skill of setting up historian collection.
No. The historian is the archive that stores and compresses time-series data. The collector is the interface that acquires values from field devices and feeds them into that archive. One historian usually has many collectors.
A collector with store-and-forward buffers values locally during the outage, preserving their original timestamps, and forwards the backlog when the connection is restored. This prevents gaps in the historical record - critical for sites on intermittent cellular or satellite links.
Yes, conceptually. Merobix reads tags from PLCs, RTUs and OPC UA sources at each site and streams them to the cloud with local buffering during connectivity loss, which is the same collect-buffer-forward pattern a traditional historian collector performs.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.