This article explains why ISA-95 is a valid data architecture choice, how it combines with Sparkplug B in a UNS architecture, and where semantic normalization must concretely take place — at the edge level, before data reaches any consumer.
- The Industrial integration problem
- UNS: a convincing pattern with a structural limitation
- Why ISA-95 is a valid data architecture choice
- ISA-95 e Sparkplug B: two standards, one semantic problem
- Where normalization happens: the Edge layer - FULL GUIDE
THE CONTEXT — Industrial data integration
Industrial data integration has a well-known problem: every new machine, every new consumer application, and every new plant adds yet another point-to-point mapping to maintain.
VIEW FULL GUIDE →
Unified Namespace (UNS) has become the reference pattern for industrial data architecture. But an MQTT broker at the center does not solve the problem of meaning: without a shared vocabulary, topics remain local conventions and the fragmentation problem reappears one level higher.
The idea is compelling: an MQTT broker at the center, a single shared semantic space, and all systems (MES, ERP, analytics, SCADA) instead of talking to each other directly, connect to that single central point and receive only the data they need.
Over time, this transforms "connecting a factory" into an ever-growing network of custom translation logic: fragile, expensive to extend, and difficult to verify.
WHITE PAPER PDF →
In practice, UNS is not a product you install, it is an architectural pattern. Like any pattern, it only works if it rests on solid foundations.
The problem that almost always emerges in real-world implementations is not the broker: it is the semantics.
The reason is structural: UNS provides transport and distribution infrastructure, but it does not solve the problem of meaning.
ISA-95 as the Semantic Layer
This is where ISA-95 becomes the layer that transforms UNS from a simple broker into a truly effective system: it provides the vocabulary, the hierarchy, and the relationships that make data interpretable in the same way by any system.
ISA-95, the international standard for integration between enterprise systems and control systems, provides a common semantic model — a shared vocabulary and hierarchy (Enterprise → Site → Area → Line → Cell → Equipment) — that allows data to maintain consistent meaning as it moves from the shop floor to business systems.
Why ISA-95 Is a Valid Data Architecture Choice
Most industrial data problems are not actually connectivity problems. Connecting to a PLC or a sensor is a largely solved problem; there are established protocols and gateways for almost every need.
The harder and more expensive problem is semantic. Once connected to a hundred machines from a dozen different vendors, how do you ensure that data means the same thing to everyone who needs it — the maintenance engineer, the MES, the ERP, the plant manager's KPI dashboard, and a data scientist training a predictive model?
ISA-95 (formally IEC/ISA 62264) exists to answer this question.
Its primary contribution is a shared vocabulary and hierarchy: Enterprise, Site, Area, Line, Cell, Equipment — along with a set of object models (Equipment, Material, Process Segment, Personnel) that describe how production entities relate to each other, independently of any specific vendor, protocol, or software architecture.
This independence is what makes it a good architectural foundation, because it guarantees:
- Vendor and protocol independence. Machine data means the same thing regardless of whether it reaches an application via OPC-UA, Kafka, MQTT, SQL, or Modbus, and regardless of which automation vendor is used. This decouples the data architecture from equipment lifecycle decisions.
A machine, a gateway, or an entire automation vendor can be replaced without having to rewrite data interpretation for downstream systems.
- Interoperability across the IT/OT boundary. MES, ERP, analytics platforms, and historians can all consume the same normalized model instead of each requiring its own custom translation layer.
This is precisely the boundary ISA-95 was designed to bridge: between manufacturing operations (Level 3, typically the MES) and the physical process with control systems such as PLCs and SCADA (Levels 0–2).
- Scalability of integration effort. Point-to-point integration grows combinatorially: every new machine and every new consumer application multiplies the number of custom mappings required.
A shared semantic model, by contrast, grows linearly. A new machine is inserted once into the existing hierarchy, and every consumer already present understands it immediately.
- Longevity and lower total cost of ownership. Adopting a common data model has a real upfront cost, but it is paid only once.
The alternative — ad hoc mapping, one integration at a time, continues to pay an integration "tax" indefinitely, one that compounds as the plant, or the company, grows.
- A shared language across roles, not just across systems. ISA-95's vocabulary gives OT engineers, IT architects, and business stakeholders a common way to talk about the same production reality, reducing the loss of meaning that occurs when each group falls back on its own local jargon.
- A foundation for higher-value use cases. Cross-plant benchmarking, enterprise-level KPI roll-ups, and machine learning models trained across multiple lines or sites all depend on data that means the same thing wherever it comes from — something structurally impossible if "Line 3" at one plant and "Line 3" at another encode incompatible local conventions.
None of this requires adopting a specific software stack or transport protocol and that is precisely the point. ISA-95 provides the semantic scaffolding; the underlying technology choices remain open.
Alleantia Core fully supports these principles, and goes further by guaranteeing standardized semantics for the complete machine dataset.
Download Full guide →
WHITE PAPER
Want to see how Alleantia Core normalizes your plant's data?
The semantic level
ISA-95 and Sparkplug B: Two Standards, One Problem
The semantic problem in UNS actually has two distinct dimensions, and confusing them is one of the most common design mistakes.
The first dimension is where data lives in the namespace — that is, the structure of MQTT topics.
ISA-95 addresses this aspect: it acts as a shared vocabulary independent of protocol, vendor, and software architecture.
When MQTT topics follow this hierarchy, "oven temperature line 3" and Line3_Oven_T become Site/Milan/Area-A/Line3/Oven/Temperature and Site/Barcelona/Area-A/Line3/Oven/Temperature: the same structure, with meaning that is immediately readable by any consumer.
The second dimension is how that data is formed when it arrives that is, the payload. This is where Sparkplug B enters: the specification that defines the standardized format for MQTT messages.
Explicit data types, node lifecycle management, birth and death certificates that make the broker the source of truth for the state of connected devices and their lifecycle.
ISA-95 → struttura dei topic Standardized semantic hierarchy: where each piece of data resides in the namespace, with a meaning shared across systems, vendors, and plants.
Sparkplug B → formato del payload Structured MQTT messages with explicit typing, birth/death certificates, and node lifecycle management: the layer that completes end-to-end semantics.
Neither standard imposes a specific technology stack — and this flexibility is precisely the point. They provide the semantic scaffolding; specific architectural choices remain open.
Applying this semantics to real data — 15-year-old PLCs, CNC controllers from different vendors, sensors with proprietary protocols — is an edge layer problem: that is where the translation must happen, once, before data reaches any consumer or broker.
Alleantia Core and ISA-95 - The foundation for structured and maintainable factory integration. Let's see how these principles translate into practice.
DOWNLOAD THE IN-DEPTH WHITE PAPER
WHITE PAPER
Want to see how Alleantia Core normalizes your plant's data?
