What Is a Historian Collector?
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.
The collector's role in the historian architecture
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.
Store-and-forward and compression at the collector
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.
Historian collectors in oil and gas operations
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.
Configuring a Collector Deliberately
A collector configured by bulk-importing every tag in the source is a collector that will disappoint later. Start from the questions the archive must answer - regulatory reports, production accounting, troubleshooting trends - and collect the tags those need, with consistent naming, engineering units, and ranges carried through. Group tags into scan classes by how their signals actually move: fast classes for pressures and flows, slow ones for tank levels and slowly drifting temperatures. Then set deadbands per signal type on purpose; the choices made when configuring historian collector compression are where most archive quality is decided.
Two settings deserve explicit decisions rather than defaults: quality handling, so that bad-quality values are stored with their flag instead of being silently dropped or repeated; and buffer sizing, so the local store can ride out the longest outage the site realistically sees. Test both by unplugging things before go-live, not by discovering the behavior during the first real outage.
Timestamps: Whose Clock Is the Truth?
Every stored value carries a timestamp, and where that timestamp comes from matters. Sources that can stamp at origin - OPC UA servers, DNP3 outstations reporting events - preserve the moment the value actually changed; otherwise the collector stamps values on receipt, which folds in polling and transport delay. Mixing the two styles across sources is normal, but clock skew between them scrambles cause-and-effect when you reconstruct an upset, which is why verifying time sync across the SCADA stack belongs on the commissioning checklist.
Store-and-forward preserves original timestamps through an outage, which is exactly right - but watch for devices whose clocks reset after a power loss. A source that reboots to a default date will happily hand the collector a backlog of values stamped decades wrong, and those land in the archive where they are hard to find and harder to clean out.
Diagnosing a Collector That Is Losing Data
A gap, flatline, or stale trend usually traces to one of a short list of causes; check them in order:
- Source reachability - can the collector's host actually reach the PLC, RTU, or OPC server right now?
- Tag quality at the source itself - a sensor or controller problem is not a collector problem.
- Buffer health - disk space and backlog counters on the collector's local store.
- Configuration drift - did someone change the tag's scan class, deadband, or name?
- Archive acceptance - licensing, storage, and permissions on the historian side.
- Clock agreement between the collector and the archive.
The symptom itself narrows things: a gap means nothing was stored, which points at connectivity or the buffer; a flatline of repeated identical values points at a stuck source or an over-wide deadband. Whatever the cause, data the buffer never captured can only be reconstructed by hand, and backfilling the historian from a CSV file is the standard route for patching those holes from another record.
Frequently Asked Questions
Is a historian collector the same as the historian?
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.
What happens to data during a network outage?
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.
Does a cloud SCADA still use collectors?
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.
Where should a collector run - at the edge or next to the archive?
Put the collector on the good side of the worst network segment. If the fragile link is the WAN between a remote site and the historian, collect at the site so buffering protects the data; if source and archive share a solid plant network, co-locating with the archive simplifies administration. Buffering only helps for outages downstream of the collector, which is the whole logic of edge placement.
How many tags can one collector handle?
Capacity limits are product- and hardware-specific, so the honest answer comes from the vendor's documentation and a load test, not a rule of thumb. The practical constraint is usually scan load and change rate rather than raw tag count. Operationally it is better to run several collectors split by source or by scan rate than to push one instance to its ceiling, because a fault then takes down a slice of collection instead of all of it.
Sources and verification
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.
- Modbus Application Protocol Specification - Modbus Organization
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
- OPC Unified Architecture Specification (IEC 62541) - OPC Foundation
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.