← Back to the framework

Framework · Layer guide

Common Data Models

The shared language of the plant. One governed meaning for every batch, order, and reading.

What it is

Common Data Models are the shared language of the architecture. Each manufacturing domain, Quality, Maintenance, Production, Supply Chain, owns a model that standardizes its vocabulary, units, business rules, and relationships: what a batch is, what a work order is, what a temperature reading must carry with it, and how those things relate. Together the domain models form the ontology of the plant, the semantic foundation that connects an event born at the edge to an analysis run at the enterprise, and the schema from which the knowledge graph is built.

The CDM layer is unusual in the stack: it is the only layer whose product is meaning rather than movement. The Edge Intelligence Hub enriches, the Unified Namespace distributes, the Unified Data Layer stores and serves, but all of them are enforcing and applying definitions that live here. The CDM is less a runtime component than a set of governed artifacts, schemas, mappings, contracts, and relationship definitions, that every other layer consults. That is what makes it the highest-leverage artifact in the architecture: change a definition here and the meaning changes everywhere, consistently, which is exactly the property nothing else in a typical plant's data landscape has.

The leverage. Every other layer moves, stores, or acts on data. This one decides what the data is. A plant can move data without a shared language; it cannot mean anything without one.

What breaks without it

Start with a temperature. The same physical reading on Reactor A exists in the SCADA system as TT_4021.PV = 84.2, in the historian as temp_reactorA = 84, and in a PLC register as R_A_TEMP = 184.8, which is the same number in Fahrenheit. Three names, two unit systems, zero context, one thermocouple. Nothing in any of the three systems says they are the same measurement, and the only place that knowledge exists is in the heads of the people who set them up.

Now multiply. A mid-sized plant has tens of thousands of tags, a dozen systems, and a history of integrations each of which negotiated meaning privately, pairwise, and differently. This is the quiet mathematics of the problem: without a shared model, every pair of systems that needs to talk requires its own translation, and the number of translations grows with the square of the number of systems. Every new use case starts with tag archaeology. Every cross-site comparison silently risks comparing different things, because yield at one plant includes rework and at another does not, and nobody wrote either definition down. Every AI initiative inherits all of it at once, which is a large part of why manufacturing AI stalls on data: the algorithms are fine, but the inputs mean nothing consistently.

The shared language collapses that quadratic mess into something linear: every system maps to the model once, and thereafter everything that speaks the model understands everything else that does. That is the entire trick, and it is worth the effort precisely because it is done once per system instead of once per conversation.

How it works

SCADA: TT_4021.PV = 84.2 Historian: temp_reactorA = 84 PLC: R_A_TEMP = 184.8 °F three names, two unit systems, one thermocouple °F → °C Common Data Model vocabulary · ontology · units Temperature equipment: Reactor A 84.2 °C canonical unit · contract ✓

The shared language at work: every system maps to the model once, and three private spellings become one governed meaning.

A domain's Common Data Model is a bundle of governed artifacts, and it helps to see them in four groups: the model itself, the contract that enforces it, the connections that put it to work, and the stewardship that keeps it alive.

The model itself starts with domain vocabulary: the harmonized terminology for the domain's entities, agreed across sites and partners, so that a lot, a deviation, and a changeover mean one thing each. On top of the vocabulary sits the ontology: the formal definition of how concepts relate. A batch runs on equipment, consumes a material lot, produces a product, moves through phases. This is what gives the data machine-readable meaning rather than just consistent spelling, and it is the schema from which the Unified Data Layer's knowledge graph is built. Anchoring both is the ISA-95 and ISA-88 mapping: equipment hierarchies, recipes, lots, and orders aligned to the standards the industry already shares, so the model is a dialect of a common tongue rather than a private invention.

The contract makes the model enforceable. Each entity carries a JSON data contract specifying schema, units, and latency SLAs per field, machine-verifiable, which is what allows the Edge Intelligence Hub to validate at the door and the Unified Data Layer to enforce on arrival. Unit conversion rules define the canonical unit for every measure and the conversions from everything else, which is how 184.8 Fahrenheit and 84.2 Celsius stop being two readings. A contract that lives in a wiki is documentation; a contract that a validator executes is architecture.

The connections put the model to work across the stack. CDM identifiers drive the Unified Namespace topic naming, so the hierarchy a message publishes into is itself an expression of the model. Master data binding links ERP materials, suppliers, and specifications to live signals, joining the transactional world to the physical one through shared identity. And versioned feature-store tables derived from the model feed AI pipelines with inputs whose meaning is defined once rather than re-engineered per project.

The stewardship keeps it alive. Each domain model has named ownership, and lineage and governance tie back to CDM tables as their anchor. Version control means the model evolves without amnesia: schema changes follow a governed path, and history stays queryable after evolution, so last year's data remains intelligible under this year's model. A model without stewards is a snapshot that starts aging the day it ships; a model with them is a living agreement.

One structural decision runs through all of this and deserves its own paragraph: the models are federated by domain, not centralized into one enterprise schema. Quality owns the Quality model, Maintenance owns Maintenance, and the architecture harmonizes them at the boundaries, through shared ISA-95 entities and the ontology, rather than forcing one committee to model the world. This is why the layer is Common Data Models, plural. Domain teams move at their own speed, disagreements are localized, and the whole never waits for the slowest part.

What it consumes and provides

What the layer consumes: the ISA-95 and ISA-88 standards as its entity backbone, so the models extend a shared industrial vocabulary rather than replacing it. Master and reference data from the ERP, the materials, suppliers, and specifications the models bind to live signals. And, notably, feedback from above: the Feedback Data Layer surfaces contract-evolution insights, the schema mismatches and drift that real operation exposes, routed to CDM owners as change proposals. The shared language learns from its own use.

What the layer provides: schemas and ISA-95 mappings down to the Edge Intelligence Hub, which enforces them at ingestion. Topic-naming structure to the Unified Namespace, so the hierarchy is model-driven. The entity and relationship definitions from which the Unified Data Layer builds its knowledge graph. Feature definitions to the AI feature store. And, to every layer at once, the contracts that validation happens against. The CDM's exports are the rulebooks everyone else plays by, which is why its governance matters more than its tooling.

A worked example: Batch 42 in the shared language

Continue the running example that begins in the Edge Intelligence Hub guide. The 84.2 that published at 02:14 did not become Reactor A, Temperature, Batch 42, HeatUp by magic; every part of that transformation was a CDM artifact being applied.

The vocabulary and ontology resolved three raw names, TT_4021.PV, temp_reactorA, R_A_TEMP, to one entity: a temperature measurement on Reactor A. The unit rules declared Celsius canonical and converted the PLC's Fahrenheit on the fly. The ISA-95 mapping placed Reactor A in its hierarchy, part of Line 5, in Packaging, in Plant 1, which is exactly the path the Unified Namespace topic expresses. The context rules attached Batch 42 and the HeatUp phase. And the data contract validated the result: right fields, right units, within latency SLA, stamped contract-valid.

The ontology did quieter work too. Because the Production and Quality models define how a reading relates to a batch, a batch to a material lot, and a lot to a product, the vibration alert born at the edge is not an orphan event: the model already knows that an alert on Reactor A during Batch 42 connects, through the batch, to Resin lot R-19 and Product X. Nothing has traversed those connections yet, that is the knowledge graph's job, two layers up, but the connections exist because the shared language defined them. When the deviation investigation eventually asks how a vibration reading relates to a resin lot, the answer will have been waiting since the moment the model was written.

What carries these well-formed events to every consumer that needs them is the job of the Unified Namespace.

Common anti-patterns

The shared language fails in recognizable ways, and most of them are attempts to shortcut the two things that make it work: shared and governed. Six worth naming:

Anti-pattern Why it happens What it costs What to do instead
The enterprise mega-model If a shared model is good, one perfect model of everything must be better Two years of committee modeling, nothing shipped, and a design outdated before first use Federate by domain: each domain owns its model, harmonized at the boundaries via ISA-95 and the ontology
The vendor schema as the model The MES or historian schema already exists, so adopting it feels free The plant's meaning shaped by one product's design; every migration becomes a semantic crisis A vendor-neutral model mapped to each vendor, so products are replaceable and meaning is not
ISA-95 in name only Claiming standards alignment satisfies the checklist without the work Renamed columns with no equipment hierarchy or batch semantics; interoperability that fails on contact Use the standards as the actual entity backbone: hierarchies, recipes, lots, and orders modeled as ISA defines them
Contracts without teeth Documenting the schema feels like the deliverable; enforcement feels like friction A wiki nobody reads while every consumer revalidates independently and differently Machine-verifiable contracts executed at the edge and the data layer, with rejections counted and visible
The frozen model Change feels dangerous, so version one becomes permanent and requests die in committee Teams route around the model with custom fields, and the shared language forks into dialects A governed change path with real cadence, versioned evolution, and history queryable across versions
Modeling without owners The model was a project; the project ended; stewardship was nobody's job Slow semantic decay: definitions drift, mappings rot, and trust erodes until the model is folklore Named domain owners with the authority to approve changes and the calendar to actually meet

The pattern inside these is symmetry: the first three fail by getting shared wrong (too big, borrowed, or fake), and the last three fail by getting governed wrong (unenforced, frozen, or orphaned). A model that is genuinely shared and genuinely governed is hard to defeat; a model missing either is defeated already.

What good looks like

A field test for whether the shared language is genuinely working. A new use case starts from the model, not from tag archaeology, and the data science team can name an entity's fields, units, and owner without leaving their desk. The same question asked at two sites returns answers that are actually comparable, because yield means one thing. Unit errors are caught at validation, as rejection counts on a dashboard, rather than months later in an analysis that quietly mixed Celsius and Fahrenheit. A schema change last quarter followed the governed path, and queries against last year's data still work. Each domain model has a named owner, and the owners met this month. And the ontology is not shelf-ware: the relationships it defines are the ones the knowledge graph actually traverses, and adding a partner site or CMO means mapping their systems to the model once, not renegotiating meaning system by system.

An organization that passes those checks has a shared language. One that does not has a shared vocabulary document, which is a different and much cheaper thing.

Standards involved

Design it yourself

Where this layer fits

Common Data Models sit second from the bottom of the stack and first in logical order: everything else applies what this layer defines. The Edge Intelligence Hub enforces its schemas and maps at the moment data is born. The Unified Namespace organizes its hierarchy around CDM identity. The Unified Data Layer builds its knowledge graph from the ontology and enforces the contracts on everything that arrives. The Feedback Data Layer returns evidence of how the definitions hold up in production, and the AI layer's agents inherit, through every one of those paths, inputs that mean something. It is the least visible layer in a demo and the most consequential one in year three.

Further reading