sam.donche@edge ← notes

// Notes

MES vs SCADA vs historian: what actually goes where.

2026-07-23 · 4 min read · Industrial architecture

Ask three vendors which of these you need and you’ll get three answers, usually the one they sell. But MES, SCADA and a historian aren’t competitors, and they aren’t interchangeable. They’re three layers of a factory’s data stack, and each one answers a different question. Most industrial data projects that stall do so because someone asked one layer to do another’s job. Here’s how I keep them straight.

SCADA: what’s happening right now

SCADA, and the HMI screens on top of it, is the live view of the plant floor. It reads values off PLCs and devices in real time, shows operators what’s running, and lets them act on it: start a line, acknowledge an alarm, nudge a setpoint. Its entire reason for existing is the here and now: low latency, current state, control.

It’s built for real-time monitoring and supervisory control. What it isn’t built for is keeping years of data or running your reports. Most SCADA holds only a short buffer of history, so the moment you lean on it as your long-term record, you’re fighting the tool.

Historian: what happened, and how much

A historian is the plant’s memory. It captures tag values over time, often thousands of them at high frequency, and stores them so you can go back and ask what a line was doing last Tuesday at 3 a.m., or trend a temperature across a month. It’s purpose-built for time-series: fast writes, efficient storage, queries across long spans.

Its job is the durable, queryable record of process data. It is not your real-time control layer, and it’s not your reporting application either. A historian answers “what were the values.” Turning that into a shift report or a dashboard belongs to the layer above.

MES: is the order getting made right

MES works at a different altitude. It isn’t about individual tag values; it’s about production. Which work order is running on which line, whether it’s being made to spec, what the yields and losses were, where a given batch actually came from. It orchestrates and records the making of things, and it’s usually the bridge between the plant floor and the business systems (ERP) above it.

Its job is work orders, tracking and genealogy, quality and OEE: production as a managed process. It is not a historian and not a SCADA; it leans on both. It needs live state from the floor and history to reason about.

These are functions, not products

Notice I’ve described what each layer does, not what to buy. That’s deliberate. These are functions, not products, and one platform can cover more than one. I build SCADA in Ignition, and I often build MES capability in Ignition too, because it’s open enough to go well beyond supervision. For the historian I reach for Factry, or TimescaleDB when I want the history to live in SQL.

The point isn’t the logo; it’s that the functions stay distinct even when a single tool implements several of them. That openness is a gift and a trap: a platform flexible enough to do everything will happily let you blur the layers, which is exactly why keeping them straight in your head matters more, not less.

Where it goes wrong

The failure mode is always the same: one layer doing another’s job. Reporting built inside SCADA because “the data’s already there.” A historian queried directly for business reports it was never designed to serve. An MES asked to double as the real-time control system. Every one of those shortcuts looks reasonable on day one and turns brittle by month six.

I’ve done it myself. I built reporting straight into an Ignition project because it was faster than standing up something separate, and it worked until it didn’t; the fix was moving that logic to where it belonged. The lesson I keep relearning: pick the right layer for each job instead of making one platform do everything.

How they fit together

Treated as layers instead of rivals, it’s simple:

  • SCADA reads and controls the floor, in real time.
  • The historian records what happened, durably.
  • MES orchestrates and accounts for production.
  • Reporting, analytics and AI sit on top, reading from the historian and MES, not scraping SCADA.

Data flows up, control flows down. Get that layering right and everything downstream gets easier, because each new thing you build plugs into a foundation that’s already there. Get it wrong and you rebuild, which is exactly the pattern behind a factory whose data technically “exists” but nobody trusts.

None of this means buying all three at once. It means knowing which question you’re actually trying to answer, and putting the work in the layer that owns it. That, more than any single product choice, is what keeps a factory’s data trustworthy.

Untangling this on your own floor? That’s the kind of architecture I help manufacturers get right.

Get in touch

← all notes