For many manufacturers, the challenge is no longer gaining access to operational data. They already have years, and often decades, of it.

Much of that history sits in AVEVA PI.

PI has become a foundational part of the industrial data landscape, particularly in process manufacturing and other asset-intensive industries. Plants have spent years connecting DCS systems, SCADA platforms, PLCs, analyzers, utilities, and other operational sources into the PI Data Archive, creating a valuable historical record of plant performance.

That investment should not be treated as something to replace simply because the surrounding architecture is changing. What is changing is the role PI needs to play.

As manufacturers invest in enterprise analytics, AI, Industrial DataOps, Unified Namespace architectures, and cloud data platforms, PI increasingly becomes one component within a broader industrial data foundation. Its history may need to be combined with live operational state, MES and ERP context, maintenance records, quality data, and equipment information. Different consumers may also need the same underlying data in very different forms.

The architectural question is therefore not simply how to get data out of PI. It is how to preserve what PI already does well, understand how much context already exists around that data, and decide what additional capabilities should be built around it.

Two Starting Points for PI Modernization

Most PI environments fall somewhere between two broad patterns.

In the first, PI is primarily a historian. The Data Archive contains large volumes of reliable time-series data, but relatively little reusable operational context has been modeled in PI Asset Framework.

In the second, PI AF has been developed extensively. Asset hierarchies, templates, calculated attributes, analyses, Event Frames, and operational logic may already encode a significant amount of engineering knowledge.

These are very different data foundations.

In a historian-focused environment, much of the value sits in the historical measurements themselves. In a mature AF environment, PI also contains the structure and operational context needed to interpret those measurements.

That difference should shape how Industrial DataOps, the Unified Namespace, enterprise data platforms, and AI build on the PI foundation.

When PI Is Primarily a Historian

A manufacturer may have tens or hundreds of thousands of PI tags representing years of production history. The underlying data may be excellent, but outside PI it can still look like:

TT_4711.PV
P101_SPEED
FIC_203.OUT
XV404.STATE

A control engineer who knows the plant may understand those tags immediately. An enterprise analytics platform or AI system generally cannot.

To make the data reusable, additional context is needed. A temperature value may need to be associated with the site and area where it originated, the equipment and process it relates to, its engineering unit, and potentially the product, batch, work order, or equipment state that was active when the measurement was recorded.

This is where Industrial DataOps adds value.

The DataOps layer can map historian tags to stable asset identities, normalize names and engineering units, apply common information models, validate the result, and combine PI measurements with information from MES, ERP, CMMS, LIMS, or other systems.

A PI record might begin as:

Tag: TT4711
Timestamp: 10:42:31
Value: 82.4

After contextualization, the same measurement could become:

{
 "site": "Plant01",
 "area": "Reaction",
 "equipment": "Reactor04",
 "measurement": "ProductTemperature",
 "value": 82.4,
 "unit": "degC",
 "batch": "Batch4711",
 "product": "ProductA",
 "operatingMode": "Production",
 "timestamp": "..."
}

The measurement has not changed. What has changed is how much meaning is attached to it.

That matters because analytics and AI rarely need isolated signals. They need measurements connected to the operational conditions in which those measurements were produced.

PI can therefore remain the authoritative source for high-resolution process history, operational trending, and long-term time-series data, while Industrial DataOps prepares that history for broader use.

For analytical workloads, that may include creating one-minute averages, batch-aligned process windows, event-based datasets, statistical features, or production-cycle summaries rather than moving every raw historian sample into another platform.

The same contextualization can also support operational consumers.

Selected current state, significant changes, and meaningful events can be made available through a Unified Namespace without forcing every application to query PI directly and reconstruct the meaning of individual tags.

In this scenario, DataOps adds much of the reusable context that the historian itself does not provide.

When PI AF Already Carries Operational Context

The second scenario starts from a richer foundation.

Some manufacturers have spent years developing PI Asset Framework alongside the Data Archive. Their AF environments may already contain standardized equipment templates, asset hierarchies, calculated attributes, analyses, Event Frames, unit conversions, and operational logic.

In these environments, PI is doing considerably more than preserving time-series history. It already provides part of the structure and engineering context required to interpret that history.

Consider an AF hierarchy such as:

Enterprise
└── Site
     └── Area
          └── Production Unit
               └── Pump
                    ├── Speed
                    ├── Flow
                    ├── Pressure
                    └── Operating State

If that structure has already been modeled, governed, and maintained in PI AF, there is little value in recreating it from scratch elsewhere.

The role of Industrial DataOps therefore changes. Instead of building all of the context around relatively raw historian tags, it can reuse the asset identities, hierarchies, attributes, calculations, and events already available in AF, then extend that context with information from other systems.

PI AF might define Pump P101, its place in the plant hierarchy, its process measurements, operating state, and runtime calculations. MES might provide the work order, batch, product, or production state associated with it. CMMS may contain maintenance history and previous failures, while ERP provides material, planning, or cost information.

The architecture becomes one of composition rather than reconstruction.

For predictive maintenance, that composition might combine PI process conditions and operating state with maintenance history and failure records from CMMS. For quality prediction, it might combine process measurements with recipe information, batch context, raw material lots, and laboratory results. An AI agent investigating poor equipment performance may need PI history, production context, current state, and maintenance records together.

The objective is not to make PI, MES, ERP, CMMS, or the DataOps platform the single master for every piece of industrial information. Each system should continue to manage the information for which it is authoritative, while DataOps composes those sources when a broader operational view is required.

This matters especially in mature AF environments because years of engineering effort may already be embedded in templates, asset models, calculations, and event definitions. Introducing a parallel representation can create another model that must be governed and synchronized.

The same principle applies to operational logic.

PI AF may contain analyses, Event Frames, notifications, and detection logic closely tied to the historian and maintained by the engineers who understand the process. Those capabilities do not need to be moved simply because a new data platform or UNS has been introduced.

If PI already detects that a compressor has entered a surge condition, there may be little value in rebuilding the same detection logic elsewhere just so another application can respond to it. The result can instead be exposed as an operational event, contextualized where necessary, and distributed to the consumers that need it.

Industrial operations are not represented only by continuous measurements. They are also shaped by startups, shutdowns, trips, grade changes, batch transitions, quality deviations, equipment failures, and maintenance interventions. Where PI AF Event Frames already capture these episodes, the modern architecture should reuse them.

DataOps does not need to recreate the intelligence already embedded in PI. It needs to help that intelligence participate in the broader industrial data architecture.

‍

Extending PI Into the Broader Data Architecture

Once the role of PI is understood, the wider pattern becomes much clearer.

PI contributes process history and, where AF is mature, operational context. MES, ERP, CMMS, LIMS, and other systems contribute the information for which they are authoritative. Industrial DataOps maps identities across these sources, adds or reuses context, applies common models, validates the result, and creates information that can be consumed more consistently.

From there, the same foundation can support two complementary destinations.

The enterprise data platform supports analytical workloads that need historical depth, cross-source datasets, fleet-level analysis, model training, optimization, and AI.

The Unified Namespace serves the live operational architecture. It makes selected current state, meaningful changes, and events available through publish/subscribe so applications can consume them without being tightly coupled to PI or the other source systems.

The important point is not that every piece of PI data should go to both destinations. Industrial DataOps provides the engineering layer that decides what information is useful and prepares it appropriately.

Publishing PI Information Into the Unified Namespace

Consider a PI tag such as P101.DischargePressure.

Publishing that tag directly into MQTT may make it easier to access, but it does not necessarily make it easier to understand. A consumer still needs to know what P101 represents, where the equipment is located, what the measurement means, which engineering unit applies, and how the signal relates to the broader operational model.

Before publishing it into the UNS, DataOps can resolve the asset identity, reuse any available AF context, normalize the unit, map the measurement into a common information model, and validate the payload.

The resulting representation might look like:

{
 "assetId": "P101",
 "operatingState": "Running",
 "dischargePressure": 8.2,
 "pressureUnit": "bar",
 "timestamp": "..."
}

The consumer is no longer dealing with an isolated historian tag. It is consuming information that has already been mapped into a consistent operational representation.

The same applies to events. If PI AF detects a compressor surge, trip, or other meaningful condition, that result can be published as an operational event rather than requiring every downstream system to reproduce the detection logic.

The goal is not to mirror PI inside the Unified Namespace. PI should continue retaining detailed process history. The UNS should expose the current state, events, and contextualized measurements that live consumers actually need.

Avoid Rebuilding PI Somewhere Else

This separation of responsibilities helps avoid two common modernization mistakes.

The first is turning the Unified Namespace into another historian.

PI may contain measurements sampled every second or faster. That does not mean every sample should flow through MQTT. High-frequency historical retention remains a historian responsibility. The UNS should focus on useful operational state and changes.

The second mistake is copying every PI tag into a cloud data lake or lakehouse and assuming the industrial data problem has been solved.

Moving signals such as TT1001, P101_AMPS, and FIC221_PV into a centralized platform makes them easier to access, but it does not necessarily make them easier to understand or use.

The value appears when those signals are connected to stable equipment identities, process context, operating state, production information, maintenance history, and other relevant operational knowledge.

That is the difference between moving industrial data and engineering it for use.

A modern architecture should therefore avoid reproducing PI wholesale in another technology. It should preserve PI where it provides value, reuse the context and logic that already exist, and distribute only the information required by other parts of the architecture.

Let PI Maturity Determine the Modernization Strategy

The modernization path ultimately comes back to the two starting points.

If PI is primarily a historian, Industrial DataOps will need to perform more of the asset mapping, contextualization, transformation, and cross-source composition required to make that history reusable.

If PI AF is mature, much of the operational structure may already exist. In that case, DataOps should reuse the identities, hierarchies, calculations, and events already encoded in AF, then extend them with context from MES, ERP, CMMS, LIMS, and other systems.

That distinction can prevent a significant amount of unnecessary reengineering.

It also provides a better starting point for AI initiatives.

Instead of beginning with, “How do we get all of our data out of PI?”, start with a more useful question:

What operational knowledge do we already have, and what additional context does this use case require?

You may already have decades of process history, equipment hierarchies, standardized templates, calculations, and operational events. The missing information may sit elsewhere: production context in MES, material information in ERP, maintenance history in CMMS, laboratory results in LIMS, or engineering information in other systems.

Industrial DataOps connects those pieces into information that can be reliably consumed by applications, analytics, and AI.

Modernizing Around PI, Not Replacing It

Manufacturers have invested heavily in PI because acquiring and preserving reliable industrial data is difficult. The emergence of cloud data platforms, Unified Namespace architectures, knowledge graphs, and AI does not make that investment obsolete. It changes how that investment can be used.

The PI Data Archive can continue to provide trusted, high-fidelity process history. Where PI Asset Framework has been extensively implemented, it can continue to provide asset structures, calculations, events, and operational knowledge maintained close to the plant.

Industrial DataOps builds around that foundation by connecting PI with other operational and enterprise systems, adding or extending context, and making the resulting information available to live and analytical consumers.

For organizations using PI mainly as a historian, that means turning high-quality time series into contextualized operational data. For organizations with mature PI AF implementations, it means building on the context and engineering knowledge that already exist rather than recreating them elsewhere.

In both cases, the objective is the same: preserve what PI already does well while extending its value into the broader industrial data architecture.

PI remains an important historical foundation, but its information can now participate in live operational architectures, enterprise analytics, and AI without requiring every consumer to understand PI tags, structures, and interfaces directly.

That is how PI evolves from being simply the place where historical process data lives into an important component of a broader industrial data and AI foundation.

‍