FactoryTalk Historian: When It Is the Right Answer

What FactoryTalk Historian does well, what it costs, why a process historian is not an OEE system, and how to decide what to collect before you license tags you will never query.

FactoryTalk Historian is the OSIsoft PI platform, sold and integrated by Rockwell. It is very good at what it does. The failure mode is not the product. It is buying it to answer a question it was not built for.

What it is genuinely good at

Long-horizon, high-resolution time series. Continuous process values recorded at high resolution and retained for years, with compression that preserves the shape of the signal rather than sampling it away. When you need to look at a temperature trace from eighteen months ago at the resolution it was recorded, this is the category of tool that does it.

Interpolation and time alignment. Tags recorded on different schedules, from different sources, queried together on a common time base. On a process investigation that spans forty signals from three systems, this is the capability that matters and it is genuinely hard to replicate.

Compression that is not lossy in the ways that matter. The swinging-door style compression stores points that define the signal’s shape and discards points that lie on a line between them. The result is dramatic storage reduction with the trace still faithful.

A mature query and analysis ecosystem, including the client tools people in process industries already know.

Swinging-door style compression stores the points that define the signal and discards those that lie on a line between them. Dramatic storage reduction with the trace still faithful.

Where it does not fit

It is not an OEE system. OEE needs states, events, reason codes and shift context: this machine was down, for this long, for this reason, attributed to this shift. A historian stores values against time. You can build state and event logic on top of it, and plants do, and it is consistently more work and less satisfactory than using a tool built for the job.

It is not an MES. No genealogy, no work orders, no electronic batch records.

It is not a reporting tool. It stores and serves data. Turning that into something an operations manager reads every morning is a separate exercise that needs to be scoped and funded.

The question to answer before buying

What decision will this data support, and who makes it?

If that has a specific answer, specify against it. If it does not, you are about to license tags against a hope.

The most expensive failure in this layer is quiet: a historian collecting several thousand tags that no report, dashboard or decision has ever consumed. It runs, it costs licence and infrastructure money every year, and nobody notices because nothing breaks. Audit consumption periodically. A tag nobody has queried in twelve months is a tag to question.

Cost, honestly

Licensing is typically driven by tag count, and the count grows quietly. Beyond the licence:

Server infrastructure, sized for the retention and query load
Storage over the retention horizon
Interfaces and collectors to each data source
Client licences, depending on the tools and the number of users
Someone to own it, which is the recurring cost that decides whether it stays useful

The tag count question deserves attention at design time. “Collect everything, decide later” is an appealing instinct and an expensive one, because the licence and the storage are permanent while the decision to use the data may never arrive.

Getting the data right before it arrives

A historian is downstream of everything else, and it faithfully records whatever it is given.

Tag naming. If the controller exposes N7_12 then that is what the historian holds, and every query and report inherits it. This is the strongest practical argument for getting project structure right before a historian is deployed.

Resolution matched to the signal. Collecting a slow temperature at high frequency wastes capacity. Collecting a fast pressure transient too slowly loses the event you deployed the historian to catch. Set both from what the process does.

Context alongside values. A value without the batch, product, shift or machine state it belongs to is far less useful than it looks. Deciding where that context comes from is part of the design, not something to add later.

Data quality. A sensor reading zero and a sensor that has failed both record as zero unless quality is captured. Investigations built on unqualified data reach confident wrong conclusions.

The position we take

Most plants need AssetCentre before they need Historian. Protecting the code and configuration you already have is a smaller, cheaper, higher-certainty return than collecting data you have not yet decided how to use. See AssetCentre and version control.

If the question is OEE and downtime reasons, buy something built for that. A historian will disappoint everyone involved and cost more.

If the question is process behaviour over long horizons at real resolution, Historian is excellent and worth what it costs.

We are independent of this stack and take no licence margin, so when the honest answer is that a plant does not need it this year, that is the answer.