Connect AVEVA Wonderware to Power BI
Why connecting Wonderware to Power BI is harder than it looks
If you've already tried something and hit a wall, the list below is probably why. Wonderware is deceptive — it looks like something Power BI should be able to connect to directly, and that impression sends a lot of teams down the wrong path before they understand what's actually in the way.
IndustrialSQL looks like regular SQL — but it isn't
AVEVA Wonderware Historian exposes data through IndustrialSQL Server, which has a SQL-like interface. On the surface, it looks like something Power BI should be able to query directly via ODBC. In practice, IndustrialSQL uses proprietary retrieval semantics that don't behave like standard SQL. A query that looks syntactically correct will return unexpected results — or nothing — if you don't understand how Wonderware retrieves time-series data. This false familiarity is what sends most teams down the wrong path first.
Retrieval modes add a layer most BI developers don't expect
Wonderware doesn't return data the way a relational database does. To get meaningful results, you need to specify a retrieval mode: Cyclic (evenly spaced time intervals), Delta (only values that changed), BestFit (a compressed summary), or StartOfInterval (first value in each period). Use the wrong mode and you'll get data at the wrong frequency, miss transitions, or end up with far more points than Power BI can handle. Understanding which mode to use — and why — requires knowledge of Wonderware's internal data model that most BI developers simply don't have.
The ODBC path requires AVEVA client software on every machine
Querying IndustrialSQL from Power BI Desktop requires AVEVA's IndustrialSQL ODBC driver installed locally. That driver is part of the Wonderware/AVEVA client software stack — not a standalone download. Installing it typically requires an AVEVA license and IT involvement. Every developer who builds or refreshes reports needs it on their machine, which means your data access is as wide as your software deployment effort.
Power BI Service needs an on-premises gateway — with AVEVA software on it
Getting Power BI Desktop working is only half the problem. Sharing reports through Power BI Service — the cloud version that most organizations use — means routing queries through an on-premises data gateway. That gateway needs the IndustrialSQL ODBC driver installed on it too. So now you need a dedicated gateway server, a licensed AVEVA client installation on that server, and someone to own and maintain it. A report that "works on my machine" is a long way from a report that works for everyone.
The Wonderware historian lives on the OT network
Like most process historians, Wonderware runs inside the OT network — isolated from corporate IT for good reason. Giving Power BI Service a path to it means either opening firewall rules between OT and IT, or using that on-premises gateway as a network bridge. Neither is a simple change, and both create ongoing security surface that OT and IT teams will want to review carefully.
Raw time-series data at historian resolution will overwhelm Power BI
Wonderware stores process data at high frequency — sub-second for many tags — across potentially thousands of points. Power BI is a reporting and analytics tool, not a time-series engine. Pulling raw historian data directly into a Power BI model produces datasets it can't handle gracefully: slow queries, sluggish reports, and model size limits. Pre-aggregating the data — into hourly summaries, shift totals, or daily rollups — has to happen somewhere before Power BI sees it, and without a dedicated layer to do that work, it ends up in Power Query or DAX where it doesn't belong.
AVEVA's rebranding makes documentation a moving target
What most people still call "Wonderware Historian" has been rebranded multiple times: Wonderware Historian, then AVEVA Historian, and now part of AVEVA's broader Operations Data Infrastructure. Installations across different sites and vintages run on different versions with different schemas and connection strings. Documentation is fragmented across product generations. What worked in one version — or what you find in a forum post — may not apply to what you're actually running.
The approaches teams usually try
These can work — but each comes with trade-offs that tend to surface after go-live.
ODBC via IndustrialSQL + on-premises gateway
Install the IndustrialSQL ODBC driver on a Power BI gateway server, configure Power BI Service to route queries through it, and build reports against the live historian.
The catch: A dedicated gateway server, licensed AVEVA client software, network access from IT to OT, and a dependency stack that someone has to own. Getting the retrieval mode right in Power Query requires historian expertise most BI teams don't have.
Extract to SQL or flat file first
Build a scheduled job to extract Wonderware data into a SQL Server table or CSV, then point Power BI at that. Sidesteps the IndustrialSQL complexity and avoids the gateway headache.
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 until it breaks.
AVEVA's built-in reporting tools
Use Wonderware Intelligence or AVEVA Insight for reporting — tools designed specifically for Historian data that understand the retrieval model natively.
The catch: Locked into the AVEVA ecosystem. Your process data stays separate from your other business data, and your reports live in a different tool than the rest of the organization uses — making cross-functional reporting difficult or impossible.
How TrendOps connects AVEVA Wonderware to Power BI
TrendOps takes a different approach: instead of giving Power BI a path into the OT network, it brings the Wonderware data to a cloud platform that Power BI can connect to using a standard Web API — with no IndustrialSQL client software required outside the plant floor.
TrendOps Edge connects to Wonderware Historian through IndustrialSQL Server directly — no AVEVA client SDK installation needed. The connector runs on-premise alongside the historian and handles the IndustrialSQL query logic internally, so your BI team never touches it.
TrendOps handles the Wonderware retrieval mode configuration — Cyclic, Delta, BestFit, StartOfInterval — at the connector level. Your BI team queries clean, consistently shaped data through a standard API, with no need to understand Wonderware's internal retrieval semantics.
TrendOps Edge deploys on-premise and communicates outbound only over MQTT. The Wonderware historian never needs to be reachable from IT or the internet. It works across firewalled network segments and DMZ layers without inbound port rules.
Once Wonderware data is in TrendOps, Power BI connects to it like any modern data source — no on-premises gateway, no AVEVA software on the BI machine. Your BI team works with a clean, standard API and never has to touch IndustrialSQL again.
TrendOps aggregates Wonderware data server-side before Power BI sees it. Instead of pulling raw historian values at sub-second resolution, Power BI queries pre-aggregated data at the frequency that makes sense for the report — hourly, daily, shift-based. No aggregation logic in Power Query or DAX.
TrendOps auto-discovers the full tag catalog from Wonderware on startup, regardless of which version or product generation your historian is running. The tag list is immediately available in TrendOps — no manual configuration, no schema digging.
Aggregations, calculated metrics, and business logic live in TrendOps — not embedded in individual Power BI report files. Every report that connects to TrendOps uses the same consistent data layer without rebuilding logic from scratch.
TrendOps can pull from multiple historians and data sources simultaneously. If your operation has both Wonderware and PI, or Wonderware alongside a SQL-based DataLogger, your Power BI reports can combine all of it through a single connection — without separate connectors or manual data merging.
What you end up with
Power BI connected to current Wonderware tag values — updated on your configured polling interval
No on-premises Power BI gateway to stand up, license, or maintain — Power BI connects to TrendOps like any cloud data source
All your OT sources — Wonderware, PI, DeltaV — unified in one data layer that every report can draw from
Add a tag to your report without an IT ticket — TrendOps discovers the full catalog and makes it available immediately
Your Wonderware data in Power BI — without the complexity
TrendOps connects to your AVEVA Wonderware Historian on-premise and makes the data available to Power BI through a standard API — no gateway, no IndustrialSQL client software, no retrieval mode expertise required.
Book a Demo