This comparison is usually driven by cost, and on the storage layer the saving is real. The part that decides whether the move pays for itself is the asset model, because that is what you would be rebuilding yourself.
Our principal consultant spent 18 years on operational data projects for BHP, Rio Tinto, Senex Energy and Mackay Sugar, delivered while working with previous consulting employers. We resell neither product and have no reseller margin either way.
As a place to put time series and get it back, Canary does the job at a lower and more predictable cost, with less administration. For a single site whose tags people can name, that is often the whole requirement.
The PI System earns its cost through Asset Framework and everything that reads it. Once reporting has to be consistent across plants, or an obligation attaches to the numbers, replacing the archive means replacing the model too, and the model is the expensive part.
A time-series historian licensed per server with no point metering. It compresses without discarding values, installs and upgrades with little ceremony, and comes with the Axiom web client, an Excel add-in and standard collectors including OPC. It suits sites without a dedicated historian administrator, and remote or unattended assets.
Strong at storing and retrieving. Light on enterprise asset modelling.
An operational data infrastructure. The Data Archive holds the history, and Asset Framework above it turns tags into equipment with templates, attributes and event frames that span sites. PI Vision, the Analysis Service, PI Integrator and the Web API all read that model, which is what lets one report serve many plants.
Strong at enterprise context and distribution. Heavier to licence and administer.
Neither column wins outright. The rows that matter depend on how many sites you report on.
| Aspect | Canary Historian | AVEVA PI System |
|---|---|---|
| Licence shape | Per server, no point metering. Adding tags does not change the bill | Subscription sized by data volume and enabled modules |
| Compression | Lossless. The archived value is the measured value | Swinging door by default, configurable. Very efficient, and lossy unless tuned off |
| Asset model | Tag organisation and metadata. No cross-site template hierarchy | Asset Framework. Templates, hierarchy, calculated attributes, event frames |
| Event handling | Query by time range | Event frames make a period of time an object you can count and compare |
| Administration effort | Low. Installs and upgrades without specialist help | Higher. Benefits from a named administrator, particularly for Asset Framework |
| Built-in visualisation | Axiom web client, Excel add-in, trend tools | PI Vision with asset-relative displays applied across every instance of a template |
| Third-party analytics support | Supported by the main tools including Seeq, and thinner beyond that | Broadest connector coverage in the sector |
| Australian skills and integrators | Fewer. More knowledge stays in-house | Established pool, concentrated in mining, energy and utilities |
| Best fit | Single sites, remote and unattended assets, cost-constrained deployments, OEM | Multi-site groups, consistent reporting between plants, obligations attached to numbers |
Commercial terms for both products change. Treat this as a structural comparison and confirm current pricing with Canary Labs and AVEVA before you build a business case.
The licence saving is easy to calculate, which is why it tends to be the only number in the paper.
Moving tag history between historians is a known quantity. It takes planning and it takes time, and it is rarely the reason a migration overruns. The cost sits in the layer that was built on the thing you are removing.
Before committing, count these: Asset Framework templates and the hierarchy beneath them, PI Analysis calculations and what depends on their outputs, event frames and any reporting that counts them, PI Vision displays that were asset-relative and will need rebuilding per asset elsewhere, every Power BI report and integration pointed at PI, and the spreadsheets that people rely on without anybody formally owning them. That last category is usually the one nobody can enumerate, and it is the one that surfaces after cutover.
None of this argues against migrating. A site that used PI as a trend store and never built an asset model has little dependent layer to worry about, and the saving is close to the headline figure. The point is to find out which situation you are in before the business case is approved, because the difference between the two is measured in months.
For storing and retrieving time series, yes. Canary is a proven historian with lossless compression, a straightforward install, a web client in Axiom and an Excel add-in, and it is licensed per server rather than by point count. Sites that need history kept reliably and trended by people who know which tag they want are well served by it. Where the comparison stops being like for like is asset modelling and enterprise distribution. If your reporting depends on a shared equipment model across several plants, that is the part of the PI System you would be replacing with your own work.
The main one is an equivalent of PI Asset Framework: a hierarchy that spans sites, templates that define equipment once and apply everywhere, attributes that resolve to calculations or to other systems as well as to tags, and event frames that make a period of time a queryable object. Reporting tools consume that model directly, which is why one Power BI report can serve five plants. The second is ecosystem depth. Third-party analytics tools, integrators and job candidates are more plentiful around the PI System in Australia, so a Canary site carries more of its integration and support knowledge internally.
Cost predictability and operational simplicity. A per-server licence with no point metering means instrumenting more of the plant is an engineering decision rather than a procurement one, and teams historise the marginal signal that a metered site would have left out. It installs and upgrades with far less ceremony, which matters when there is no dedicated historian administrator, and it suits remote and unattended sites where nobody is going to nurse a large platform. Lossless compression also avoids the arguments about whether an archived value was the real one.
Tag history migrates, and that part is mostly a matter of time and care. The work people underestimate is everything built on top: Asset Framework templates and hierarchy, PI Analysis calculations, event frames, PI Vision displays that were asset-relative, and every report, integration and spreadsheet that points at PI. Scope the dependent layer before the archive, because that is where the effort sits. A migration justified purely on licence saving can cost more than it saves once the asset model has to be rebuilt somewhere else.
For one plant, with tags people can name, and no group reporting obligation, Canary covers the requirement at a lower total cost and with less administration. The case for the PI System strengthens as sites multiply, as reporting has to be consistent between them, and as obligations attach to the numbers. The question worth asking is not how many tags you have today but whether anyone will need to compare this plant with another one in the same report.
The historian is where the evidence lives, so yes, indirectly. Safeguard Mechanism reporting and the resource and energy data behind it depend on being able to show how a figure was derived from measurements, months or years later. Both products retain data well enough to support that. What decides whether you can actually produce the audit trail is whether the calculation and the context were modelled somewhere durable, or whether they live in a spreadsheet on somebody's drive.
We can scope what actually depends on your current historian before anyone signs a business case. If the dependent layer turns out to be thin, that is good news and we will tell you.