Industrial data platforms and historians in 2026: layers, architectures and examples

Operations data is the raw material for every digital initiative. Platforms differ in the layer they serve: storing time-series data, contextualising it, or analysing it. Clarity on the layer avoids buying overlapping tools.

How this page was made. It is an editorial explanation of the layers, with a few vendors cited as examples from their own public pages. We have not tested the products, received payment or ranked vendors. Vendor statements are marked as such; confirm features and pricing directly with suppliers.

Our criteria

• Fit to your industry, scale and existing systems.
• Openness: standard interfaces and data export.
• Security appropriate for OT environments.
• Support and partner ecosystem in your region.
• Total cost over the life of the deployment.

The layers of an industrial data platform

"Data platform" covers several different products, and confusing them causes many failed projects. A useful mental model has four layers.

1. Collection and the historian

An operational historian is a time-series database built for plant process data⁵. Historian functions are frequently built into, or run next to, DCS and PLC control systems, where they add data capture, validation, compression and aggregation⁵. The vocabulary comes from the plant floor: these systems were originally built to capture instrumentation and control data, and the word "tag" for a stream of process data comes from the physical tags attached to instruments for manual data collection⁵. Data access matters; raw data can be reached through interfaces such as OPC HDA, SQL or REST APIs⁵.

Example from vendor pages: AVEVA describes the AVEVA PI System as an integrated portfolio of solutions that lets industrial operations collect, cleanse, store, enrich and visualise real-time operations data², and describes its software as open and agnostic¹. This is the vendor's own description.

2. Time-series storage at scale

A time series database (TSDB) is software optimised for handling time series data, which is a sequence of data points indexed in time order⁶. Because ingestion rates are high and the data is sequential, TSDBs rely heavily on specialised compression to manage storage⁶. Historians are a specialised form of TSDB with industrial connectors, while general-purpose TSDBs are often used in IT-led and cloud architectures.

3. Context

Raw tags rarely mean much to anyone outside the control room. Contextualisation maps tags to assets, units, batches, products and events, often using an asset hierarchy aligned with ISA-95. This is where most of the engineering effort goes, and where DataOps tools position themselves.

Examples from vendor pages: PTC says ThingWorx combines data from machines, systems and enterprise applications so that operations can be understood in context³. Cognite's site reports an IDC MarketScape recognition in the Industrial DataOps Platforms category⁴; this is a vendor-reported statement and we have not read the underlying report.

4. Enterprise analytics and the lake

A data lake is a repository that stores data in its natural, raw format, usually as objects or files⁷. It can hold structured data such as relational tables, semi-structured data such as CSV, logs, XML and JSON, unstructured data such as emails, documents and PDFs, and binary data such as images, audio and video⁷. Lakes and warehouses let data scientists combine process data with quality, maintenance and business data. Without the context layer, however, they quickly become hard to use.

Common architectures

• Historian-centric: site historians feed an enterprise historian; analytics tools connect to it. Mature and familiar to engineers.
• Hub and spoke via a unified namespace: edge gateways publish contextualised data to a broker and consumers subscribe. Flexible, but needs strong governance of the namespace.
• Cloud lakehouse: data replicated from historians and other systems into cloud storage for enterprise analytics and machine learning.

Most real companies run a hybrid: historians remain the system of record for operations, with selected, contextualised data flowing upward.

Questions to ask in selection

• Connectivity: which control systems, protocols and existing historians are supported natively?
• Data fidelity: how are compression, interpolation and data quality flags handled when data moves between layers?
• Context modelling: can asset models be templated and maintained by site engineers?
• Openness: can you export data and models without proprietary lock-in?
• Security: does the architecture respect OT zones and conduits, with data flowing outward rather than inbound connections to control networks?
• Cost model: licensing by tag, by asset, by user or by consumption can change total cost a great deal at scale.

Choosing

• Map which layers you already have.
• Define two or three priority use cases.
• Test with your own data during a proof of concept.
• Check integration with control systems and IT.

Governance makes or breaks it

Assign data owners for each site and asset class, agree naming standards and units, and publish a catalogue of what exists. Measure adoption: how many decisions are taken using the platform, not just how many tags it holds. Historians are used across many industries, for functions such as supervisory control, performance monitoring and quality assurance, and more recently for machine learning that learns from large volumes of historical data⁵. Those uses only materialise when people trust the data.

Starting small

Pick one value case, such as energy per unit or a recurring quality problem, and build the full chain from sensor to decision for that case. Then reuse the model and the pipeline for the next. That approach reveals data-quality problems early and creates internal champions.

Skills

Successful platforms combine process engineers who understand what the data mean with data engineers who build reliable pipelines. Budget for both, and give site engineers simple tools to build their own trends and reports. Publish a short guide to the platform so new users can find data quickly.

A short reference architecture

For a mid-sized multi-site company, a pragmatic pattern is: a historian or edge gateway at each site collecting from control systems; an asset model maintained centrally but edited by site engineers; outbound-only replication of selected, contextualised data to an enterprise store; and analytics tools that read from that store. Data flows outward through firewalled conduits, which respects OT security zones. Each site keeps local data for operations even if the wide-area link fails.

Pitfalls seen in practice

• Copying everything to the cloud without a use case, creating storage costs and little value.
• Losing fidelity by aggregating data too early, so later analyses cannot see short events.
• Ignoring time zones and clocks: unsynchronised timestamps make cross-system analysis unreliable.
• No feedback to operations: insights that never return to the control room or the maintenance planner.

Key takeaways

• Identify the layer you need before comparing vendors.
• Openness avoids lock-in.
• Prove value with your own data.

Frequently asked questions

Do we still need a historian if we have a cloud data lake?

Usually yes. Historians are optimised for high-rate process data and operational use, while lakes serve enterprise analytics.

What is the biggest hidden cost?

Contextualisation and data governance, which require sustained engineering effort.

Which vendor should we pick?

This page does not recommend vendors. Start from the layer and use case, then compare several suppliers against the criteria above using your own data.

Sources

Every factual statement marked with a number links to the source below. Unnumbered practical guidance is editorial advice. Sources were retrieved on 24 October 2026; check the publisher for later revisions. Wikipedia pages are used as secondary references and summarised in our own words (Wikipedia text is licensed CC BY-SA 4.0; any short quotation is marked and attributed); vendor pages are cited only to show what a vendor says about itself. Photo credits and licences are on the image credits page.

1. AVEVA (vendor site, accessed 24 Oct 2026) aveva.com
2. AVEVA PI System (vendor page, accessed 24 Oct 2026) osisoft.com
3. PTC ThingWorx (vendor page, accessed 24 Oct 2026) ptc.com
4. Cognite (vendor site, accessed 24 Oct 2026) cognite.com
5. Operational historian (Wikipedia) en.wikipedia.org
6. Time series database (Wikipedia) en.wikipedia.org
7. Data lake (Wikipedia) en.wikipedia.org