Connect AVEVA PI to Power BI
Why connecting AVEVA PI to Power BI is harder than it looks
If you've already tried something and hit a wall, the list below is probably why. The barriers aren't obvious until you're already in the middle of them — and they tend to stack.
PI uses a proprietary time-series data model
AVEVA PI stores data in a Data Archive — a specialized time-series database built around tag names, timestamps, and values. It doesn't expose a standard SQL interface. To query it, you need AVEVA's own tooling: the PI AF SDK, PI Web API, or a PI OLEDB/ODBC driver. None of these are things Power BI understands natively.
Power BI has no native PI connector
Power BI Desktop and Power BI Service don't ship with an AVEVA PI connector. AVEVA offers a certified Power BI connector, but it requires the PI AF SDK installed on the machine running the queries. In Power BI Service — the cloud version that most organizations use for sharing reports — that means running queries through an on-premises data gateway with the PI AF SDK installed on it.
AVEVA's own connector comes with a significant cost
AVEVA does offer a certified Power BI connector for PI — but it isn't free. The licensing cost is a barrier on its own, before you've even accounted for the infrastructure required to run it. For organizations that just need process data in a report, the pricing is often hard to justify when the underlying problem is simply moving data from one system to another.
OT networks are intentionally isolated from IT and the cloud
In most industrial environments, the PI server lives on the OT network — firewalled from the IT network for good reason. Giving Power BI Service access to that environment means either opening firewall rules between OT and IT, standing up bridging infrastructure across multiple network segments, or both. Neither is trivial, and both introduce ongoing security surface to manage.
Raw time-series data at PI's native frequency will overwhelm Power BI
PI can store data at sub-second intervals. A single tag sampled every second generates over 86,000 data points per day — and most PI deployments have hundreds of tags. Power BI is a reporting tool, not a time-series engine, and it struggles badly with datasets at this volume. Before you can build a useful report, someone has to aggregate, resample, and align the data into a frequency Power BI can actually handle. Without a dedicated data layer to do that work, it falls on the BI developer — in Power Query, in DAX, or in a pre-processing script that nobody wants to own.
Every component you add is something to maintain
A PI AF SDK installation needs to stay current. A data gateway needs a dedicated server, Windows updates, and monitoring. A PI Web API deployment needs its own configuration and security management. Each component between PI and Power BI can break — and usually breaks quietly, before a morning report run, when no one is watching.
Adding one new data point means starting the whole process over
Once you've finally gotten PI connected to Power BI, adding a new tag to your report often isn't self-service. Depending on your setup, it means another request to OT to confirm the tag name, another ticket to IT to expose it through the gateway, and another round of waiting before you can build anything. For BI teams that want to iterate quickly, this is a serious bottleneck.
The approaches teams usually try
These can work — but each comes with significant trade-offs that tend to surface after go-live.
PI Web API + on-premises Power BI gateway
Install PI Web API on the historian server, stand up a Power BI on-premises data gateway, install the PI AF SDK on the gateway machine, and configure Power BI Service to query through it.
The catch: A dedicated gateway server, PI client licensing, network access from IT to OT, and an ongoing dependency stack that someone has to own and maintain.
AVEVA's certified Power BI connector
Use AVEVA's Power BI connector with the PI AF SDK installed locally. Works in Power BI Desktop but requires the same gateway path for Power BI Service — so you're back to Option A for any shared or cloud-hosted reports.
The catch: SDK on every machine that builds reports, licensing considerations, and limited to desktop-only access without gateway infrastructure.
Extract to SQL or flat file first
Build a scheduled job to extract PI data into SQL Server or CSV, then point Power BI at that. Sidesteps the PI connectivity problem entirely and avoids the gateway complexity.
The catch: A custom ETL pipeline to build and maintain, data latency built in by design, and the extraction logic lives in a script that nobody documents and everyone forgets about.
How TrendOps connects AVEVA PI to Power BI
TrendOps takes a different approach: instead of giving Power BI direct access to PI, it brings the PI data to a cloud platform that Power BI can connect to using a standard Web API — with no PI software required outside the plant floor.
TrendOps Edge deploys on-premise and communicates outbound only over MQTT. Your PI server never needs to be reachable from IT or the internet. It works across firewalled network segments and DMZ layers without inbound port rules.
Connects to PI via the PI AF SDK using dual PIDataPipe subscriptions (Archive and Snapshot) for live data. Can backfill historical tag values for any time window on demand — so your Power BI reports have current and historical context from day one.
TrendOps aggregates your PI data server-side before Power BI ever sees it. Instead of pulling millions of raw tag values, Power BI queries pre-aggregated data at whatever frequency makes sense for your report — hourly, daily, shift-based. Fast queries, manageable model sizes, and no aggregation logic cluttering your Power Query or DAX.
Once your PI data is in TrendOps, Power BI connects to it like any modern data source. No PI SDK on the BI machine, no on-premises gateway, no AVEVA software outside the plant. Your BI team works in familiar tools with a clean data layer underneath.
Aggregations, calculated metrics, and business logic live in TrendOps — not embedded in individual report files. Every Power BI report that connects to TrendOps uses the same consistent, centralized data layer without rebuilding logic from scratch.
TrendOps Edge tracks the last successful poll checkpoint. If a connection is interrupted, it resumes exactly where it left off — no duplicate values, no silent data gaps, no manual intervention needed to recover.
TrendOps can pull from multiple data sources simultaneously — other historians, SQL databases, external Web APIs. Your Power BI reports can combine PI process data with financial data, external inputs, or data from other systems, all through a single connection.
Need a new PI tag in your Power BI model? Enable it in TrendOps and it's immediately available — no IT request, no OT involvement, no waiting. TrendOps auto-discovers your full PI tag catalog on startup, so the data is already there. You just decide what to use.
What you end up with
Power BI connected to current PI tag values, updated on your configured polling interval
Query any date range without re-querying PI — historical data lives in TrendOps and is available on demand
Your BI team needs no PI expertise, AVEVA licenses, or special software — just a TrendOps API connection
Build more reports and dashboards on the same PI data — without repeating the integration work each time
Your PI data in Power BI — without the complexity
TrendOps connects to your AVEVA PI historian on-premise and makes the data available to Power BI through a standard API. Add tags, build reports, and extend your data model — without filing a single IT request.
Book a Demo