How the PI System Is Used Across Industries

Meta description: Learn how the PI System serves as an industrial data historian across utilities, manufacturing, pharma and oil & gas—plus ESG reporting and AI-ready architectures.

PI System: from plant data to decisions

The AVEVA PI System is widely deployed as an industrial data historian because it addresses a common problem: operational data is high-volume, high-frequency, time-series and comes from many control and monitoring technologies (PLC/DCS/SCADA/BMS/lab systems/IoT gateways). When well-run, PI becomes the operational “system of record” for time-series process and asset data—supporting operators, engineers, reliability, production planning, quality, energy management and enterprise analytics.

This page summarises typical PI uses, what “good” looks like, and how architectures diverge across utilities, manufacturing, oil & gas and pharma—plus considerations for ESG, analytics and selection.

Why PI is industry-agnostic

Time-series fundamentals behave the same across sectors Whether turbine vibration, batch temperature, breaker status or cleanroom pressure, the technical patterns repeat:

• Fast analogue changes mixed with slower state changes
• Large tag counts and long retention windows
• Data quality issues (missing, bad or out-of-order values)
• Event context needed to make raw numbers meaningful
• The need to keep collection independent from reporting/analytics

PI’s data model and services are designed around these realities.

Separation of concerns: collection, storage, consumption A robust PI estate separates:

• Ingestion: protocols, buffering, edge concerns
• Storage: retention, compression, scaling, availability, backup/restore
• Consumption: trending, dashboards, calculations, exports, APIs

This separation enables the same core historian to support different operating models and regulatory needs.

For collection mechanics and standards, see How Data Gets Into the PI System: Interfaces, Adapters, and MQTT. For scalable design, see Designing a Scalable and Resilient PI System Architecture.

OT-first or IT-led — PI fits both Some organisations treat PI as an OT platform with controlled upward sharing; others treat it as a corporate data service with strict enterprise controls. PI supports both approaches but the architecture and security stance differ.

Common cross-cutting use cases

Operations visibility and shift handover

• Control-room trending, situational awareness and “what changed?” reviews
• Automated shift logs and fleet/multi-site dashboards
  Governance and standard visualisation conventions are essential.

Reliability and maintenance

• Condition monitoring (vibration, temperature, pressures, run hours)
• Identifying bad actors and chronic issues; triggering work processes
  This depends on strong asset context.

Energy management and cost allocation

• Site energy balances, steam/air/chilled water performance, KPIs (kWh/tonne, kWh/batch)
  Energy use cases often expose data quality issues quickly and link to ESG reporting.

Quality and process improvement

• Golden-batch comparisons, deviation analysis, SPC-style monitoring

Incident investigation and compliance evidence

• Demonstrating conditions were within limits, traceability for audits, evidence packs from trends/events/calculations Operational stability and predictable performance are prerequisites (see Keeping PI Fast, Stable, and Predictable at Scale).

Industry scenarios

The summaries below focus on commonalities, distinctions and practical planning points.

Utilities: grid, generation, water and wastewater Data sources

• SCADA (substations, feeders, reservoirs, pumping stations), DCS/PLC in plants, protection systems, power-quality meters, environmental monitoring, asset condition data (transformer DGA, vibration)

Use cases

• Fleet performance, outage/event investigation, water quality and permit reporting, operational KPIs, resilience reporting

Operational realities

• Distributed buffering is essential for remote sites and intermittent comms
• Time synchronisation is mandatory for event ordering and disturbance analysis
• Multi-tenancy/segmentation may be required for regions, contractors or regulated entities

Architecture patterns

• Central Data Archive/cluster with robust remote collection
• DMZs for enterprise sharing and read-only replicas or curated data products for wider use

Manufacturing: discrete, continuous and hybrid Data sources

• PLC/HMI/SCADA across lines, DCS for continuous processes, MES/batch systems, weigh scales, labs, building services

Use cases

• OEE and downtime analysis, throughput and constraint tracking, recipe/setpoint monitoring, yield/waste reduction, utilities optimisation

Operational realities

• Naming conventions and AF templates are critical to avoid “one-off” dashboards
• High-frequency data can overload visualisation tools without governance
• Engineering change is constant; lifecycle processes must manage churn

Architecture patterns

• Site historians feeding a corporate aggregation layer, standardised AF libraries, segregated engineering/test environments

See Running the PI System Day-to-Day: A PI Admin’s Playbook for day-to-day governance.

Oil and gas: upstream, midstream, downstream Data sources

• DCS/PLC/SCADA across wells, pipelines, terminals and refineries; flow computers; rotating equipment monitors; analysers; tank gauging

Use cases

• Production optimisation, pipeline monitoring and transient analysis, refinery optimisation, integrity management, commercial and regulatory reporting

Operational realities

• Connectivity varies (offshore/remote); edge buffering and resilient reconnection are required
• Cyber boundaries are strict: DMZs, unidirectional gateways and controlled ports are common
• Data trust (reconciliation, provenance, quality flags) becomes a business concern

Architecture patterns

• Clear separation between control and corporate networks, regional historians feeding corporate layer, curated exports to analytics rather than broad PI access

See Securing the AVEVA PI System in Modern Enterprise Environments for aligning PI with modern security expectations. Also DMZ and zone-based architectures for PI System deployments.

Pharma: regulated manufacturing, quality and validation Data sources

• DCS/PLC, batch execution systems, environmental monitoring (cleanrooms, cold chain), utilities critical to quality (WFI, clean steam), lab/LIMS (often integrated at reporting stage)

Use cases

• Batch review support, deviation investigations, environmental monitoring, utilities monitoring, inputs to CPV/process verification

Operational realities

• Strict change control, traceability and documented data flows are required for audits
• Be explicit about PI’s role (monitoring/decision support vs official batch record)

Pharma benefits from disciplined operational processes and predictable performance (see Running the PI System Day-to-Day: A PI Admin’s Playbook and Keeping PI Fast, Stable, and Predictable at Scale).

ESG and compliance reporting

What PI provides

• Traceable, time-aligned operational measurements: energy by source, fuel use and flaring proxies, process-emission proxies, water abstraction/discharge/quality, asset runtime and load profiles

What PI is not

• PI is not a policy engine. ESG KPIs also need organisational boundaries, accounting rules, data certification and versioned methodologies.

Practical pattern

• PI supplies measurements and provenance; curated outputs feed ESG platforms or data warehouses for aggregation and assurance.

Controls that make ESG credible

• Define data ownership; record units and basis; use consistent aggregation logic; build audit-friendly calculations with change control; monitor data quality

Analytics and AI platforms: where PI fits (and where not to stretch it)

Integration patterns

• Curated exports for governance, near-real-time feeds for operational analytics, context-first modelling using AF, publish data products (approved signals/KPIs)

Practical considerations

• Isolate analytics workloads to avoid degrading historian responsiveness
• Align security with enterprise IAM and least privilege
• Maintain semantic consistency so AI models use agreed definitions

See Securing the AVEVA PI System in Modern Enterprise Environments.

Selecting an architecture: what changes by industry

The best architecture fits operational constraints, support model and risk appetite. Use Designing a Scalable and Resilient PI System Architecture as the baseline, then apply these industry-specific choices.

1. Availability and recovery expectations

• Is PI used for real-time decisions or reporting? What data-loss window is tolerable? What does “restore” include (ingestion only, or dashboards/analytics too)?

1. Network topology and trust zones

• Remote sites require edge buffering; strict OT/IT segmentation favours DMZ patterns; contractor access needs tight role design and auditing

See How Data Gets Into the PI System: Interfaces, Adapters, and MQTT and Securing the AVEVA PI System in Modern Enterprise Environments.

1. Data volume, tag strategy and performance engineering

• Refineries: high tag counts and update rates
• Discrete manufacturing: many state/event tags
• Utilities: distributed sources and long retention
• Pharma: lower tag counts but heavier governance

For performance guidance, see Keeping PI Fast, Stable, and Predictable at Scale.

1. Context model and lifecycle management

• Asset models, naming conventions and onboarding standards often deliver more value than raw historian tuning
• Manufacturing and pharma benefit strongly from AF template discipline; utilities from fleet/region hierarchies; oil & gas from clear asset separation

1. Consumption model

• Operator sites need fast, consistent displays; engineering teams need safe ad hoc analysis; enterprise analytics need governed access and lineage

Getting help

Involve specialists when you face multi-site architecture, OT/IT security boundaries, or performance issues affecting operations. External reviews can standardise naming, AF templates and onboarding across plants. Browse vetted options at https://piadmin.com/directory.

Common pitfalls by industry (and how to avoid them)

Utilities

• Ignore remote comms at your peril → design for buffering/backfill
• Inconsistent timestamps → enforce time sync and monitor drift
• Mix operational and enterprise workloads → establish controlled sharing

Manufacturing

• Tag sprawl → enforce naming and AF templates early
• Ungoverned dashboards → set display/performance standards
• Underestimate change rate → formalise tag/asset lifecycle

Oil & gas

• Flattening everything into a tag list → model assets and envelopes explicitly
• Late security consideration → align architecture with zones early
• Direct enterprise access to OT data → prefer curated products

Pharma

• Undefined validated scope → state intended use and controls
• Weak audit trail for config changes → formalise change control and peer review
• Treating PI as the official record → make system boundaries explicit