Running PI and Aspen InfoPlus.21 Together: Federate or Consolidate?
Most large process operators run more than one historian. Rarely by design — more often through acquisition, joint ventures, or decades of sites making independent and locally sensible decisions. Refining and petrochemical estates frequently run AVEVA PI alongside Aspen InfoPlus.21, sometimes with a third system inherited from a DCS vendor.
The question that follows is always the same: consolidate onto one platform, or federate across what exists? The honest answer depends on things that have little to do with the historians.
The case for consolidation
- One skill set to hire for and retain, which matters more than it sounds when the labour market for historian engineers is as thin as it is
- One set of licences, one support relationship, one upgrade cycle
- One asset model, so fleet comparison is possible without a translation layer
- Fewer integration points, and integration points are where estates break
The case for federation
- Migration cost scales with history volume and tag count, and for a large refinery that is a serious number
- Some applications are tightly coupled to a specific historian’s API, and rewriting them is its own project
- Site autonomy is sometimes contractual, particularly in joint ventures where you do not control the other party
- Regulatory and validated environments may make change expensive out of proportion to the benefit
- If a divestiture is plausible within a few years, consolidating an estate you may be separating is work you will undo
What usually decides it
Three questions tend to settle the argument more reliably than a platform comparison.
Who is going to operate it in five years? If your historian expertise is concentrated in two people approaching retirement, running two platforms is a staffing risk regardless of the technical merits.
What do you actually need to compare across sites? If the answer is a handful of KPIs, federation plus a common model at the reporting layer delivers it at a fraction of the cost. If engineers need to work fluidly across the fleet at full resolution, consolidation starts to pay.
Is the data model the real problem? Frequently the pain attributed to having two historians is actually the absence of a shared asset model. Consolidating onto one platform without building that model reproduces the problem on a single system, at considerable expense, and the disappointment arrives late.
The middle path, and its trap
A federation layer — AspenTech Inmation is designed for exactly this — can present multiple sources through one object model without moving the underlying history. It is a genuinely good answer for estates that cannot justify consolidation.
The trap is treating federation as a way to avoid the modelling work. A federation layer over three inconsistent models produces one inconsistent model with extra infrastructure. The modelling is the work; the federation is just where it lives.
How we assess it
We look at the estate as it is, the realistic five-year ownership picture, and what genuinely needs to be comparable. Then we say which way the economics point — including, sometimes, that the problem does not justify a project. We hold AVEVA accreditations and work across Aspen platforms; we are not a reseller for either. More on mixed estates.

