Power BIInductive Automation Ignition (MES/SCADA) Agent view

How to connect Power BI to Ignition (MES/SCADA)

Short answer

Connect Power BI to Ignition through the SQL database behind the historian and MES, preferably a reporting replica or summary tables, using an on-premises data gateway. Use WebDev APIs only for small live slices. Build OEE, downtime and quality dashboards from curated views, then add natural-language Q&A over that model.

Ignition already has strong visualization in Perspective and Vision, so the reason to add Power BI is usually the audience. Plant managers, finance and corporate teams want production and downtime next to ERP cost, sales and quality data, in the tools they already open every morning.

The wrinkle is that Ignition's data is built for operations, not reporting. The historian stores time series in partitioned tables with a lookup table for tag identity, and MES data may be spread across custom schemas. Pointing Power BI straight at those tables works for a demo and tends to hurt in production.

This page lays out a sturdier path: curate the data in SQL, connect through a gateway, model it for the questions people ask, and consider a natural-language layer on top.

What teams use it for

OEE and availability by line

Combine state tags, counts and reject counts from curated tables to compute availability, performance and quality per line, shift and product.

Downtime Pareto

Use the downtime event table with reason codes to show top causes, mean time between stops and trend by week, filtered by line or crew.

Energy and utility consumption

Aggregate meter tags into hourly and daily tables, and relate consumption to production volume to find energy per unit.

Quality and SPC summaries

Bring in measurement results and limits to chart capability and out-of-control events, with drill-through to the batch.

Plant to ERP comparison

Join MES production counts to ERP work orders and standard costs to see schedule adherence and yield variance in one model.

Multi-site rollup

Aggregate summary tables from several Gateways into a central warehouse so corporate sees all plants on the same definitions.

Inductive Automation Ignition (MES/SCADA) integration surface

  • Historian SQL storage: tag history is held in partitioned data tables with a tag lookup table, in your chosen database such as SQL Server, PostgreSQL or MySQL. Naming and structure vary by version, so inspect your schema.
  • Transaction Groups (SQL Bridge module) write selected tags to relational tables on a trigger, which suits production counts, batch records and recipes that you want in clean rows.
  • Named queries and database connections let you build views over the data, and the Reporting module can produce scheduled extracts as well.
  • WebDev endpoints can return JSON for small, near-live datasets, though they are not the right path for large history loads.
  • Historian query functions return aggregated values with defined intervals, which you can write to summary tables on a schedule from a Gateway timer script.

How it works

  1. 1

    Decide the data path

    Prefer a reporting database or read replica fed from the historian, so heavy Power BI refreshes do not compete with plant logging.

  2. 2

    Build curated summary tables

    Create hourly and per-shift tables for production, state time, downtime and key process values. A Gateway timer script, a stored procedure or an ETL job can populate them.

  3. 3

    Create reporting views

    Present clean views with friendly names, units, line and area attributes and a calendar and shift dimension, not raw tag IDs.

  4. 4

    Install the on-premises data gateway

    Put the gateway on a server that can reach the SQL database. Configure credentials with a read-only account and schedule refreshes outside peak logging periods.

  5. 5

    Model and measure

    Import summaries, use DirectQuery only for narrow cases, define OEE and downtime measures once in DAX, and document the definitions.

  6. 6

    Add row-level security and Q&A

    Limit data by plant or line with roles, then enable natural-language questions over a tidy semantic model, with synonyms for your line and product names.

Example flows

Nightly OEE refresh

Trigger: Midnight schedule at the end of the production day.

  1. A Gateway timer script or database job aggregates state and count tags into shift summary rows.
  2. The on-premises data gateway refreshes the Power BI dataset from the reporting views.
  3. Dashboards update with the previous day's OEE, downtime and reject figures.

Result: Managers open a consistent dashboard each morning without touching the plant historian.

Plant versus ERP schedule view

Trigger: Weekly planning meeting.

  1. MES summary tables supply produced quantities by work order.
  2. ERP extract supplies planned quantity, due date and standard cost.
  3. The model joins on work order and shows lateness and yield variance.

Result: Planners see which orders slip and why, using downtime reasons from Ignition.

Keeping data on-prem

Power BI Desktop and the on-premises data gateway let you keep the source database on your network and send only the dataset to the Power BI service, or you can use Power BI Report Server if the data and reports must stay entirely local. Check the licensing and feature differences for your edition. For natural-language questions that must not leave the site, put a local model over the same curated views, so users ask in plain language and the answer comes from your SQL without external processing. That is a pattern Netray builds alongside existing dashboards.

Security checklist

  • Use a read-only SQL account limited to the reporting views, never the account Ignition uses to write history.
  • Apply row-level security by plant and line, and review which workspaces and people can export data.
  • Avoid exposing the historian database directly to the internet; route refresh through the data gateway.
  • Mask or exclude fields that reveal customer, recipe or proprietary process details when sharing beyond the plant.
  • Document dataset owners and refresh credentials, and rotate them on a schedule.

Ways to get it done

Connect Power BI directly to the historian database

Effort: Days, with performance and naming limits.

Quick prototype on a small, non-critical dataset.

Curated reporting layer with Power BI gateway

Effort: Three to eight weeks including summary logic and definitions.

Most plants that want reliable dashboards for management.

Warehouse plus semantic model plus natural-language layer

Effort: Phased project, partner or in-house, with Netray adding on-prem Q&A.

Multi-site groups and teams that need ERP and plant data together.

Pitfalls

  • !Querying raw historian partitions from Power BI, which causes slow refreshes and load on the logging database.
  • !Joining on tag names that change; use stable IDs or a maintained tag dimension.
  • !Mixing time zones and daylight saving between Ignition timestamps and the model.
  • !Defining OEE differently in Perspective and Power BI so numbers disagree in meetings.
  • !Using DirectQuery on large tables and then blaming Power BI for being slow.

Frequently asked questions

Does Ignition have a native Power BI connector?

The usual route is through the SQL database that holds the historian and MES data, using Power BI's standard SQL connectors and the on-premises data gateway. Check the module marketplace for any packaged option, but the SQL path is dependable.

Can Power BI show live SCADA values?

Only near-live, and not as a replacement for Perspective or Vision. For real-time operations keep Ignition screens. Use Power BI for trends, summaries and cross-system analysis, with refresh as often as the source and licence allow.

Why not query the historian tables directly?

They are partitioned time series built for write throughput, and tag identity sits in a lookup table. Direct queries are slow and fragile. Aggregated summary tables or historian query functions give cleaner, faster results.

Can we ask questions in natural language?

Power BI offers Q&A and Copilot style features depending on licence, and they work best over a well named model. For data that cannot leave the site, a local model over the same views can answer questions without cloud processing.

How do we combine this with ERP data?

Bring ERP tables or extracts into the same warehouse or model, join on work order, item and date, and keep one definition for each metric. The plant gives you downtime and counts, the ERP supplies cost and demand.

Want Power BI working on your Inductive Automation Ignition (MES/SCADA)?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment