Upgrading and running plant historians, and getting their data out of the plant safely.
We upgrade and run AVEVA PI System and Aspen InfoPlus.21. That includes cleaning up tag and asset models and rebuilding interfaces that fail. We also move reliable time-series data from the plant into analytics platforms without opening a hole in the OT network.
Cohash upgrades and supports plant historians, specifically AVEVA PI System (formerly OSIsoft PI) and Aspen InfoPlus.21 (IP.21).
We rebuild interfaces and connectors and clean up tag naming and asset models. We design DMZ replication and send contextualized data to cloud platforms such as Snowflake, Databricks and Microsoft Fabric. Certified engineers are available onsite at US sites or from nearshore and offshore teams, on contract, contract-to-hire or permanent terms.
you probably need this if
When the network blips, interfaces lose data, and nobody sees the gaps until they turn up in reports weeks later.
Every site names tags differently, so any cross-site question starts with somebody's spreadsheet.
Data scientists ask for a direct connection into the plant historian.
terms on this pageConnectordefinitionThe integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.explained in a field note →
no date yetOSIsoft PI System is now AVEVA PI SystemOSIsoft appears among AVEVA's heritage brands. The product line is now AVEVA PI System, with PI Server doing storage and enrichment.source ↗
no date yetAVEVA is part of Schneider ElectricSchneider Electric completed its acquisition of AVEVA, AVEVA states. AVEVA is now a member of the Schneider Electric group.source ↗
no date yetPI System delivered through AVEVA PI Data InfrastructurePI Server, AVEVA Edge Data Store and the CONNECT industrial intelligence platform are the core, with PI Interfaces, PI Connectors and AVEVA Adapters around them. AVEVA says it's moving to subscription licensing.source ↗
no date yetAspenTech is part of EmersonAspenTech states it is now part of Emerson. Aspen InfoPlus.21 remains its process historian, with aspenONE Process Explorer for visualization.source ↗
the story · aveva pi & aspentech ip.21 estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your AVEVA PI & AspenTech IP.21 estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · aveva pi & aspentech ip.21 estate3 open
openWhen the network blips, interfaces lose data, and nobody sees the gaps until they turn up in reports weeks later.
recurringEvery site names tags differently, so any cross-site question starts with somebody's spreadsheet.
blockedData scientists ask for a direct connection into the plant historian.
exposure
Historian upgrades and health…Interface and connector rebuildsAsset models and tag hygieneDMZ and cloud data pathsMoves between historiansIndustrial data staffing
CC&B
startrehearsehandover
Historian health check
Model and naming standard
Rebuild and replicate
Handover
we are here
ready to hand over
The data team gets consistent asset names across all nine plants, and the OT team still…
Leadership chooses between migration and federation on a costed list, and the refinery's…
Interface inventory with buffering, failover and owner per node
Collection gap report by site with root cause for each gap
chapter 01 · where it hurts
Why teams reach out
When the network blips, interfaces lose data, and nobody sees the gaps until they turn up in reports weeks later.
Every site names tags differently, so any cross-site question starts with somebody's spreadsheet.
Data scientists ask for a direct connection into the plant historian.
chapter 02 · what we change
How we solve it
Historian upgrades and health checks
Interface and connector rebuilds
Asset models and tag hygiene
DMZ and cloud data paths
Moves between historians
Industrial data staffing
chapter 03 · how it runs
Our approach
Historian health check
Model and naming standard
Rebuild and replicate
Handover
chapter 04 · where you end up
What changes
The data team gets consistent asset names across all nine plants, and the OT team still hasn't opened a single inbound port.
Leadership chooses between migration and federation on a costed list, and the refinery's operators keep their displays until a decision is made.
Interface inventory with buffering, failover and owner per node
Collection gap report by site with root cause for each gap
what we do
Our AVEVA PI & AspenTech IP.21 work
6 kinds of AVEVA PI & AspenTech IP.21 work, each run by engineers who have done it on live tenants.
PI Server and IP.21 upgrades planned around archive sizes, interface nodes and buffering, with a health check of collection gaps, stale tags and failed interfaces first.
PI Interfaces, PI Connectors and AVEVA Adapters, or IP.21 collection, rebuilt with buffering and failover so a network blip doesn't leave a hole in the record.
Tag naming standards, unit and descriptor clean-up, and asset hierarchies that let an engineer find "Compressor 3 discharge pressure" without knowing the tag name.
Site-to-DMZ replication, one-way data flows and feeds into Snowflake, Databricks or Microsoft Fabric that keep the plant network closed to inbound traffic.
Migrations between PI and IP.21, or consolidation of several site historians, with history backfilled and reconciled tag by tag.
PI System administrators, IP.21 specialists and industrial data engineers, onsite at US sites or remote, on contract, contract-to-hire or permanent terms.
capability 01 / 06in production
CC&B
Historian upgrades and health checks
PI Server and IP.21 upgrades planned around archive sizes, interface nodes and buffering, with a health check of collection gaps, stale tags and failed interfaces first.
PI Interfaces, PI Connectors and AVEVA Adapters, or IP.21 collection, rebuilt with buffering and failover so a network blip doesn't leave a hole in the record.
Tag naming standards, unit and descriptor clean-up, and asset hierarchies that let an engineer find "Compressor 3 discharge pressure" without knowing the tag name.
Site-to-DMZ replication, one-way data flows and feeds into Snowflake, Databricks or Microsoft Fabric that keep the plant network closed to inbound traffic.
PI System administrators, IP.21 specialists and industrial data engineers, onsite at US sites or remote, on contract, contract-to-hire or permanent terms.
AVEVA PI & AspenTech IP.21 situations we walk into
We pieced these together from AVEVA PI & AspenTech IP.21 situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
PI at nine sites, three naming schemes and a cloud analytics push
composite · not a client story
Beforethe situation
Nine plants run PI with three tag naming schemes inherited from past owners. A central data team wants plant data in Databricks, and the OT team refuses any inbound connection.
What we dothe work
We agree one naming and asset standard with process engineers, starting with the equipment the data team needs. A DMZ copy takes replicated data from each site, and the cloud feed runs outbound from the DMZ under its own service identity.
Afterwhere you end up
The data team gets consistent asset names across all nine plants, and the OT team still hasn't opened a single inbound port.
case file 02
An acquired refinery on IP.21 and a company standard on PI
composite · not a client story
Beforethe situation
A company standardized on PI years ago, then acquired a refinery that runs IP.21 with years of history, custom calculations and operator displays built on aspenONE Process Explorer.
What we dothe work
We list what operators and engineers use daily, cost a full move against a federated model and test reading both historians through one asset layer first. History backfill is priced tag by tag before anyone commits.
Afterwhere you end up
Leadership chooses between migration and federation on a costed list, and the refinery's operators keep their displays until a decision is made.
We don't start a step until the last one has produced something you can check.
step 01
Historian health check
We go through interface logs and buffering settings, check archive sizes and stale tag counts, and write up the collection gaps at each site with what caused them.
step 02
Model and naming standard
We agree a tag naming and asset hierarchy standard with process engineers, starting with the units and equipment that analytics teams ask about most.
step 03
Rebuild and replicate
We rebuild interfaces and connectors with buffering and failover. Each site replicates to a historian in the DMZ, and the cloud feed leaves from there, outbound only.
step 04
Handover
Whichever site and central teams will own it get the admin runbooks, the interface inventories and a monthly data quality check.
ai on aveva pi & aspentech ip.21
Where AI fits on AVEVA PI & AspenTech IP.21, and where it needs guardrails.
AVEVA pairs PI System with AVEVA Predictive Analytics and the CONNECT platform, and AVEVA World 2026 included developer sessions on MCP in AVEVA products. AVEVA doesn't yet list a PI System MCP server on its product pages. For historians, the first AI job is usually clean tags and asset models, because agents can't use data nobody can find.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
AVEVA PI & AspenTech IP.21does the work
AVEVA doesn't currently publish an official MCP server, so agents should read from a DMZ copy of the historian through its supported APIs with a read-only identity scoped to approved AF databases, never reach into the control network, and log every query. Writes stay off.
AVEVA Predictive Analytics
AVEVA's predictive analytics use historian data to predict asset failures. Train a model on gappy data and it raises false alarms. So we check tag quality and collection gaps for the assets in scope first.
MCP in AVEVA products
AVEVA World 2026 had a hands-on developer session on MCP within AVEVA products, and Mitsubishi Heavy Industries showed an MCP it built for PI System covering AF, time-series data and event frames. We'd treat these as patterns, not a supported product, until AVEVA publishes one.
Asset models agents can use
Give an agent a raw tag ID and it has nothing to reason about. It needs a name like Compressor 3 discharge pressure. AI can propose AF templates and descriptors from the tag lists, and your process engineers review them.
AI around IP.21 and PI operations
Across PI and Aspen InfoPlus.21 sites, AI summarizes interface logs, flags stale tags and drafts health-check reports. An administrator confirms each finding.
How plant data moves from controllers to the cloud
Control systems feed the site historian through interfaces with local buffering. A DMZ copy holds replicated data, and outbound feeds deliver it with asset context to analytics platforms, so nothing outside reaches into the control network.
01 · Control systems
DCS and PLCsOPC UA · OPC DA · Modbus → Interfaces and adapters · OPC reads
What a AVEVA PI & AspenTech IP.21 engagement leaves behind
These are working documents, written against your configuration, so your team can run them without us.
inventory01
Interface inventory with buffering, failover and owner per node
yours to keep
report02
Collection gap report by site with root cause for each gap
yours to keep
guide03
Tag naming and asset hierarchy standard agreed with process engineers
yours to keep
design04
DMZ replication and outbound cloud feed design
yours to keep
runbook05
Historian upgrade runbook with rehearsal timings
yours to keep
document06
Monthly data quality check the site team can run
yours to keep
talent and delivery · aveva pi & aspentech ip.21
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
AVEVA PI System administrator
PI interfaces and adapters engineer
PI asset model and analytics developer
Aspen InfoPlus.21 engineer
Industrial data engineer (historian to cloud)
due diligence · aveva pi & aspentech ip.21
Questions to ask any partner, including us.
Put these to anyone bidding on your AVEVA PI & AspenTech IP.21 work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you find collection gaps we don't know about yet?
Interfaces tend to fail silently, and the first sign is a report that looks wrong. Interface logs, buffer settings and stale tag counts tell you where the holes are.
Q2
What is your design for getting data to the cloud without inbound access to OT?
A DMZ copy with outbound-only feeds is the pattern most OT teams accept. A design that needs a firewall hole into the control network will stall.
Q3
Who decides tag names and asset hierarchies, and how will you get it agreed?
Naming standards fail when IT writes them alone. Process engineers have to recognize the asset model or nobody will use it.
Q4
How will AVEVA's subscription licensing change what we pay for?
AVEVA says it's moving to subscriptions. What you pay will depend on which components you run and at how many sites, so get the inventory straight before the renewal call.
Q5
What would it cost to backfill history if we move historians?
History backfill, calculation rebuilds and display rework usually cost more than the server move. Ask for the number tag by tag.
01Is OSIsoft PI the same product as AVEVA PI System?
It is. AVEVA bought OSIsoft and sells the PI System under its own name, and AVEVA is now in the Schneider Electric group. Most components kept their PI names, PI Server, PI Vision and PI Interfaces among them, so existing skills and documentation still apply.
02Who owns Aspen InfoPlus.21 now?
AspenTech says it's now part of Emerson. IP.21 is still sold as AspenTech's process historian, with aspenONE Process Explorer for dashboards, and you still take support and licensing questions to AspenTech.
03How do we get historian data to the cloud safely?
Replicate from the site historian to a copy in the DMZ, and send data to the cloud from there. Nothing in the cloud should open a connection into the control network. We design the replication, the outbound feed and the identity it runs under.
04Should we move from IP.21 to PI or the other way?
Only with a reason that pays for it. A move changes interfaces, displays, calculations and user habits at every site. We start with what each site needs from its historian, then cost the move tag by tag, including backfill of history.
05How long does a historian upgrade take?
It depends on the number of interface nodes, archive sizes, custom calculations and how many sites must move together. We inventory interfaces and calculations first and rehearse the server upgrade on a copy before scheduling site windows.
06Can you staff PI administrators or IP.21 specialists?
We do. PI System administrators, IP.21 specialists and industrial data engineers can sit onsite at a US plant, or work remotely from our nearshore and offshore teams in any time zone.
services
Related services
Projects on AVEVA PI & AspenTech IP.21 usually end up touching one of these, so they're worth a look.
