Industrial Data Contextualisation: From Raw Values to Meaningful Data

Industrial data contextualisation is the process of enriching the raw values produced by machines and sensors with the meaning they lack: which asset generated them, which unit they are in, which production order they belong to, which shift was on and what state the line was in. Without that context, a plant historian is a collection of numbers; with it, it is the foundation of indicators, traceability and models. In this guide we look at which layers of context exist, where each is added and how to govern the data model that holds them together.

What industrial data contextualisation is

A PLC does not know what it is manufacturing. When it publishes register 40012 with the value 1,847, that figure is true, but it is a mute truth: it does not say whether these are parts or millimetres, which machine it comes from, or whether the line was producing article A or article B. Somebody knows all of that (the programmer who mapped the register, the supervisor who released the order), but it does not travel with the data. Contextualisation is the discipline of attaching that knowledge to the value systematically, so that any consumer (a dashboard, an OEE calculation, a model) can use it without asking anyone.

It is worth distinguishing it from normalisation, with which it is often confused. Normalisation solves the form: coherent units, correct scales, source timestamps. Contextualisation solves the meaning: what this data is within the business. A platform needs both, and in that order: first a well-formed value, then a well-placed one.

Why raw data does not serve the business

The practical consequence of missing context is that every consumer has to reconstruct it on their own. The analyst who wants performance per product reference manually crosses the counter history with the ERP's order list; the engineer investigating a defective batch chases through three systems which machine, which parameters and which shift coincided; the management dashboard shows a total electricity consumption nobody can split by line. The cost is not in capturing the data, which was already captured: it is in interpreting it again and again, with different criteria each time.

That repeated reconstruction is also the main source of discrepancies between reports: two people crossing the same signals with slightly different rules produce two truths. Contextualisation attacks the root: the join is done once, with an agreed rule, and the result is published for everyone.

The five layers of context

Not all context is equal, nor is it added in the same place. It helps to think of it in five layers, from the most physical to the most business-oriented:

Signal context. Which magnitude it is, in which unit, with which valid range and which reading quality. It is the layer that turns register 40012 into "good parts counter, units, cumulative integer".
Asset context. Which machine, line, area and plant generated the value. It is expressed as a position in an asset hierarchy, and it is what makes it possible to aggregate by line or compare equivalent machines.
Production context. Which work order, which product reference and which batch were running when the value was produced. It is the layer that makes traceability and per-reference analysis possible.
Operational context. Which shift, which crew and what state the line was in (producing, stopped, changeover). Without it, an average speed mixes real production with stoppages and means nothing.
Business context. The dimensions that matter upstream: customer, sales order, energy cost of the period. It is usually added in the data layer, joining with the ERP, and it is what turns technical indicators into management information.

The canonical model: names and hierarchy

All the layers above need a common skeleton: a canonical data model that defines what things are called and how they are organised. In practice it has two pieces. The first is the asset hierarchy (plant, area, line, machine, signal), which in a modern architecture materialises as the topic tree of the unified namespace: a data point's position in the tree already is asset context. The second is the signal dictionary: for each signal type, its business name, its unit and its semantics, identical across all equivalent machines. If spindle temperature has the same name on all four injection machines, comparing machines is a query; if it has four names, it is a project.

The canonical model is not a decorative document: it is a contract. When contextualised datasets are published to business consumers, that contract is formalised with an explicit schema, units and frequency, as we develop in the guide to industrial data contracts.

Where to contextualise: edge or platform

The architectural question is where each layer is attached. The short answer: each context is added at the point closest to where it is known, and as early as possible.

Context layer	Where it is added	Why there
Signal (unit, range, quality)	Edge, at capture	Only the edge sees the source; afterwards it is too late to know quality
Asset (machine, line, plant)	Edge, via position in the namespace	The gateway knows which device it listens to; the topic tree encodes it
Production (order, reference, batch)	Data layer, joining with MES or ERP	The running order lives in the business systems, not in the PLC
Operational (shift, line state)	Data layer, with calendar and state logic	State is derived from several signals and from agreed rules
Business (customer, cost, sales order)	Data or analytics layer, joining with ERP	It changes over time and must not freeze the process data

The rule that orders the table: what describes the physical fact is frozen with the data at the edge; what interprets it is joined later in the data layer of the industrial data platform, where the historian keeps the detail and the transformations produce the contextualised datasets. Attaching the work order at the edge looks efficient, but it couples the gateway to the MES and turns every business-system change into a plant change.

A worked example: from signal to indicator

Let us walk the full path with a generic case. A packaging line has a cycle counter in the PLC that grows from 0 to 65,535 and rolls over. The business goal: good units per product reference and per shift.

Capture and signal context (edge). The gateway reads the counter every 2 seconds over Modbus, resolves the rollover, flags the quality and stamps the source timestamp. The value is now "accumulated cycles, units, reliable".
Asset context (edge). It is published in the tree under its line and machine branch. Any consumer knows where it comes from without an auxiliary table.
Production context (data layer). A join with the ERP's orders assigns each interval of cycles to the running order and reference. The counter's 43,200 daily values become segments per order.
Operational context (data layer). The shift calendar and the line-state signal separate real production from stoppages. An 8-hour shift with 90 minutes of stoppage contributes 6.5 hours of denominator, not 8.
Result. A contextualised table with date, shift, line, order, reference, good units and productive time. On top of it, the per-reference indicator is a trivial query, and the same table feeds dashboards, reports and models without reinterpreting anything.

Common mistakes when contextualising

Leaving contextualisation to analytics. "The analyst will join it later" means every analysis pays for the join again, with its own rules. Shared context is built once, in the platform, not in each analysis notebook.

Encoding business context in signal names. Putting the product reference or the customer name in the tag name freezes into the plant something that changes every week. Names encode what is stable (asset and magnitude); what varies is joined as data.

An improvised asset hierarchy. If each integrator invents their own branch of the tree, asset context degenerates into the same chaos as before, just better transported. The hierarchy is agreed in writing before connecting the second machine.

Line states without an agreed definition. If "stopped" means different things to production and to maintenance, every derived indicator inherits the ambiguity. State logic is a business decision that gets documented, not a technical setting.

Contextualising without keeping the raw data. Enriched data answers today's questions; the raw data with its timestamp answers tomorrow's. Contextualised datasets are published and the original detail is kept in the historian: it is never a replacement.

Frequently asked questions about contextualisation

What is the difference between normalising and contextualising industrial data?

Normalisation solves the form of the data: coherent units, correct scales, source timestamp, reading quality. Contextualisation solves its meaning: which asset generated it, which order and reference it belongs to, which shift and line state applied. The first happens at the edge during capture; the second is completed in the data layer by joining with the business systems.

Does contextualisation require having an MES?

No. Production context (order, reference, batch) can come from the MES if one exists, from the ERP or even from a structured manual declaration in small plants. What matters is that there is an agreed source of "what was being manufactured" and that the join with the signals happens once, in the platform, not in every analysis.

Where should contextualisation happen, at the edge or in the cloud?

In both, but by layers. At the edge you add what describes the physical fact and is only known there: unit, reading quality, source asset. In the data layer you join what interprets it: work order, shift, line state, business dimensions. Attaching business context at the edge couples the plant to corporate systems and complicates every change.

Where does a plant that only has raw data start?

With the canonical model and one use case: agree the asset hierarchy and the signal dictionary, pick an indicator that is calculated by hand today and build the full context chain for it, from the edge to the contextualised table. That first pass validates the rules and leaves the infrastructure in place, so contextualising the rest is incremental.

If your plant already captures data but every report demands joining it by hand again, at Captia Connect we build the chain that solves it: capture and normalisation at the edge, an agreed asset hierarchy and an industrial data platform where context is added once and serves everyone. The first step is defining the canonical model around one concrete use case.