Industrial Dashboard Software: 6 Tools Compared

Ask ten engineers what a dashboard is and you get ten answers. One means a Grafana page showing motor current. One means a trend client pulled from the historian. One means a Power BI report the plant manager opens on Monday.

They are not the same product. They do not sit in the same place on the network. And they do not talk to the same things.

This guide sorts industrial dashboard software by one question: how does the tool get its data? That single question decides everything else — where you install it, what it costs, and whether it belongs anywhere near the control network.

1. Two Layers, One Boundary

Everything in this guide sits above that boundary. None of these tools run a plant. They show you what a plant did, and in some cases what it is doing right now.

The mistake people make is picking a Layer 1 tool for a control job. Grafana looks great in a demo. Then someone asks it to acknowledge an alarm or write a setpoint, and the whole thing falls apart — because that was never what it was built to do.

2. Which Layer Do You Actually Need?

Four questions settle it.

Do you already have a historian or time-series database? Yes → Layer 1 is the cheapest path by a wide margin. No → you need something that can poll and store.

Do you need to write values back to the process? No → Layer 1. Yes, but only setpoints on a small machine → Layer 2. Yes, and operators depend on it → you need SCADA, not a dashboard.

How many sites and how many tags? Under a few hundred tags at one site → Layer 2 is enough. Thousands of tags across sites → put a historian in the middle and use Layer 1.

Who maintains it? An IT team that knows Docker and SQL → either layer works. An automation team with no server experience → buy a commercial client that came with the historian.

3. Layer 1 — Historian Visualization Clients

These tools store nothing and poll nothing. Point them at a historian or a database, pick your tags, get a trend. That limitation is also their strength: they are cheap to deploy, they scale to a lot of users, and they cannot break your process.

Every historian ships with a client like this. The question is usually not whether to use one, but whether the one that came in the box is good enough.

3.1 Grafana

The default choice for time-series data, industrial or not.

Grafana is a rendering engine with a good query builder. It expects the data to already be somewhere. In a plant, that “somewhere” is usually InfluxDB or TimescaleDB, filled by Telegraf or Node-RED reading from PLCs.

People ask constantly whether Grafana can read OPC UA directly. The honest answer has gotten worse, not better. The OPC UA datasource that once lived under Grafana’s own GitHub organization was deprecated and reached end of life in mid-2024. What remains is a mix of paid marketplace plugins and vendor-specific ones tied to a particular OPC UA server product.

None of them buffer data during an outage, and they poll on dashboard refresh rather than on a scan cycle. Treat direct protocol plugins as a lab convenience. For anything that has to keep working, put a collector in front and store the data first.

Best for: engineering trends, energy dashboards, KPI screens, anything already landing in a time-series database.

3.2 AVEVA PI Vision

The web display client for the AVEVA PI System. If a plant runs PI, this is how people look at it.

PI Vision replaced ProcessBook as the standard way to build displays on PI data. The asset framework is the real advantage: displays follow the asset model, so a “compressor” display works on all forty compressors without editing anything.

The constraint is absolute. PI Vision reads PI and nothing else. If your data is not in PI, this tool has nothing to show you.

Best for: plants already running the PI System, process industries, enterprise-wide operational reporting.

3.3 Canary Axiom

The browser-based trending and dashboard client for the Canary historian.

Canary sits in the mid-market gap — more capable than a SCADA’s built-in trend screen, far less expensive and less heavy than a full PI System.

The MQTT publisher is worth knowing about. It turns the historian into a data source for anything else on the network, which is a clean way to feed cloud dashboards without opening a path back in.

Best for: mid-size plants, teams that want a historian and trending without an enterprise project.

Close, but not dashboards

Two categories get compared to these tools constantly and belong in neither layer.

Business intelligence — Power BI, Superset, Metabase. They read SQL well and time-series data poorly. No asset model, no tag quality, no deadbands, no interpolation. They still show up in plants one layer further out, building monthly production and downtime reports from data a historian already aggregated. Fair use. Just do not point one at a live process database and expect it to behave.

Analytics workbenches — Seeq, TrendMiner, dataPARC. These connect to the same historians and start with a trend, but the job is different: cleansing signals, finding periods of interest, aligning batches, correlating variables. They are built for one engineer digging into a question, not for a screen fifty people watch. Buy one when your engineers export historian data to Excel every week — that habit is the symptom they treat. Do not buy one expecting operator displays.

4. Layer 2 — Dashboards With Built-In Drivers

These tools do both jobs. They poll devices and draw the screen. That makes them far more useful on a plant floor — and it also means they sit on a network segment where a bad poll causes real trouble.

4.1 Node-RED Dashboard 2.0

Node-RED is a flow-based tool: you wire nodes together to move and transform data. Dashboard 2.0 — officially FlowFuse Dashboard — adds a web UI layer on top of those flows.

It is a full rebuild, not an update. The original dashboard ran on AngularJS, which stopped being maintained years ago and could not be patched safely. Dashboard 2.0 is built on Vue instead. If you are looking at old tutorials, check which one they use.

Node-RED is the glue in most open-source industrial stacks. Even when Grafana draws the final chart, Node-RED is often the thing reading Modbus registers and pushing them into the database.

Two catches. The dashboard is open core — the base nodes are Apache 2.0, but per-user dashboards are a paid FlowFuse feature. And flows grow fast: an unversioned Node-RED instance with 400 nodes becomes unmaintainable. Keep flows in Git, keep them small, and name your variables like someone else will read them.

Best for: protocol glue, edge gateways, small monitoring screens, prototypes.

4.2 FUXA

A web-based SCADA/HMI built on Node.js and Angular. It is the closest open-source thing to a real HMI editor that runs entirely in a browser.

FUXA gives you real HMI features: symbols, alarms with thresholds, user permissions, trends, and device control. No runtime license, no tag count limit. The Pro edition is a one-time €100 and adds white-label branding, event logging, and unlimited installations — worth knowing, because it is unusually cheap for anything in this category.

It is not built for a control room running a refinery. There is no redundancy story, and the project rests on a small team with community contributions. For a machine skid, a test bench, a water pumping station, or a remote site, it does a lot for almost nothing.

Best for: small standalone HMI, OEM machine screens, remote sites, retrofits.

4.3 ThingsBoard

An IoT platform with dashboards as a first-class feature. Native protocol support is MQTT, HTTP, CoAP, LwM2M, and SNMP. Industrial protocols come through a separate IoT Gateway component.

The device-and-asset model is what sets ThingsBoard apart. If you have 200 identical pumping stations, you build the dashboard once and it applies to all of them. Doing that in Grafana means template variables and discipline; here it is the native way to work.

The MQTT side is genuinely strong, and it is strong in the free Community Edition rather than behind a paywall. That makes ThingsBoard a natural fit for distributed assets — solar sites, water networks, vehicle fleets.

Best for: many similar sites, MQTT-based fleets, tenant separation, cloud deployments.

5. Where SCADA Platforms Fit

Ignition, WinCC Unified, AVEVA System Platform, FactoryTalk View, and zenon all ship web dashboards now. The screen is not what separates them from the tools above.

What separates them is everything behind it. A tag engine. Alarm acknowledgment and shelving that survives a restart. Redundancy. Audit trails. And a driver stack that reaches protocols no dashboard tool touches — DNP3, IEC 60870-5-104, IEC 61850.

That is a different purchase, and the numbers make it obvious. An Ignition platform license is $1,200 list. The Perspective module that actually draws the screens is $11,225. Then the license turns out to be the small part — engineering, screen design, database work, testing, and commissioning routinely run several times the software cost.

Which platform counts as “standard” also depends entirely on which room you are standing in. An automotive plant runs FactoryTalk View SE. A distribution control center down the road runs MicroSCADA X or SurvalentONE. Both are SCADA. Neither vendor bids on the other’s projects.

The short test: if an operator would pick up the phone when the screen goes dark, you need SCADA, not a dashboard.

If that is where you are, the most popular SCADA systems guide covers thirteen platforms sorted by where they actually get deployed, with licensing shapes and native protocol support for each. For the no-license-cost end, see the free SCADA software guide.

One edge worth naming honestly: FUXA sits on the boundary. It calls itself SCADA/HMI, it writes to devices, and it turns up in both conversations. The label is not the useful distinction. Whether anything with consequences depends on it — that is.

If nothing does, keep reading. A dashboard is cheaper, faster to stand up, and safer to hand to fifty people.

6. Protocol Reach: How Each Tool Gets Field Data

Layer 1 tools are absent from this table on purpose. None of them speak a field protocol at all — they read from a historian, and the historian’s own collectors handle OPC UA, OPC DA, and the rest. Their protocol reach is whatever sits underneath them.

Two things stand out. First, the bottom of that table is empty. No dashboard tool on the market speaks DNP3, IEC 104, or IEC 61850 directly. For utility and substation work you need a SCADA front end or a protocol gateway feeding a database, and the dashboard reads from there.

Second, everything speaks SQL. That is why the database-in-the-middle pattern is so common — it is the one interface every tool agrees on.

7. Two Reference Architectures

The open stack

Cost: zero in licenses. Cost in reality: someone has to own it. Four moving parts, four upgrade paths, four things that break at 2 a.m. This stack is excellent when you have an engineer who enjoys it and terrible when you don’t.

The split stack

This is what most working plants actually look like, and the direction of every arrow is the point. History flows outward. Nothing reaches back in.

Nobody with a browser and a KPI question ever touches the control network.

8. Why a Dashboard Should Stay Read-Only

A dashboard that can only read is a dashboard that cannot cause an incident. That is worth more than it sounds.

Every Layer 1 tool is read-only by design. That is exactly why they are safe to expose to a wide audience. Layer 2 tools can write — and the moment they can, they belong in a controlled zone with the same treatment as any other control system asset.

Practical rules that hold up on site:

• Put the dashboard where its data lives, not where its users are. Users reach it through a reverse proxy or VPN. The dashboard does not reach into the control network for them.
• One direction through the DMZ. Data flows out to the historian or broker. Nothing initiates a connection inward.
• Separate accounts from the SCADA system. A dashboard login should never be a SCADA login.
• Turn on TLS even internally. Grafana, ThingsBoard, and FUXA all support it, and most installs skip it because HTTP worked on day one.
• Log who changed what. Commercial historian clients do this natively. Open-source dashboards mostly do not.

The zone and conduit model in IEC 62443 covers this properly — see the OT cybersecurity guides for how the segmentation should actually be drawn.

9. Cost and Licensing

The honest note on “free”: open-source dashboards move the cost from a license line to a labor line. On a small system with an engineer who likes the work, that is a great trade. On a site with no IT support and a five-year uptime expectation, it usually is not.

10. FAQ

Can Grafana be used as SCADA software? No. Grafana has no tag engine, no alarm acknowledgment, no write path to devices, and no redundancy. It is a visualization layer. It works very well as the reporting face of a SCADA system, reading from that system’s historian.

What is the difference between a dashboard and an HMI? An HMI is used to operate the process — it reads and writes, and operators depend on it in real time. A dashboard usually only reads, and is used to understand the process rather than run it. Layer 2 tools blur the line; Layer 1 tools do not.

Can Grafana read Modbus or OPC UA directly? Not well. The OPC UA datasource that once sat under Grafana’s own GitHub organization was deprecated and hit end of life in mid-2024. What is left is paid marketplace plugins and vendor-specific ones tied to a particular server product. None buffer data during an outage, and all poll on dashboard refresh. For anything production-grade, put Node-RED or Telegraf in front and store the data first.

Is Ignition Perspective better than Grafana? They solve different problems. Perspective is an HMI that can control equipment, with alarms and audit trails, and it is a licensed SCADA platform rather than a free tool. Grafana is a free visualization layer with excellent charts and no control capability. Many plants run both, and that is usually the right answer.

PI Vision or Grafana for a plant that already runs PI? PI Vision, for operations displays. It understands the asset framework, so displays follow the asset model instead of hard-coded tag names. Grafana still earns a place for cross-system dashboards that mix PI data with production, energy, or quality data from other databases.

What is the cheapest way to get a web dashboard on a PLC? FUXA on a Raspberry Pi or industrial PC. Native Modbus, S7, and OPC UA, a drag-and-drop editor, built-in logging, no runtime license. Expect to do your own maintenance.

Which dashboard tools support IEC 61850 or IEC 104? None of them. Those protocols live in SCADA front ends and gateways. The usual path is a SCADA system or protocol gateway that speaks IEC 61850 or IEC 104, logs to a database, and lets a dashboard handle the display.

Do I need a historian, or can the dashboard store data? Every Layer 1 tool stores nothing — Grafana needs a database, and PI Vision and Axiom need a historian. Node-RED needs one too. FUXA and ThingsBoard include storage, though for long retention and heavy trending a dedicated historian still performs better.

Can I put a dashboard in the cloud and still keep the plant secure? Yes, if data only flows outward. An edge gateway publishes to MQTT or writes to a cloud database, and the dashboard reads from there. No inbound connection to the control network, ever. That pattern is how ThingsBoard and most cloud dashboards are deployed in practice.