Lokesh Chennuru What the standard says
ISA-95 — published internationally as IEC 62264 — is the standard for integrating enterprise and control systems. Two parts of it dominate practice:
- The level model. Level 0–1 is sensing and actuation; level 2 is supervisory control; level 3 is site operations — MES, historians, scheduling, quality; level 4 is enterprise business systems. It is a model of where functions belong, and which levels should and should not talk directly.
- The object models. ISA-95 defines structured ways to describe equipment hierarchy, material, personnel, and production schedules — the context that turns a raw tag into meaningful production information. (Its sibling ISA-88 does the same for batch recipes and procedures.)
The level diagram is often drawn as a strict vertical stack with data marching up one layer at a time. That depiction — not the standard’s object models — is what the unified-namespace movement reacts against.
What it means on the plant floor
A unified namespace (UNS) is, in practice, a single real-time message broker (commonly MQTT-based) where every system publishes to and subscribes from one structured, hierarchical view of the plant. Instead of dozens of point-to-point integrations climbing the ISA-95 stack, each system reads and writes a shared, contextualised topic tree.
The honest reading of the debate:
- The UNS does not delete ISA-95’s meaning. A topic like
site/area/line/machine/bearing/temperatureis an ISA-95 equipment hierarchy wearing different clothes. The context model is still doing the work; the broker only changes how messages move. - It does relax the strict layer-by-layer transport. A condition-monitoring service can subscribe to the data it needs without a chain of integrations through levels 2 and 3 — which is genuinely faster to build and easier to evolve.
- It does not relax the security boundary. A flat broker that any system can publish to is an IEC 62443 nightmare if the zones and conduits are not designed. “Flat for data, segmented for trust” is the reconciliation: one logical namespace, with controlled, often read-only, paths across security zones.
So the two ideas are not rivals. ISA-95 supplies the meaning (what the data describes); the UNS is one good answer to the transport (how it moves). A plant can hold the context model and adopt the broker, or keep a disciplined historian and skip the broker, depending on scale.
The three decisions this should change
- Settle the outcome before the topology. Decide what you actually need — contextualised, real-time, low-integration-friction data — and judge any UNS proposal or historian-centric design against that outcome, not against which camp it belongs to. The outcome is the requirement; the broker is an option.
- Keep the context model whatever the transport. Equipment hierarchy, units, operating state, and timestamps have to live somewhere. Adopt ISA-95’s object model (and ISA-88 for batch) as the shared vocabulary so a tag stays meaningful whether it travels up a stack or through a broker. Skipping this is how a UNS becomes a fast firehose of meaningless topics.
- Design zones and conduits before opening the namespace. A unified namespace and IEC 62443 segmentation are complementary, not contradictory: one logical data view, with deliberate, monitored, least-privilege paths between security zones. Decide who can publish, who can only subscribe, and where the boundary sits — before the broker goes live.
Where it stops being useful
- The level diagram is a model, not a mandate. Treating ISA-95’s levels as a rule that forbids a service from reading data it needs is a misuse of the standard — that rigidity is exactly what the UNS movement rightly pushes back on. Use the levels to reason about function and trust, not to ban useful data flows.
- A namespace is not an architecture. A broker with a tidy topic tree and no governance — no naming standard, no ownership, no security model — scales chaos faster than spaghetti integrations did. The hard part was always the context and the boundary, and neither standard nor broker does that thinking for you.
- Vocabulary varies by site. ISA-95’s formal object models are heavier than many plants need. Borrow the hierarchy and state concepts that make your data legible; you do not have to implement the full standard to benefit from its discipline.
Sources
- ISA-95, Enterprise-Control System Integration International Society of Automation
- IEC 62264: Enterprise-control system integration International Electrotechnical Commission
- IEC 62443 series: Security for industrial automation and control systems International Electrotechnical Commission
Frequently asked
What is the ISA-95 model?
ISA-95 (international as IEC 62264) is a standard for integrating enterprise and control systems. It is best known for a level model — sensing and control at levels 0-2, site operations such as MES and historians at level 3, and enterprise systems at level 4 — and for object models that define how production information (equipment, material, schedules) is structured. Its lasting value is a shared vocabulary for where industrial functions and data belong.
Does a unified namespace replace ISA-95?
Not really — it rearranges the transport, not the meaning. A unified namespace (UNS) is typically a single message broker where every system publishes and subscribes to a structured, real-time hierarchy of plant data. It challenges the rigid layer-by-layer data flow ISA-95 is often drawn as, but it still needs ISA-95's context — equipment hierarchy, units, state — to make the messages meaningful. The argument is about topology, not about whether context matters.
Do I need a unified namespace?
You need the outcome a UNS promises — data that is contextualised, real-time, and accessible without point-to-point spaghetti — more than you need any particular product. A broker-based UNS delivers that well at scale; a disciplined historian and a clear ISA-95 model can deliver enough of it for a smaller plant. Decide on the outcome and the security boundary first, then choose the topology.