Power BI for Manufacturing: Getting PLC and SCADA Data In Cleanly

Power BI is the reporting tool many Australian manufacturers already use for finance and sales, so it is a natural place for managers to want production figures too. Getting PLC and SCADA data into it cleanly takes more thought than connecting to a database and dragging fields onto a page. This guide covers the architecture that works, where context and calculations belong, how to model the data, and the refresh and time-zone limits to design around.

It is written for operations and engineering managers, and for the IT or BI people who will maintain the reports, in plants that want production dashboards in Power BI alongside their other business reporting.

The architecture that works

A reliable Power BI setup for production data has four layers, and Power BI is only the last one.

1. The control layer. PLCs and machine controllers on the line, which know every state, count, reject and fault.
2. The collection layer. A SCADA platform or data server on the OT network that reads the PLCs, detects events such as stops and changeovers, and adds context.
3. The production data layer. A SQL database or historian, owned by the site, holding events, counts and their context in documented tables.
4. The reporting layer. Power BI, reading curated views or tables from the production data layer through the on-premises data gateway, or from a copy in the cloud.

Two rules follow from this. Power BI never connects to a PLC, and nothing in the business network writes back to the control layer. Data moves outbound from the plant, through the network boundary described in our guide to ISA-95 and the Purdue model.

Where context comes from

A count of 12,000 cups is meaningless in a report unless it knows which line, SKU, order and shift it belongs to. That context has to be attached where it is created, in the collection and production data layers, not reconstructed in Power BI later.

• Line and machine from one equipment hierarchy used by SCADA, the database and the reports.
• SKU and order from the schedule or ERP, selected at changeover and stored with each event.
• Shift from one shift calendar and one time base.
• Stop reason from the PLC fault or the operator's HMI selection, stored with the stop.

If Power BI has to join production counts to a separate shift spreadsheet by timestamp, the report will eventually be wrong at a shift boundary. Our reliable plant data page covers the context model in more detail.

Calculate OEE upstream

It is tempting to calculate OEE in Power BI with DAX measures. It usually causes problems within a year.

• The rules for planned and unplanned time, ideal rates per SKU and changeover booking end up in report formulas that plant engineers cannot see or change.
• The SCADA screen at the line and the Power BI report calculate OEE differently, and the weekly review argues about which is right.
• A new line or SKU needs a report change as well as a plant change, and one of them gets missed.

The more durable approach is to calculate availability, performance, quality and OEE in the production data layer, per line, SKU, order and shift, using the same definitions as the SCADA screens. Power BI then aggregates and presents figures that already mean the same thing everywhere. Our OEE guide explains the definitions that have to be agreed first.

Modelling production data for Power BI

Power BI works best with a star schema: fact tables of events and measurements, surrounded by dimension tables that describe them.

Keep the fact tables at the grain the reports need. Most management reporting needs production per shift or per hour, not every PLC scan. High-rate process trends belong in a historian and a SCADA trend screen, not in a Power BI data set.

Refresh limits and real-time expectations

Power BI offers two main ways to read data. Import mode copies data into the Power BI model on a schedule; it is fast to use but only as current as the last refresh. DirectQuery reads the source each time a visual loads; it is more current but puts load on the database and can be slower. At the time of writing, Microsoft limits scheduled refresh to eight a day on shared capacity and 48 a day on Premium or Fabric capacity.

For production data, that leads to a practical split.

• Operators and supervisors who need to act within minutes use SCADA screens and alerts, which update within seconds.
• Managers use Power BI reports refreshed on a schedule that suits their decisions, often every shift or every day.
• Near-real-time Power BI views, where genuinely needed, use DirectQuery against a well-indexed, summarised table rather than raw events.

Expecting Power BI to replace a line screen usually disappoints everyone. Using each tool for the audience it suits works well.

Time zones and production days

Two time issues catch most first Power BI production reports.

• UTC in the service. The Power BI service works in UTC, so functions such as "today" and "now" can return a different date to the one the plant is living in, especially for Australian sites many hours ahead of UTC. Store local time and UTC explicitly in the data, and use the stored local time for reporting.
• Production days and daylight saving. A night shift that starts at 10 pm belongs to one production day, not two calendar days, and daylight-saving changes create a 23-hour and a 25-hour day each year. Put the production day and shift in the shift calendar dimension so reports do not have to work it out.

Security and ownership

The on-premises data gateway connects Power BI to a database on the site network using an outbound connection. Place the reporting database, or a replica of it, where the gateway can reach it without opening a path into the control network. Give Power BI a read-only account on curated views, not on the raw tables. Decide early who owns the data set: most plants do best when engineering owns the production data layer and definitions, and the BI team owns the reports built on it.

What this means

Power BI is a good surface for production reporting when it sits on top of a well-built production data layer. Collect and contextualise data on the plant side, calculate OEE and downtime there with one set of definitions, model the result as a simple star schema, and design around refresh and time-zone limits. Keep second-by-second views in SCADA, and let Power BI do what it does best for managers.

If you want production data delivered to Power BI with the calculations done properly upstream, speak with an engineer. Our Chobani OEE platform case study shows shift and weekly management reports built from PLC data.