Shop Floor Data Standardisation: How UNS and PackML turn raw machine signals into actionable intelligence
Publicado às 18 de setembro de 2026 em Indústria 4.0
Many manufacturers who have invested in industrial analytics arrive at the same uncomfortable realisation at some point: the analytics problem is actually a data problem.
Dashboards are incomplete because certain machines do not connect reliably. AI models produce inconsistent results because the same variable is named differently across lines, measured in different units, and sampled at different rates. Adding a new data feed for a pilot project requires weeks of integration work because the wiring diagram between the shop floor and the IT layer is understood by nobody in full.
These are symptoms of an architecture problem that predates the analytics ambition. Two standards, used together, form the backbone of a modern shop floor data infrastructure that solves it: the Unified Namespace and PackML.
These are symptoms of an architecture problem that predates the analytics ambition. Two standards, used together, form the backbone of a modern shop floor data infrastructure that solves it: the Unified Namespace and PackML.
The data and connection problem beneath the analytics problem
Industrial equipment communicates through a wide variety of protocols such as OPC-UA, Modbus, PROFINET, EtherNet/IP, and proprietary formats specific to individual machine vendors. Every vendor and every legacy system speaks a different language.
Each system on the shop floor tends to connect only to the systems it was integrated with at the time of installation, creating a web of direct point-to-point connections that accumulates over years into what engineers typically call the ‘spaghetti’ architecture.
This creates two compounding problems. The first is the poll-and-push trap: systems continuously polling each other for updates, regardless of whether anything has changed, generating unnecessary data traffic and creating latency that makes real-time decisions difficult. The second is the data chaos problem: even when data is accessible, it is inconsistent. The same physical measurement, production speed, for example, may be labelled differently, expressed in different units, and stored in a different data type across three machines on the same line. Cross-line comparison requires a translation layer. Cross-site analysis requires several. Before any meaningful analytics can be built, that data has to be cleaned, harmonised, and contextualised.
When someone needs a new data feed for a dashboard or an AI model, building it requires understanding the entire wiring diagram from scratch. It is one of the most significant barriers to industrial AI and advanced analytics in practice.
Each system on the shop floor tends to connect only to the systems it was integrated with at the time of installation, creating a web of direct point-to-point connections that accumulates over years into what engineers typically call the ‘spaghetti’ architecture.
This creates two compounding problems. The first is the poll-and-push trap: systems continuously polling each other for updates, regardless of whether anything has changed, generating unnecessary data traffic and creating latency that makes real-time decisions difficult. The second is the data chaos problem: even when data is accessible, it is inconsistent. The same physical measurement, production speed, for example, may be labelled differently, expressed in different units, and stored in a different data type across three machines on the same line. Cross-line comparison requires a translation layer. Cross-site analysis requires several. Before any meaningful analytics can be built, that data has to be cleaned, harmonised, and contextualised.
When someone needs a new data feed for a dashboard or an AI model, building it requires understanding the entire wiring diagram from scratch. It is one of the most significant barriers to industrial AI and advanced analytics in practice.
The Unified Namespace
The Unified Namespace (UNS) addresses the integration problem by replacing the point-to-point model with a publish-subscribe architecture. Rather than building direct connections between producers and consumers, every data source publishes its data to a central broker, and every data consumer subscribes to the feeds it needs. Adding a new consumer requires no changes to the source systems.
The most common implementation uses MQTT (Message Queuing Telemetry Transport) as the messaging protocol. It is a lightweight publish/subscribe protocol designed for exactly the conditions industrial environments impose: unreliable networks, constrained devices, and the need for low-latency delivery. Specifically, the Sparkplug B specification adds report-by-exception behaviour: devices publish updates only when values change beyond a defined threshold, rather than on a continuous polling cycle.
The namespace structure follows the ISA-95 hierarchy:
Enterprise
└── Site
The most common implementation uses MQTT (Message Queuing Telemetry Transport) as the messaging protocol. It is a lightweight publish/subscribe protocol designed for exactly the conditions industrial environments impose: unreliable networks, constrained devices, and the need for low-latency delivery. Specifically, the Sparkplug B specification adds report-by-exception behaviour: devices publish updates only when values change beyond a defined threshold, rather than on a continuous polling cycle.
The namespace structure follows the ISA-95 hierarchy:
Enterprise
└── Site
└── Area
└── Line
└── Cell / Equipment
└── Tags (state, metrics, events, alarms)
Every data point has a predictable address in that hierarchy. Any system that understands the structure can navigate to any data point without custom integration work, making the architecture inherently scalable.
Every data point has a predictable address in that hierarchy. Any system that understands the structure can navigate to any data point without custom integration work, making the architecture inherently scalable.
PackML
The UNS solves the data integration architecture problem. PackML solves a different but closely related problem: the fact that every machine on the line describes its own operational states in a different way.
One machine reports "running", "faulted", and "idle". Another reports "auto", "E-stop", and "standby". A third uses numeric codes. When a plant has machines from multiple manufacturers (which is the norm) any analysis that spans machine boundaries requires a translation layer. PackML eliminates that layer by defining a standard state model that all machines can adopt:
Stopped ──► Resetting ──► Idle ──► Starting ──► Execute (Running) │ Completing │ Complete ──► Resetting
In a PackML-compliant environment, every machine uses the same state names and transitions. Performance metrics, such as actual speed, target speed, product count, reject count, are published under standardised tag names. When machines from different vendors both speak PackML, comparing their performance requires no translation. The data is directly comparable.
One machine reports "running", "faulted", and "idle". Another reports "auto", "E-stop", and "standby". A third uses numeric codes. When a plant has machines from multiple manufacturers (which is the norm) any analysis that spans machine boundaries requires a translation layer. PackML eliminates that layer by defining a standard state model that all machines can adopt:
Stopped ──► Resetting ──► Idle ──► Starting ──► Execute (Running) │ Completing │ Complete ──► Resetting
In a PackML-compliant environment, every machine uses the same state names and transitions. Performance metrics, such as actual speed, target speed, product count, reject count, are published under standardised tag names. When machines from different vendors both speak PackML, comparing their performance requires no translation. The data is directly comparable.
PackML meets UNS: the combination that enables cross-line analytics
When PackML-compliant machines publish their standardised state and tag data into a UNS via MQTT, the result is a shop floor data backbone where
- Every machine speaks the same data vocabulary
- Every data point lives at a predictable address in the ISA-95 hierarchy, and
- Every consumer receives data only when something changes, via Sparkplug B report-by-exception
The integration overhead that previously made cross-line analytics a months-long project becomes a configuration exercise.
Edge-level data filtering
The UNS and PackML create a clean, standardised data architecture. But a large factory with hundreds of PLCs, thousands of sensors, and dozens of production lines can easily generate tens of millions of data points per minute. Sending all of that to a cloud analytics platform is expensive, introduces latency that makes real-time decisions at the machine level impossible, and degrades the signal-to-noise ratio for the models consuming it.
Intelligent edge-level data filtering addresses this directly. The edge layer is where raw OT data from PLCs, sensors, and fieldbus systems is collected, translated into standard formats, pre-processed, and selectively forwarded upstream. It is the intelligent boundary between the physical process and the information systems that analyse it.
Two filtering techniques do most of the work. Dead-band filtering suppresses updates when a value changes by less than a defined threshold. For example, a temperature sensor that fluctuates by 0.1°C around a stable setpoint sends no update at all. Aggregation calculates summary statistics, such as averages, min/max, standard deviations, at the edge over a defined time window, forwarding a single summary value rather than thousands of raw readings.
Intelligent edge-level data filtering addresses this directly. The edge layer is where raw OT data from PLCs, sensors, and fieldbus systems is collected, translated into standard formats, pre-processed, and selectively forwarded upstream. It is the intelligent boundary between the physical process and the information systems that analyse it.
Two filtering techniques do most of the work. Dead-band filtering suppresses updates when a value changes by less than a defined threshold. For example, a temperature sensor that fluctuates by 0.1°C around a stable setpoint sends no update at all. Aggregation calculates summary statistics, such as averages, min/max, standard deviations, at the edge over a defined time window, forwarding a single summary value rather than thousands of raw readings.
The cloud cost equation
The financial case for edge filtering is straightforward. A 50-machine factory where each machine exposes 200 tags at one-second polling resolution generates approximately 10,000 data points per second, or 864 million per day. At typical cloud IoT platform pricing of €0.10–0.30 per million messages, that is €86–260 per day in ingestion costs alone, before storage or processing. Applying report-by-exception and dead-band filtering at the edge, reducing message volume by 90%, changes the picture significantly:
Filtered: 86 million messages per day → €9–26 per day in ingestion costs
Storage requirements reduced proportionally
Stream processing load reduced, enabling smaller and cheaper compute tiers
In practice, a cloud-only architecture for a site of this size runs roughly €3,000–4,500 per month. An edge-filtered architecture brings that to approximately €400–600 per month. The edge hardware investment typically pays back in under three months, and the five-year saving exceeds €150,000 for a single site, before the value of faster, more reliable decisions is counted.
Filtered: 86 million messages per day → €9–26 per day in ingestion costs
Storage requirements reduced proportionally
Stream processing load reduced, enabling smaller and cheaper compute tiers
In practice, a cloud-only architecture for a site of this size runs roughly €3,000–4,500 per month. An edge-filtered architecture brings that to approximately €400–600 per month. The edge hardware investment typically pays back in under three months, and the five-year saving exceeds €150,000 for a single site, before the value of faster, more reliable decisions is counted.
From data to decisions: what this architecture enables
Real-time production dashboards without integration projects. With every machine publishing standardised data to a common namespace, dashboards can be built by subscribing to the relevant topics. No bespoke integration, no dependency on a specific vendor's API.
Multi-line and multi-site comparative analytics. Because PackML enforces a common vocabulary and the UNS provides a consistent address structure, comparing the performance of line 3 in one plant with line 3 in another becomes a data query rather than an integration project.
AI and machine learning with clean, contextual data. Models receive structured, labelled, consistently formatted data rather than raw, inconsistent signals. The quality of the input directly determines the quality of the output. This architecture removes one of the most common reasons AI pilots fail to reach production.
Faster machine-level decisions without cloud dependency. By moving AI inference and control logic to the edge, decisions that depend on millisecond response times — closed-loop quality control, safety interlocks, real-time process adjustments — can execute locally without waiting for a cloud round-trip.
Multi-line and multi-site comparative analytics. Because PackML enforces a common vocabulary and the UNS provides a consistent address structure, comparing the performance of line 3 in one plant with line 3 in another becomes a data query rather than an integration project.
AI and machine learning with clean, contextual data. Models receive structured, labelled, consistently formatted data rather than raw, inconsistent signals. The quality of the input directly determines the quality of the output. This architecture removes one of the most common reasons AI pilots fail to reach production.
Faster machine-level decisions without cloud dependency. By moving AI inference and control logic to the edge, decisions that depend on millisecond response times — closed-loop quality control, safety interlocks, real-time process adjustments — can execute locally without waiting for a cloud round-trip.
How OMRON can support
Implementing UNS and PackML does not require replacing existing equipment or systems. Most PLCs and industrial controllers can be configured to publish data via MQTT brokers using standard edge gateway software, and PackML compliance can be retrofitted through gateway-level translation for machines that do not natively support it. The typical starting point is a single production line or cell: deploy the edge infrastructure, validate the data model, then scale.
OMRON's i-BELT service covers exactly this layer of the transformation. From IT-OT architecture design and data model definition through to edge deployment and integration with enterprise systems, and as part of a broader assessment that connects data infrastructure decisions to the specific production KPIs the business is trying to improve. For more information, please visit:
i-BELT Service
Contact us for more information
OMRON's i-BELT service covers exactly this layer of the transformation. From IT-OT architecture design and data model definition through to edge deployment and integration with enterprise systems, and as part of a broader assessment that connects data infrastructure decisions to the specific production KPIs the business is trying to improve. For more information, please visit:
i-BELT Service
