Every few years, some new platform capability makes people announce that SCADA, MES, and the historian are “converging.” Ignition can act as a historian now. Unified Namespace (UNS) architectures push context all the way to the edge. Edge gateways run analytics that used to require a server rack in the plant IT closet. Each of these is a real, useful development. None of them actually collapses the boundaries between control, history, and execution — they just make it easier to blur them by accident, which is a different problem entirely.
The confusion isn’t really about technology. It’s about function. If you know what job a layer is supposed to do, it doesn’t matter whether Ignition, a dedicated MES suite, or a cloud time-series database is doing it. The tool is negotiable. The function isn’t. So let’s rebuild the mental model from the ground up, using function instead of product category, and then apply it to the situations that are actually causing the confusion right now.
Four Jobs, Not Three Boxes
Most confusion starts because people think in terms of three products — SCADA, MES, Historian — when there are actually four distinct jobs happening in a manufacturing stack. Naming the fourth one is what fixes the mental model.
1. The control loop
This is the job of keeping a process or machine doing what it’s supposed to do, in real time, with deterministic timing. PLCs, DCS controllers, and SCADA systems live here. SCADA’s core responsibility is supervisory: visualize the process, let operators intervene, execute setpoint changes, and raise alarms when something is out of bounds. The defining trait of this layer is that it operates on a control-loop timescale — milliseconds to seconds — and its data is transient by nature. A SCADA screen shows you the current state of a tank level. It is not the system of record for what that tank level was two shifts ago.
2. History
This is the job of remembering. A historian’s entire reason for existing is to capture time-series data — tags, values, timestamps — at high resolution and retain it efficiently, usually with compression schemes like swinging-door or boxcar-backslash. It answers “what happened, and when.” A historian doesn’t know what a batch is, what a work order is, or what “good” looks like for a specific product. It just remembers numbers extremely well and for a long time.
3. Context
This is the job UNS architectures are actually solving, and it’s the one most people skip when they list out “the three systems.” Context means taking raw tag data and attaching meaning to it: this value belongs to this machine, on this line, in this area, at this site, and it corresponds to this batch or this work order. MQTT Sparkplug B payloads structured into a namespace hierarchy are a context mechanism, not a historian and not an MES. UNS is middleware for meaning, not a system of record for anything by itself.
4. Execution
This is MES territory, and it’s the job most often shortchanged when people try to make SCADA or a UNS broker do double duty. Execution means managing the business logic of production: work orders, routings, genealogy, quality holds, material consumption, operator work instructions, and the transactional record of what was actually built, by whom, against what specification, with what disposition. ISA-95’s Level 3 definition maps almost exactly onto this. MES doesn’t control the machine and it doesn’t remember raw sensor history — it owns the record of production activity and the rules that govern it.
Why Ignition-as-Historian Doesn’t Change the Framework
Ignition’s built-in historian capability (and similar features in other modern SCADA/HMI platforms) is a genuinely useful consolidation — fewer licenses, fewer integration points, one less system to patch and secure. But it’s a deployment decision, not a boundary decision. The historian function still exists as a distinct job even when it runs inside the same platform as your SCADA visualization. The failure mode to watch for isn’t “using Ignition as a historian” — it’s letting the convenience of co-location tempt you into writing execution logic (work order state, quality disposition, genealogy) into SCADA scripting because the data’s sitting right there. That’s how you end up with production logic embedded in tag change scripts that no one can find during an audit, duplicated in the MES a year later because nobody trusted the SCADA version, and now you’re reconciling two systems that both think they’re the record of truth.
UNS Is Plumbing, Not a Layer That Owns Anything
UNS deployments generate a similar temptation from the other direction. Because a well-built namespace carries rich context — site/area/line/machine, tied to batch or order IDs — it’s easy to start treating the broker itself as if it were the system of record for production state. It isn’t, and it shouldn’t be asked to be. A message broker has no durable transactional guarantees for business state, no built-in concept of a work order lifecycle, and typically no audit trail suitable for regulated environments. UNS earns its value by making it cheap and consistent to move contextualized data between the layers above — feeding a historian, feeding MES, feeding an analytics or ML model — not by replacing what those layers do. If your UNS topic structure is the only place that “knows” what job is currently running on a line, you’ve quietly made your middleware into a system of record by accident, and middleware failure modes (broker restarts, retained message loss, schema drift) are not what you want your production record to depend on.
Edge Computing: Push Logic Down, Not Ownership
Edge gateways running local analytics, protocol translation, or even lightweight ML inference are increasingly common, largely because sending everything to the cloud or a central server has real bandwidth and latency costs. The framework question to ask isn’t “can this run at the edge” — plenty of things can — it’s “which job is this edge device actually doing.” An edge gateway calculating OEE component availability from PLC states is doing execution-adjacent work and its output belongs in MES or a reporting layer, not just a local dashboard. An edge device buffering and forwarding time-series data during a network outage is doing a historian’s job (temporarily) and should reconcile with the historian of record once connectivity returns. Edge computing changes where computation physically happens. It should not change who owns the resulting record.
A Working Test for New Tools
When you’re deciding where a new capability belongs, ask these in order:
- Does it need to act within a control loop’s timescale? If yes, it’s SCADA/control territory, regardless of what platform hosts it.
- Is its core job to remember values over time for later retrieval? If yes, it’s historian territory, even if it’s a feature bolted onto something else.
- Is its core job to attach meaning and route data, without owning business state? That’s context/UNS territory — useful, necessary, but not a record of truth.
- Does it need to enforce business rules, track work orders, or produce an auditable production record? That’s MES, full stop, and no amount of clever scripting elsewhere should substitute for it.
The practical payoff of this framework is that it lets you evaluate a new tool — Ignition’s historian module, a UNS broker, an edge analytics box — on what job it’s actually doing, instead of what marketing category it’s sold under. Products will keep bundling functions together because that’s good business. Your architecture diagram should keep the functions separate anyway, because the day you need to trace a quality escape back through genealogy, you want exactly one system that can answer “what actually happened here,” not three systems that each remember it a little differently.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
