These serve different audiences at different time scales, and the interesting question is not which to pick. It is what sits between your historian and your reporting layer, because that is what decides whether anyone believes the numbers.
Our principal consultant spent 18 years building group and operational reporting over historian and plant data for BHP, Rio Tinto, Senex Energy and Mackay Sugar, delivered while working with previous consulting employers.
PI Vision belongs in the control room, showing live equipment state to people who may need to act within minutes. Power BI belongs above it, joining production to cost and ERP for people deciding what happens next quarter. Neither substitutes for the other.
Pointing Power BI at raw process history is the failure that repeats. It works in testing, then a year of data accumulates and the refresh stops finishing.
Live equipment state, at the resolution the process runs at. Displays are built once against an Asset Framework template and applied to every instance, so a site covers hundreds of assets from a handful of definitions. It reads the PI System it belongs to and nothing else.
Audience: operators and supervisors. Horizon: now, and the last few hours.
Modelled reporting over many sources at once, so production can sit beside cost, maintenance spend, ERP transactions and emissions. Measures are defined in the model, distribution is organisational, and security can be applied per row so each site sees its own numbers in the same report.
Audience: management and group functions. Horizon: shift, month, quarter, year.
Most sites run both. These rows explain which work belongs where.
| Aspect | PI Vision | Power BI |
|---|---|---|
| Latency | Live, at process resolution | Scheduled refresh, or DirectQuery with a load cost |
| Data sources | The PI System only | Almost anything, joined in one model |
| Can join production to cost | No | Yes, and this is the main reason sites want it |
| High-resolution time series | Native. What it was built for | Needs aggregating first. Raw tags break import models |
| Asset context | Comes from Asset Framework templates | Whatever you modelled, or whatever the report author assumed |
| Display effort across assets | One asset-relative display serves every instance | One report with slicers, provided the model carries the hierarchy |
| Distribution | Users with PI access on the operational network | Organisation-wide, with row-level security and scheduled delivery |
| Suits regulatory reporting | Source of evidence, not the reporting surface | Yes, when the calculation is modelled and traceable |
| Where it fails | Anything needing non-PI data or a management audience | Anything needing sub-minute latency or raw signal detail |
The middle two steps are the ones that get skipped, and they are the ones that decide whether the report gets used or argued about.
Skipping the aggregation step is a performance problem and it announces itself early. A tag sampled every second produces over thirty million values a year, so a few hundred tags gives you a dataset that no import model refreshes comfortably. Teams discover this when the report that was fast in testing stops finishing after twelve months of history.
Skipping the modelling step is worse, because nothing breaks. Each report author aggregates raw tags with their own assumptions about downtime, sensor dropouts and where a shift boundary falls. Two reports then disagree about the same month and both authors can defend their figure. The site stops acting on the reports and goes back to the spreadsheet somebody trusts, and the reporting project is recorded as a technology failure when the actual gap was an agreed definition.
Deciding those definitions once, upstream, is unglamorous work that no dashboard demo ever shows. It is also the difference between plant reporting people use and plant reporting people relitigate.
There is no first-party Power BI connector for the PI System, so you go through one of several routes: PI Integrator for Business Analytics, which shapes asset-modelled data into tables for analytics, the PI Web API, PI OLEDB or JDBC, or a warehouse or lake that PI feeds on a schedule. For anything beyond a proof of concept, most sites end up with PI Integrator or a warehouse in the middle, because querying an operational historian directly from a refreshing report puts avoidable load on the system of record.
Because Power BI is built for modelled and aggregated data, and process history is neither. A single tag at one-second resolution is over thirty million values a year, and a few hundred tags makes a dataset no import model will refresh comfortably. The fix is to aggregate before the data reaches Power BI, to the grain the report actually needs, which is usually shift, hour or batch rather than second. Sites that skip that step build a report that works in testing and times out once a year of history accumulates.
Power BI, in almost every case. PI Vision is built for live equipment monitoring and it cannot join to finance, ERP or sales data, so a production number and its cost consequence cannot appear on the same page. Power BI does that joining well and distributes to a management audience with row-level security and scheduled delivery. Where PI Vision stays unbeaten is the control room, at a resolution and latency that Power BI does not attempt.
No. They serve different audiences at different time scales. PI Vision answers what is happening now, for people who may need to act in the next few minutes, and it does that on asset-relative displays that cover hundreds of assets from a handful of definitions. Power BI answers how last month went, for people deciding what to do next quarter. Replacing PI Vision with Power BI would give the control room a report that is minutes stale, which is the one thing a control room cannot use.
Deciding the calculation once, upstream of the report. When each report author aggregates raw tags with their own assumptions about downtime, sensor dropouts and shift boundaries, two reports disagree and both are defensible, which is how a site ends up arguing about numbers instead of acting on them. Putting the definition in the asset model or in a modelled layer that every report reads gives one answer and an audit trail for how it was derived. This is the work that decides whether plant reporting gets used.
Yes, and for multi-site groups it is often the better shape, because it gives you somewhere to land aggregated operational data alongside ERP and finance without either system carrying reporting load. It does not remove the modelling decision. A lakehouse holding raw tags with no agreed calculation produces the same disagreements as before, at greater scale. Decide the grain and the definitions first, then choose where they live.
Tell us which number two reports disagree on. That disagreement is usually where the missing definition is, and it is a cheaper thing to fix than a reporting platform.