Digital Twin Information Models: AAS vs DTDL vs OPC UA

Pick the wrong modeling language and your digital twin becomes a data island. Three years later, nobody can map a pump’s bearing temperature from the cloud back to the asset on the shop floor. That is the quiet failure mode behind most stalled Industry 4.0 programs. Choosing among digital twin information models is not a cosmetic decision — it determines whether your twin can be queried, federated, governed, and handed to a supplier without a rewrite.

This post compares the three serious contenders in 2026: the Asset Administration Shell (AAS), Microsoft’s Digital Twin Definition Language (DTDL), and the OPC UA information model. We cut through the marketing to weigh semantics, tooling, ecosystem maturity, interoperability, openness, PLM integration, and the runtime-versus-design-time split. You will leave with a weighted comparison matrix, four diagrams, and a defensible answer to “which one do we standardize on?”

What this post covers: why the choice matters, each contender in depth, a head-to-head scoring table, real interoperability bridges, the gotchas nobody warns you about, and concrete selection guidance.

Context: why the modeling-language choice matters

A digital twin is only as useful as the model behind it. The model defines what an asset is — its properties, telemetry, relationships, and the semantics that let two systems agree on meaning. Get this layer right and a twin becomes queryable, composable, and portable. Get it wrong and you ship a brittle blob of JSON that no downstream tool understands.

The stakes rose sharply with Industry 4.0 and the push toward interoperable value chains. Manufacturers, suppliers, and operators now exchange asset data across company boundaries. A nameplate property modeled one way in engineering must survive the trip to procurement, operations, and decommissioning. Without a shared information model, every handoff needs a custom adapter, and each adapter is a place where meaning leaks.

This is where the three contenders diverge. They were born in different worlds. AAS comes from the German Plattform Industrie 4.0 and the standards bodies, aiming at vendor-neutral asset portability. DTDL came from Microsoft Azure, optimized for a cloud twin graph. OPC UA grew from the OT and automation world, where live machine data is the whole point. Understanding those origins explains nearly every trade-off below.

By 2026 the field has consolidated around these three rather than fragmenting further, which itself is a meaningful signal. Earlier proposals and proprietary twin schemas have largely faded as buyers demand standards-backed portability. The practical effect is that an architecture decision made today is more durable than one made five years ago — the contenders are stable, well-documented, and backed by organizations that are unlikely to disappear. That stability lowers the risk of committing, but it raises the cost of committing to the wrong one, because you will live with the choice longer.

For the broader standards landscape — including ISO 23247 and ISO/IEC 30173 — see our guide to digital twin standards and reference frameworks. The choice of information model sits one layer below those framework standards.

It is worth separating two questions that teams routinely conflate. The first is how do I move data — a transport and protocol question. The second is how do I describe what the data means — the information-model question this post addresses. OPC UA answers both, which is part of why it is so often misclassified as merely a protocol. AAS and DTDL answer only the second, and rely on other transports to move bytes. Confusing the two layers leads to category errors, such as comparing AAS to MQTT or expecting DTDL to handle deterministic real-time control. Keep the layers distinct and the comparison clarifies immediately.

The three contenders explained

Each model answers the same question — “how do I describe an asset?” — with a different philosophy. Here is what you are actually adopting.

Asset Administration Shell (AAS / IEC 63278)

The Asset Administration Shell is the standardized digital representation of an asset, defined under IEC 63278 and stewarded by the Industrial Digital Twin Association. An AAS wraps an asset in a shell containing one or more submodels. Each submodel groups related data: a Nameplate submodel, a Technical Data submodel, an Operational Data submodel, and so on.

The power of AAS lies in standardized submodel templates published by the IDTA. When two companies both use the IDTA Nameplate submodel, a property like the manufacturer name lands in the same place with the same semantic ID. Submodel elements carry references to external dictionaries such as ECLASS or IEC CDD, which is how AAS achieves machine-readable semantics rather than just shared field names.

AAS is fundamentally design-time and exchange-oriented. The AASX package format lets you serialize a complete shell and hand it to a partner. There is a Type 1 (file exchange), Type 2 (server with API), and Type 3 (peer-to-peer) deployment continuum. For a deeper architectural treatment, see our AAS reference architecture guide. The trade-off: AAS is rich and portable but heavier to author than a cloud-native schema.

A few structural details matter for the comparison ahead. An AAS distinguishes between the asset (the real thing) and the shell (its administered representation), each carrying a globally unique identifier. Submodel elements come in defined kinds — Property, Range, MultiLanguageProperty, SubmodelElementCollection, ReferenceElement, and more — which gives the model a typed grammar rather than free-form JSON. That grammar is what tools can validate against. The IDTA maintains a growing catalog of standardized submodel templates, and the practical value of AAS scales directly with how many of them your industry has agreed upon. Where a template exists, adoption is mostly assembly; where one does not, you are designing semantics from scratch and inviting the very fragmentation AAS exists to prevent.

One more nuance: AAS supports both instance shells (this specific pump, serial 4471) and type shells (the pump model line). That instance-versus-type split mirrors PLM thinking and is one reason AAS slots cleanly into product lifecycle workflows where a design definition fans out into many built units.

DTDL (Azure Digital Twins, v3)

The Digital Twin Definition Language is a JSON-LD-based language created by Microsoft to model twins in Azure Digital Twins. A DTDL model is an Interface identified by a Digital Twin Model Identifier (DTMI), such as dtmi:com:pump:Pump;1. Interfaces declare Properties, Telemetry, Commands, Components, and Relationships.

DTDL v3 added semantic typing, richer schemas, and improved extensibility through feature extensions like QuantitativeTypes for units. Because DTDL is JSON-LD, it plays naturally with graph queries. Azure Digital Twins lets you build a live twin graph — instances connected by relationships — and query it with a SQL-like dialect. That graph-native runtime is DTDL’s signature strength.

DTDL is pragmatic and developer-friendly. The tooling is excellent inside the Azure ecosystem, and the DTDL v3 specification is open on GitHub. The catch is gravity: DTDL is open as a spec, but its center of mass is Azure Digital Twins. If you walk this path, see our DTDL v3 and Azure Digital Twins tutorial for hands-on modeling. Outside Azure, the runtime ecosystem thins considerably.

It helps to see DTDL’s content classes side by side, because they reveal its worldview. Properties hold state that changes slowly and is read or written. Telemetry represents a stream of events or measurements, not stored state. Commands are callable methods on a twin. Components let one interface embed another as a named sub-structure. Relationships connect twin instances into the graph, with their own properties on the edge. This vocabulary is deliberately lean — it maps almost one-to-one onto an application developer’s mental model, which is exactly why DTDL is fast to pick up.

DTDL v3 also sharpened semantic typing. You can annotate a Property or Telemetry with a semantic type such as Temperature and pair it with a unit, so the platform understands that a value is degrees Celsius rather than an opaque double. That closes part of the gap with AAS and OPC UA on units, though DTDL still leans on its own type system rather than an external industrial dictionary like ECLASS. For cloud teams that value velocity over cross-vendor dictionary alignment, that is an acceptable trade; for a multi-supplier value chain, it is a real limitation.

OPC UA information model (companion specs, nodeset)

OPC UA is, first, an industrial communication standard — but it carries a powerful information model. Servers expose an address space of Nodes: Objects, Variables, Methods, and the Types that define them. A PumpType ObjectType defines structure; a BearingTemperature Variable carries a NodeId, a DataType, and EngineeringUnits.

The interoperability engine here is the companion specification. Industry consortia publish standardized type definitions — for robotics, machine tools, pumps, and more — as NodeSet XML files. A device vendor that implements a companion spec exposes the same node structure as every other compliant vendor. This is real plug-and-play at the OT layer, governed by the OPC Foundation.

OPC UA shines at runtime. It is built for live data, subscriptions, security, and deterministic access to machine state. Our OPC UA protocol technical guide covers the transport and security stack. The information model is excellent for operational semantics but was not designed for the full asset lifecycle the way AAS was.

The address space is the heart of the model. Every Node has a NodeId, a NodeClass (Object, Variable, Method, ObjectType, and so on), and References to other nodes — HasComponent, HasProperty, HasTypeDefinition. Those References turn the address space into a navigable graph, which is why a client can browse a server it has never seen and discover structure at runtime. Type definitions sit above instances: a PumpType ObjectType declares the shape, and each real pump is an instance that conforms to it. This is closer to object-oriented modeling than to a flat tag list, and it is a frequent surprise to engineers who think of OPC UA only as “tags over the wire.”

Companion specifications are the governance layer that makes this interoperable rather than per-vendor. The OPC Foundation hosts dozens of them — for machine tools, robotics, plastics machinery, and more — each a NodeSet XML file defining standard types. When a manufacturer implements the relevant companion spec, integrators get predictable structure across brands. The limitation is scope: companion specs describe operational structure superbly, but rarely the commercial, regulatory, or end-of-life data an asset accumulates over a full lifecycle. That gap is precisely where AAS picks up.

The same pump, three ways

Abstractions get clearer with a concrete asset. Take pump P-101 with a bearing-temperature reading, a rated power, and a relationship to the tank it feeds. Watch how each model expresses the same three facts.

In AAS, the pump is a shell with submodels. Rated power lives as a Property inside a Technical Data submodel; bearing temperature is a Property inside an Operational Data submodel; the feeds relationship is a ReferenceElement pointing at the tank’s shell. Each Property carries a semanticId — an IRI into ECLASS or IEC CDD — so a partner’s tooling knows that this number is rated electrical power in kilowatts, not horsepower or a label.

In DTDL, the pump is an Interface, dtmi:com:pump:Pump;1. Rated power is a Property; bearing temperature is Telemetry, because it streams rather than persists as state; the feeds relationship is a Relationship to a Tank interface, with the edge itself able to carry properties such as flow rate. The whole thing is JSON-LD, ready to instantiate into a queryable graph.

In OPC UA, the pump is an instance of a PumpType ObjectType in the server’s address space. Rated power and bearing temperature are Variables with NodeIds, DataTypes, and EngineeringUnits; the feeds relationship is a Reference to the Tank object node. A client browses in, discovers the structure, and subscribes to bearing temperature for live updates.

The same three facts, three grammars. AAS optimizes for portable, dictionary-anchored description. DTDL optimizes for a cloud graph of instances. OPC UA optimizes for live, browsable, runtime access. None is wrong; they answer different questions.

Head-to-head comparison

The three models are not direct substitutes — they overlap partially and excel at different things. The figure below shows the same physical asset, a centrifugal pump, modeled in all three. Notice how each represents bearing temperature differently: an AAS submodel property, a DTDL telemetry field, and an OPC UA variable with engineering units.

With that mapping in mind, here is a weighted scoring across the criteria that actually drive adoption. Scores are a synthesized 1–5 judgment, not vendor benchmarks; weights reflect a typical industrial-interoperability program.

Criterion (weight)	AAS / IEC 63278	DTDL v3	OPC UA Info Model
Semantics & dictionaries (20%)	5 — submodel templates, ECLASS/CDD refs	3 — semantic types in v3, weaker dictionaries	4 — strong typed nodes, companion specs
Tooling & authoring (15%)	3 — improving, AASX editors	5 — mature Azure tooling	4 — modeler tools, NodeSet editors
Ecosystem maturity (15%)	4 — fast-growing IDTA ecosystem	4 — large but Azure-centric	5 — decades of OT adoption
Interoperability (20%)	5 — vendor-neutral by design	3 — strong in-Azure, weaker outside	4 — companion specs, OT-focused
Openness & governance (10%)	5 — IEC standard, IDTA-governed	3 — open spec, single-vendor runtime	5 — open standard, foundation-governed
PLM integration (10%)	5 — lifecycle and exchange native	3 — operations-leaning	3 — runtime-leaning
Runtime vs design-time fit (10%)	3 — design-time strength	4 — runtime graph	5 — runtime strength
Weighted total	4.45	3.55	4.25

Read this as a starting point, not a verdict. AAS leads on portability and lifecycle, OPC UA on live operational data, DTDL on cloud developer velocity. The weights are the argument — change them and the ranking changes. A pure cloud-analytics team would weight tooling and runtime higher and might rank DTDL first.

A few criteria deserve unpacking, because the one-line cell notes flatten real nuance. On semantics, AAS scores highest not because its data types are richer — DTDL and OPC UA both have strong type systems — but because of the dictionary discipline baked into submodel templates. Anchoring a property to an ECLASS or IEC CDD entry is a stronger guarantee of shared meaning than agreeing on a field name, and AAS makes that anchoring the default rather than an afterthought.

On interoperability, the picture splits by direction. OPC UA delivers exceptional interoperability within the OT layer through companion specs, but that interoperability is scoped to live operational structure. AAS targets interoperability across organizations and lifecycle phases, which is a broader, harder problem. DTDL is highly interoperable inside Azure and noticeably less so outside it. Scoring these on one axis hides that they solve different interoperability problems.

On PLM integration, AAS wins decisively because lifecycle and cross-organization exchange are its founding purpose, not a bolt-on. The instance-versus-type distinction, the AASX exchange package, and standardized commercial submodels all map onto how PLM systems think. DTDL and OPC UA can participate in PLM workflows, but they were built for operation and runtime, and it shows when you push them toward handover and decommissioning data.

Crucially, the choice is rarely exclusive. The decision tree below routes you by primary goal rather than forcing a single winner, because most mature architectures combine at least two of these models.

Interoperability in practice

The interesting engineering happens at the seams, not inside any single model. The most common real-world bridge connects OPC UA and AAS. OPC UA owns the live OT data; AAS owns the portable, lifecycle-aware asset description. They are complements, and the IDTA and OPC Foundation have collaborated on mapping approaches between them.

The diagram below shows a typical bridge. An OPC UA server exposes nodes shaped by a companion specification. A mapping layer translates that NodeSet into AAS submodels, aligning semantic IDs so a property means the same thing on both sides. The AAS repository then serves the portable shell to IT and engineering consumers.

This is where mapping pitfalls bite. The most frequent is unit mismatch: an OPC UA variable carries En