AVEVA Historian vs PI System: storage, store-and-forward and replication to PI

AVEVA now sells two process historians: AVEVA Historian, the former Wonderware Historian that sits next to System Platform and InTouch HMI, and the PI System from the former OSIsoft. Plants that run one of them, or both, ask how they differ and how data moves between them. This article compares them from AVEVA's own documentation: the AVEVA Historian 2026 guide, the System Platform 2023 R2 SP1 P04 deployment guide, the PI Server 2018 installation guide and the UniInt interface framework 4.7.3. What a process historian does in general: What is a process historian.

1. AVEVA Historian in a System Platform system

AVEVA's deployment guide describes the Historian node as a computer that runs AVEVA Historian on top of Microsoft SQL Server. It stores the historical process data and serves real-time data to System Platform clients such as AVEVA OMI and InTouch HMI. The Historian node needs no Platform object: the Application Object Servers push the attributes configured for historisation to it. Because of its disk and memory load, AVEVA advises that in most cases Historian Server is the only product on that node.

The guide also gives the ports: from System Platform 2023 R2 the default HCAL port is 32565, where earlier versions used 32568, and the REST API port is 32569. Most topologies keep the historical and alarm databases together on the Historian node.

2. How AVEVA Historian stores data

AVEVA Historian uses two kinds of storage. A SQL Server database named Runtime holds the configuration and classic event data. The process data itself, together with alarms and events, replication data and auto-summary data, is written to history blocks: folders of files in AVEVA's own format, each covering a fixed time interval. A server can run a main storage partition for primary data and an auto-summary partition for calculated summaries. Each value is stored with a timestamp and a quality stamp, and Historian keeps both original data and revisions, with a record of how a value was changed.

3. Inside a PI Server

AVEVA's PI Server installation guide describes a PI System as a chain from the data source and its data collector to Data Archive, the PI Asset Framework (PI AF) server and the client tools. AVEVA lists Data Archive, PI AF and PI Notifications Service as the parts of PI Server, with PI Analysis Service as a further server role in the same install kit:

• Data Archive: stores time-series data and routes it in real time through the system.
• PI AF server: models assets and equipment so that time-series data has context.
• PI Analysis Service: runs calculations on PI AF attributes and writes the results to other attributes.
• PI Notifications Service: runs notification rules and sends alerts by email or to a web service.

4. Keeping data through a network outage

Both products buffer at the source, but with different components:

Two details from AVEVA's Historian pages matter on site. IDAS store-and-forward is not available when a failover IDAS is configured, and the store-and-forward path must be a valid local path. For HCAL, AVEVA's sizing example adds 30% to the forwarding bandwidth, and in its time example one hour of stored analog data takes about 47 minutes to forward over a link 30% faster than the normal data rate.

5. Tiers, and moving data from Historian to PI

AVEVA Historian replicates in tiers: a tier-1 historian sends data to a tier-2 historian, a server can be tier 1 and tier 2 at once, and replication can continue to further tiers. Summary replication happens only between tier 1 and tier 2; beyond that, data is replicated as it is. Historian can replicate process data as well as alarms and events.

A PI Server can be the next tier. AVEVA's Historian 2026 guide allows up to three replication server connections in total to PI Server and CONNECT, and needs PI Web API 2021 SP2 (1.16) or later with Open Message Format (OMF) services enabled on the PI side. For plants that already feed PI through the PI Connector for AVEVA Historian, AVEVA's migration steps keep the connector running until replication is verified, with each destination tag name matching the name the connector used, to avoid gaps.

6. Side by side

How TDL approaches it

TDL Industrial Automation is listed in AVEVA's Partner Finder as a System Integrator in the AVEVA Partner Ecosystem. Our historian work so far has been on FactoryTalk Historian at the Vinh Hoan FeedOne aquafeed plant and on AVEVA System Platform with historian and reports at Samsung SEHC. Before choosing a historian we list who reads the data and from where: operators on the same System Platform system, or engineers and managers across several sites. More on historian services: SCADA, HMI and plant data integration.