These two products get compared constantly and they are not substitutes. Ignition is a supervisory platform that runs plant. The PI System is a retained record that reporting and analytics read from. Most sites that ask the question have a gap at one layer and a working tool at the other.
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. What follows is that view, not a vendor pitch. We resell neither product.
If you need operators to see and control the process, that is Ignition territory and the PI System will not do it. If you need to answer a question about last quarter with numbers that survive scrutiny, that is what the PI System was built for and a SCADA historian will make you work harder for it.
On larger Australian sites the two run together, with Ignition collecting and controlling, and PI retaining and contextualising. The choice only becomes either-or on smaller sites where one tool has to cover both jobs.
An operational data infrastructure, originally from OSIsoft. The Data Archive stores time series at high resolution for years. Asset Framework sits above it and turns tags into equipment with attributes, templates and event frames, so a query can ask about a crusher rather than about tag 4412. PI Vision draws it, the Analysis Service calculates on it, and PI Integrator and the Web API hand it to reporting.
Reads and retains. It does not write to plant and it is not an HMI.
A SCADA, HMI and integration platform. It has an OPC UA server and device drivers built in, Perspective for browser and mobile screens, Vision for desktop clients, scripting in Python, and a tag historian that writes to a standard SQL database. The module range extends into reporting and alarm notification, and third-party MES modules add downtime and production tracking.
Collects, displays and controls. Historising is one of its jobs rather than its whole purpose.
Neither column is the winner. Read down the aspect that matters to your site.
| Aspect | AVEVA PI System | Ignition |
|---|---|---|
| Primary job | Retain and contextualise operational data for the enterprise | Run supervisory control and operator screens |
| Controls plant | No. Read only by design | Yes. Writes setpoints and commands |
| History store | Purpose-built archive with swinging door compression, designed for years of retention | Standard SQL database. Retention at high resolution needs partitioning and housekeeping |
| Asset model | Asset Framework. Cross-site hierarchy, templates, event frames, attributes that resolve to calculations and other systems | User Defined Types. Templates tags per gateway. No event frame equivalent |
| Licence shape | Subscription sized by data volume and enabled modules, so point counts affect cost | Per server with unlimited tags, clients and connections inside the licence |
| Visualisation | PI Vision. Asset-relative displays built once and applied to every instance | Perspective and Vision. Full HMI freedom, mobile native, more build effort per screen |
| Reporting and BI | PI Integrator, Web API and OLEDB. Asset model gives reports their context | SQL historian is directly readable by any BI tool. Context is whatever you modelled |
| Typical Australian footprint | Large mines, refineries, LNG, water and power utilities | Greenfield sites, mid-size plants, OEM and remote assets, sites replacing ageing SCADA |
| Skills availability here | Specialist and concentrated. Asset Framework skills are scarcer than PI administration skills | Broader, and closer to general software skills because of the Python scripting |
Licensing terms for both products have changed in recent years. Confirm current commercial detail with AVEVA and Inductive Automation before building a business case on it.
This is the part that gets underweighted in selection exercises, and it has more effect on what a site ends up measuring than any feature on the list above.
When points are metered, teams ration them. Engineers put forward the tags they can justify, someone reviews the count against the licence, and the marginal signal that would have been useful in an investigation two years later never gets historised. The data you wish you had is the data nobody could cost-justify at the time.
When tags are unlimited, the opposite failure appears. Everything gets historised, including thousands of points nobody has ever looked at, and the SQL store grows until long-range queries start timing out. The discipline moves from counting licences to managing retention and deciding what deserves high resolution.
Both failures are fixable, and both are cheaper to prevent at design time than to unwind once five years of history exists in the wrong shape.
The arrangement that turns up most often on Australian sites with more than one plant.
The reason this shape persists is that the two tools have different obligations. A control system has to be available right now. A record has to still be correct in seven years, when somebody asks how a number was derived. Asking one system to satisfy both tends to compromise whichever one was not the original design goal.
Usually no, because the two sit at different layers. Ignition is a SCADA and HMI platform that operators use to see and control plant, and it can historise tags to a SQL database. The PI System is not an HMI and does not control anything: it is a long-retention operational data store with an asset model on top, built to be read by reporting, analytics and enterprise systems. Sites replace PI with Ignition successfully when their only real use of PI was trending. Sites that use Asset Framework templates, event frames and decades of archived history find that the replacement scope is much larger than it first appears.
Yes, and this is the most common arrangement on larger Australian sites. Ignition runs the control room and collects from PLCs and field devices, then exposes tags over OPC UA. The PI System subscribes to those tags and becomes the retained record that Power BI, reporting and analytics read from. The division of labour is that Ignition answers what is happening now and PI answers what happened over the last seven years.
The licence shapes differ more than the headline numbers do. Ignition is licensed per server with unlimited tags, clients and device connections inside that licence, so adding instrumentation does not change what you pay. AVEVA licenses the PI System by subscription, sized by the volume of data and the modules you enable, so the count of points and interfaces does affect cost. Ignition is generally the lower software spend, particularly on smaller sites and where you want to instrument a lot more points. Confirm current terms with each vendor before you build a business case, because both have changed their models in recent years.
Ignition has User Defined Types, which template a set of tags and apply them across many instances of the same equipment. That covers a good part of what teams use Asset Framework for. What Asset Framework adds is a hierarchy that spans sites and systems rather than one gateway, attributes that resolve to calculations or to other systems as well as to tags, event frames that turn a period of time into a queryable object, and a model that reporting tools consume directly. If your reporting depends on asset context that is shared across several plants, that gap is the thing to test before you commit.
Work out which layer you actually lack. A greenfield site with no supervisory system needs SCADA first, and Ignition is a strong candidate on cost and speed of build. A site that already has working SCADA but cannot answer questions about last quarter has a historian and asset model gap, which is the problem PI was designed for. Choosing the second tool before you have the first one working is the more expensive mistake, because analytics on data that was never contextualised produces numbers nobody trusts.
Yes, by different routes. Ignition historises into a standard SQL database, so Power BI connects to it the way it connects to any SQL source. The PI System needs a shaping layer, usually PI Integrator for Business Analytics, the PI Web API, or a warehouse that PI feeds. In both cases the work that decides whether the report is trusted is aggregation and context, not the connector.
We support both and sell neither, so we have no stake in which one you pick. Tell us what your site cannot answer today and we will tell you which layer is missing. If the answer is that your current tooling is fine, we will say that.