Key takeaways
Short answer: A plant historian is a high-frequency time-series database storing every PLC tag with sub-second resolution. OEE platforms either read from an existing historian or store data at historian cadence themselves. The question is not "do I need a historian or an OEE platform" — it is "where does the time-series data live and is the resolution good enough to support OEE analytics." See also OEE vs Utilization.
A historian is a specialized database optimized for time-series data — millions of (timestamp, tag, value) tuples per second, retained for years, retrievable for any time window. Typical applications:
Common dedicated historians: OSIsoft PI (now AVEVA PI), Aspen IP21, Honeywell PHD, Wonderware Historian (now AVEVA Insight). In cloud / open-source: InfluxDB, TimescaleDB, AWS Timestream, Azure Time Series Insights.
OEE math requires precise time-state tracking:
Lose any of these and OEE becomes approximate. A historian (or historian-grade storage inside the OEE platform) is what makes OEE precise enough to act on.
Architecture A: dedicated historian feeds OEE. The plant has an existing PI or InfluxDB. The OEE platform subscribes to the relevant tags and computes OEE in real time, with the historian as the long-term store.
Pros: long-term storage already solved. Many tools can read from the same historian.
Cons: another system to maintain. Latency added by the round trip.
Architecture B: OEE platform is the historian for production data. No dedicated historian. The OEE platform captures PLC signals directly and stores them at high cadence internally.
Pros: simpler stack. Lower latency.
Cons: long-term retention may be limited. Other consumers (engineering, lab) cannot easily query.
Most SMB plants are fine with architecture B for production data. Plants with regulatory traceability (pharma, food) typically need a dedicated historian regardless.
1. Sampling production data at low frequency. 1-minute averages miss micro-stops and short cycles. OEE built on 1-minute aggregates is fiction.
2. Treating the SCADA database as a historian. SCADA databases are tuned for current state, not long-term time series. They fall apart at scale.
3. Skipping retention planning. Three years of high-frequency PLC data is large. Plan downsampling from day one.
4. No tag governance. Adding tags without standard naming makes the historian unusable. Establish naming conventions before scaling.
For plants with PI, the OEE platform is usually a PI client subscribing to relevant tags. PI continues to be the system of record for time-series data; the OEE platform computes and presents OEE on top.
For plants without PI, the OEE platform is often the de facto historian for production data — which is fine for most use cases but does not replace PI for process engineering or regulatory archives.
Fabrico's OEE module ships with an internal time-series store and integrates with external historians (PI, InfluxDB, TimescaleDB) for plants that have them — giving the team flexibility on the data layer.
See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.
Usually no for production data alone. Yes if you have regulatory traceability requirements, multi-system consumers, or process engineering needs that go beyond OEE.
It works for small scale. At industrial scale (thousands of tags, milliseconds resolution, years of retention) you need a time-series-specific store.
Depends on use. Production troubleshooting usually needs 30-90 days raw; long-term trends can live on downsampled aggregates.
Both are time-series databases. PI is the long-standing industrial standard with mature integrations. InfluxDB is open source, popular in cloud-native and modern stacks. Both work for OEE.
Some can. Useful for storing computed OEE values alongside raw PLC tags so external consumers can read OEE from the same source.
Login
Blog
