Production data historian: what it manages
A production data historian is a dedicated storage layer that continuously saves measurements from PLCs, instruments and sensors as time series, so trends, loss analysis and traceability can be queried later—in a tire group project, the delivered system connected 366 curing presses in phase one, collected real-time values on a 6-second cycle, and kept three years of data with outage backfill, all confirmed by the technical agreement (2026 archived records).
How a historian divides work with real-time monitoring
Many factories already run SCADA or dashboards, yet still need a historian—because the two answer different questions:
- Real-time monitoring answers "how are we doing now": current values, current alarms and current states, refreshed in seconds.
- A historian answers "what happened in the past": curves for any variable over any period, aggregates and cross-shift comparisons.
- Both share one acquisition path but store data for different purposes—one serves operations, the other serves analysis and traceability.
- The typical gap without a historian: screens look normal, but during an audit or review no complete curves can be produced.
In the tire project mentioned above, this division was implemented as follows: the SCADA/MES side handled real-time monitoring and reporting, the historian side kept long-term curing process curves, and data collected during network outages was backfilled once the link recovered.
The acquisition path from equipment to historian
For data to reach the historian reliably, each layer of the path has a clear job:
- Access layer: read equipment and instrument data over proven protocols such as major PLC families, Modbus and OPC UA; legacy devices without communication ports are retrofitted first.
- Edge layer: gateways cache locally during outages and resend automatically after recovery, so historical curves stay complete.
- Transport layer: uplinks such as MQTT carry certificate-based authentication; data is cleaned and forwarded against tag rules on the server side.
- Storage layer: a time-series database organizes writes per tag for trend queries, reports and traceability interfaces.
This path supported 366 curing presses on one network segment with 6-second real-time sampling in that project; an earlier chemical SCADA engineering effort carried roughly 80,000 variables and more than 24,000 alarm points (figures confirmed by the project lead).
Four data conventions to settle before kickoff
Historian projects rarely fail at storage itself—they fail at unwritten conventions. The recommended approach is to confirm four items line by line in a tag list before work starts:
| Convention | What to confirm | Common sticking point |
|---|---|---|
| Tag list | Which variables to collect, units and ranges | Field instrument names differ from drawings |
| Sampling cycle | How often for real-time values vs. on-change uploads | Too dense inflates storage; too sparse loses peaks |
| Time source | Device clock or collection time | Time zones and clock drift misalign curves |
| Naming rules | Mapping between tag codes and asset numbers | Vendors naming independently makes merging impossible |
In that tire project, tag and curve protocols plus master-data mapping were fixed at the technical-agreement stage, which later let group-level multi-site replication reuse the same template.
Retention periods and backup policy
How long to keep history is a management decision derived from traceability and audit requirements, not a technical parameter:
| Policy item | Recommended approach | Basis |
|---|---|---|
| Retention period | Set to the longest requirement from product traceability and customer audits | The project kept three years per the agreement |
| Redundancy and backup | Server-side redundant cluster, dual-machine hot standby, RAID1 disks | Configuration practice from large SCADA/MES projects |
| Continuous operation | 7×24 operation and outage backfill written into the technical agreement | Enforced contract clause, accepted at handover |
| Capacity planning | Estimate as tags × cycle × years and reserve room to grow | Part of the pre-kickoff convention review |
Writing the period, backup and backfill into contract terms rather than verbal promises is a proven approach that keeps acceptance free of disputes.
Summary
Building a production data historian comes down to four points: a storage role clearly divided from real-time monitoring, a four-layer acquisition path, four data conventions settled before kickoff, and retention planning derived from traceability and audit requirements. Check your existing system against these lists and close the first missing layer first. You are welcome to start with an on-site diagnosis request.
Request an on-site diagnosis
Have an experienced engineer review your current acquisition path and data conventions, and get a recommended approach that settles the specifications before kickoff. English-speaking contact is available throughout.
Contact Us