What Is the AVEVA PI System? Architecture, Components and Use Cases

Meta description: Understand the AVEVA PI System: PI Data Archive, PI AF, PI Vision and PI Web API. Learn data flows, key use cases, misconceptions, and roles.

The AVEVA PI System is an operational data platform for collecting, storing, modelling, contextualising and delivering time‑series data from industrial assets and processes. It addresses the need to keep high‑frequency operational signals usable for operations and engineering (not just for long‑term reporting) and to manage many heterogeneous, evolving data sources.

This guide explains the PI System at a “fundamentals plus” level: what it is, how it fits together, typical data flows, how it differs from traditional databases, common misconceptions, and how teams usually divide responsibilities. If you’re planning or revisiting a design, read Designing a Scalable and Resilient PI System Architecture.

Core components and purpose

A PI deployment can include many services, but four components appear in almost every design: PI Data Archive, PI AF, PI Vision and PI Web API. Understanding their boundaries helps with design, troubleshooting and role clarity.

PI Data Archive — time‑series engine

Stores time‑stamped values (events) for PI points (tags).
Accepts values from interfaces/adapters/connectors.
Provides efficient long‑term storage and fast retrieval for time‑based queries (trends, summaries, sampled values).
Enforces point‑level security and manages quality metadata.

Operational notes:

Optimised for time‑based retrieval and operational workloads, not ad‑hoc relational joins.
Timestamps, data quality and update behaviour are as important as numeric values.
Point configuration (scaling, compression, exceptions, data type, scan class) affects performance and fidelity.

If you’re new to ingestion, start with How Data Gets Into the PI System: Interfaces, Adapters, and MQTT.

PI AF (Asset Framework) — context, modelling and calculations

Provides asset models, hierarchies, templates, attributes, event frames and relationships that turn raw signals into meaningful information.
Typical system‑of‑record responsibilities: asset templates, naming standards, units, reusable calculations (AF analyses) and event frames.
Governance (templates, naming and ownership) is essential to scale; without it, PI becomes a tag dump.

PI Vision — visualisation for operations

The common “glass to the process” for trends, dashboards and operational displays.
Works well with AF context (element/attribute searches and substitutions) to deliver cross‑area visibility and historical trending.

Operational notes:

Complementary to HMI/SCADA; not a replacement for control system HMIs.
Poorly designed displays (too many symbols, high update rates, heavy searches) can degrade performance.
Using AF as the primary data source encourages consistent modelling.

PI Web API — modern access for apps and integration

Provides HTTP/REST access to PI Data Archive and AF for custom apps, integrations and analytics.
Common uses: mobile tools, enterprise integration, feeding analytics platforms, and replacing older client libraries in some scenarios.

Practical considerations:

PI Web API exposes PI data—identity, authorisation and network placement are critical.
Treat it as a shared service: consider rate limits, caching and consistent query design.
Align deployment and authentication with your security team.

Typical end‑to‑end data flows

Rather than a single path, PI supports repeatable flows that architects and admins encounter regularly.

Real‑time collection from control systems into PI Data Archive

Signals originate in PLC/DCS/SCADA or concentrators.
A data collection component reads values and sends them to PI Data Archive as PI points with timestamps and quality.
Consumers access data via PI Vision, client tools or APIs.

Design questions: buffering during outages, source vs PI standardisation of naming, expected scan rates and latency. See How Data Gets Into the PI System: Interfaces, Adapters, and MQTT.

Contextualisation and modelling in AF

Tags in the Data Archive are mapped to AF attributes on asset elements.
Templates standardise mappings across similar assets.
AF analyses and roll‑ups produce derived attributes and KPIs.

This separation of raw signals (archive) and meaning (AF) lets you query across assets (e.g. “show flow for all pumps in this area”) without encoding hierarchy into tag names.

Visualisation and operational decision support

PI Vision displays use AF searches and attribute substitution.
Operators and engineers rely on trends, comparisons and roll‑ups for shift handovers, troubleshooting and post‑event reviews.
Treat key displays like controlled assets: versioning, owners and performance checks.

Integrations to enterprise systems and analytics

Apps and analytics platforms consume PI data via PI Web API or other methods.
Consumers usually need AF context as much as raw values.
Undefined ownership of definitions (units, asset boundaries, KPI formulas) leads to conflicting dashboards; define owners early.

For security patterns supporting these flows, see Securing the AVEVA PI System in Modern Enterprise Environments.

How PI differs from traditional databases

PI is often compared to relational databases; the comparison matters only when focused on workload and behaviour.

Time‑series‑first storage and retrieval

Relational DBs excel at structured records and joins. PI Data Archive is engineered for fast write/retrieval of time‑stamped values, efficient representation of changing signals (compression/exception) and common industrial queries (“What was it at 10:03?”, “Average last hour?”, “When did it cross a limit?”).
Use query patterns that match PI’s strengths for analytics.

Data quality and timestamp semantics are first‑class

Instrument failures, comms loss and manual overrides are normal; PI records quality and timestamp semantics as core metadata.
Consumers must understand quality flags and the impact of timestamp alignment and sampling on derived KPIs.

Separation of data and context

Data Archive: time‑series storage and point configuration.
AF: meaning, hierarchy, reusable calculations, event frames and naming standards.
Blurring these layers (for example, encoding hierarchy in tag names) makes systems brittle.

Operational performance and predictability

PI deployments succeed when ingestion, queries and failure behaviour are predictable. Capacity planning, buffering and health monitoring are recurring priorities. See Keeping PI Fast, Stable, and Predictable at Scale.

Common misconceptions

“PI is just a tag database” — The real value is context (AF), standardisation and reuse across roles. Without AF, PI tends to become a naming contest.
“PI replaces the control system historian/HMI” — PI complements control system tools by providing cross‑area visibility, longer retention and easier integration; it is not an HMI replacement.
“We can push everything into PI and sort it out later” — Rapid ingestion is possible, but governance debt compounds. Basic rules (tag standards, AF templates, ownership and onboarding checklists) prevent long‑term pain.
“PI is a data lake” — PI is optimised for operational time‑series and related context. Integrate with fit‑for‑purpose systems for documents, ERP records and unstructured data.
“PI Web API is the model” — PI Web API is an access method; AF is the model and Data Archive is the historian.

Deployment patterns: on‑prem vs AVEVA CONNECT (high level)

On‑prem PI System

Chosen when sites must operate through WAN outages, control networks are segmented, data sovereignty is required or local OT support exists.
You are responsible for patching, backups, failover testing, identity integration and capacity planning.
Read Designing a Scalable and Resilient PI System Architecture and Running the PI System Day-to-Day: A PI Admin’s Playbook.

AVEVA CONNECT (cloud services)

Considered when enterprise teams need centralised, easier access and cloud‑first integration.
Cloud connectivity does not remove the need for modelling, security design and operational ownership; it shifts responsibilities and boundary controls.

Roles and responsibilities

Clear roles help PI succeed. Individuals may cover multiple responsibilities, but ownership should be explicit.

PI Administrator (platform operations)

Owns platform health: services, backups, restore tests, patching, monitoring and runbooks.
Coordinates with Windows, virtualisation, storage and network teams. See Running the PI System Day-to-Day: A PI Admin’s Playbook.

PI Engineer / PI System Engineer (design and enablement)

Designs ingestion, point standards and asset modelling.
Handles performance tuning, scaling and project enablement.

OT/IT Architect (architecture and governance)

Defines network zoning, identity, HA/DR patterns, integration boundaries and ownership of AF templates and KPIs. See Securing the AVEVA PI System in Modern Enterprise Environments.

Operations, Maintenance, Process, Reliability and Data teams (consumers and co‑owners)

Operations owns key dashboards and operational definitions.
Reliability owns condition indicators and event definitions.
Process engineers own KPI formulas.
Central data teams consume governed datasets rather than scraping.

Common PI System use cases (with realistic boundaries)

Operational troubleshooting and incident review: rapid trend overlays and cross‑signal correlation with AF context and event frames.
Production and batch visibility: tracking runs, comparing performance between batches and providing shift dashboards from governed definitions.
Asset performance and reliability: condition indicators and abnormal operation detection using consistent asset hierarchies.
Energy and utilities monitoring: normalising consumption, detecting peaks and calculating intensity KPIs across sites.
Enterprise integration and analytics: feeding curated time‑series into analytics tools and providing an operational source of truth for process values.

Avoid using PI as a general enterprise reporting database without respecting time‑series semantics and context. The right pattern is “PI for operational time‑series + integration to fit‑for‑purpose systems”.

Performance, stability and security: essentials

Performance and scale

Keep ingestion predictable with buffering, controlled scan rates and managed backfill.
Govern point creation and client query patterns; treat AF searches and PI Vision design as performance concerns. See Keeping PI Fast, Stable, and Predictable at Scale.

Security

Define identity and access patterns that meet OT and enterprise needs.
Place web‑facing services intentionally and audit who can write data or change definitions (AF templates, analyses, points). See Securing the AVEVA PI System in Modern Enterprise Environments.

Administration practices

Maintain runbooks, backup/restore tests, change control, routine health checks and clear ownership of AF models, displays and onboarding requests. Start with Running the PI System Day-to-Day: A PI Admin’s Playbook.

Getting specialist help

For business‑critical estates, involve specialists for architecture reviews, security design, large migrations or performance investigations—especially when multiple sites share a central platform. External review helps validate resilience and DR assumptions. If hiring, browse PIAdmin.com jobs: https://piadmin.com/jobs.

Recommended PIAdmin.com reading path

Use this progression: architecture → ingestion → performance → security → operations maturity.

What Is the AVEVA PI System? Architecture, Components and Use Cases

What Is the AVEVA PI System? Architecture, Components and Use Cases

Tags