Connect FactoryTalk Historian to Power BI
Why connecting FactoryTalk Historian to Power BI is harder than it looks
If you've already tried something and hit a wall, the list below is probably why. FactoryTalk Historian runs on the same OSIsoft PI data engine that powers many of the world's largest industrial historians — which means it inherits all of PI's power, and all of PI's barriers to modern BI tools.
FactoryTalk Historian is built on the PI engine — and Power BI has no native connector for it
Rockwell Automation's FactoryTalk Historian runs on the OSIsoft PI Data Archive — the same proprietary time-series engine used by AVEVA PI. That means it stores data in PI's binary format, exposes it through PI's API layer, and inherits PI's complete absence of a native Power BI connector. There's no "FactoryTalk" data source in Power BI's connector list, and there's no PI connector either. Every team building this integration is building it from scratch.
The PI Web API can serve data — but it needs to be deployed and configured first
The closest thing to a Power BI bridge is the PI Web API — a REST interface that sits in front of the PI Data Archive and returns JSON that Power BI can consume. Getting there requires deploying the PI Web API on a server inside your network, configuring authentication, and building the Power BI queries yourself using the web connector. It works, but it's an infrastructure project before it's a report.
Direct access requires the PI AF SDK on every Power BI Desktop machine
If you're using a PI-based custom connector or a community solution, it typically requires the PI Asset Framework SDK installed on the machine running Power BI Desktop. That SDK is a licensed piece of client software that requires IT deployment. Every developer or analyst who builds or refreshes reports needs it, and keeping SDK versions aligned across machines becomes its own maintenance burden.
FactoryTalk Historian lives on the OT network — and Power BI Service can't reach it
FactoryTalk Historian is deployed on the operational technology network, isolated from the internet and often from the corporate IT network. Power BI Desktop can connect if the developer's machine has OT access, but Power BI Service — the cloud platform used for shared dashboards and scheduled refreshes — cannot reach the historian at all without additional infrastructure in place.
Sharing reports through Power BI Service requires an on-premises data gateway
To schedule data refreshes and share reports through Power BI Service, you need a Microsoft on-premises data gateway installed on a machine that can reach the historian. That gateway server needs the PI client software installed on it too. What started as a reporting project now requires a dedicated gateway server, a PI license for that server, and an IT team to maintain it.
Raw time-series data volumes will overwhelm Power BI's in-memory model
FactoryTalk Historian can store thousands of tags at sub-second resolution. Pulling raw data directly into Power BI — even for a moderate number of tags over a few weeks — quickly exceeds what Power BI's in-memory engine handles well. Reports become slow to load, slow to refresh, and expensive to maintain. The data needs to be pre-aggregated before it reaches Power BI, but that aggregation layer doesn't exist natively in the PI stack.
Integration answers are scattered across Rockwell, OSIsoft, and AVEVA documentation
Because FactoryTalk Historian is built on PI, most of the integration guidance lives in OSIsoft or AVEVA documentation — not in Rockwell's FactoryTalk knowledge base. Teams searching for "FactoryTalk Historian Power BI" often miss the relevant PI Web API documentation entirely, or find community solutions built for a different version of the PI stack than what's running at their site.
The approaches teams usually try
Most teams try one of these before looking for a different path.
PI Web API + Power BI web connector
Deploy the PI Web API on a server with access to the historian, then use Power BI's generic web connector to query it. Doesn't require the PI SDK on developer machines once the API server is running.
The catch: The PI Web API needs to be deployed, secured, and maintained as infrastructure. Query construction is manual and PI-specific. Power BI Service still can't refresh without an on-premises gateway.
Extract to SQL, connect Power BI to SQL
Run a scheduled process that pulls data from FactoryTalk Historian and writes it to a SQL Server database. Power BI connects to the SQL database on the IT network instead of the historian directly.
The catch: You've now built and have to maintain an ETL pipeline. Data latency depends on the extraction schedule. Schema design for time-series in SQL is non-trivial, and the pipeline breaks silently when the historian changes.
FactoryTalk Analytics / VantagePoint
Rockwell's own analytics tools — FactoryTalk Analytics and the older VantagePoint product — are designed to visualize historian data and can produce trend views and dashboards without needing Power BI.
The catch: These are separate platforms your team has to adopt and maintain alongside Power BI. Most organizations have already standardized on Power BI — adding another reporting tool for one data source creates parallel workflows nobody wants.
How TrendOps connects FactoryTalk Historian to Power BI
TrendOps takes a different approach: instead of giving Power BI direct access to the historian, it brings the 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.
The TrendOps Connector runs on-premise, inside the plant network, reading from the PI Data Archive directly via its native interface.
Data moves from the historian to the cloud over an outbound-only connection. No changes to OT firewall rules. No inbound exposure to the plant network.
TrendOps Platform exposes data through a standard Web API that Power BI's built-in web connector can query. No PI client software on any analyst or developer machine.
Because TrendOps Platform lives in the cloud, Power BI Service can reach it directly. Scheduled refreshes and shared dashboards work without a gateway server on the OT network.
TrendOps handles time-series aggregation — averages, min/max, time-weighted values — in the platform. Power BI receives clean, pre-aggregated data at the resolution you choose, not raw sub-second readings.
TrendOps exposes a consistent data model regardless of which historian is underneath. No PI-specific query syntax or retrieval mode knowledge required.
TrendOps streams live tag values and backfills historical data, so Power BI reports can show both current plant state and trend analysis without separate data sources.
If you have AVEVA PI, Wonderware, or DeltaV alongside FactoryTalk Historian, TrendOps can connect all of them. One Power BI connection, one data model, one report that spans your entire plant floor.
What you end up with
Outside the plant floor, no PI client software is needed on any machine in the reporting chain.
Power BI Service connects to TrendOps Platform directly. No on-premises gateway server to deploy or maintain.
Pre-aggregated at the platform level. Power BI works with the right data at the right resolution, not raw historian output.
FactoryTalk, AVEVA PI, Wonderware, DeltaV — one platform, one Power BI connection, one report.
Your Power BI team shouldn't need PI software to report on plant data
TrendOps handles the historian connection on-premise and serves clean, pre-aggregated data through a standard API your Power BI reports can reach from anywhere.
Book a Demo