Digital Twin Information Models: AAS vs DTDL vs OPC UA

Pick the wrong modeling language and your twin becomes a data island. Three years on, nobody can trace a pump’s bearing temperature from the cloud graph back to the nameplate the supplier filed during procurement. That quiet failure, not a lack of sensors, stalls most Industry 4.0 programs. Choosing among digital twin information models is therefore an architecture decision with a long tail: it decides whether your twin can be queried, federated, governed and handed to a supplier without a rewrite.

Three serious contenders remain in late 2026: the Asset Administration Shell (AAS) from the Industrial Digital Twin Association (IDTA), the Digital Twins Definition Language (DTDL) from Microsoft, and the OPC UA information model from the OPC Foundation. They overlap less than the marketing suggests. This post models one pump in all three, with code, and shows where each one is strong and where it quietly fails.

What this covers: the origin and mechanics of each model, a verified status check of current versions, one pump asset expressed three ways, how semantic IDs (ECLASS, IEC CDD) tie them together, bridging patterns and tooling, a decision matrix, and the failure modes that bite in production.

Context and Background

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.

It helps to separate two questions that teams routinely conflate. The first is how data moves, which is a transport and protocol question answered by MQTT, AMQP, HTTP or OPC UA’s own binary and PubSub mappings. The second is what the data means, which is a modeling question. This post is about the second. If you need the first, our comparison of OPC UA FX and deterministic Ethernet covers the transport side of the OT world.

The three models were born in different places, and nearly every trade-off follows from that origin.

• AAS came out of Germany’s Plattform Industrie 4.0 and is now maintained by the IDTA. It targets asset portability across companies and the lifecycle: a manufacturer ships an asset with its digital description, and an operator, integrator and recycler all read the same description.
• DTDL came from Microsoft and is the schema language of Azure Digital Twins (ADT). It targets a cloud-hosted twin graph where interfaces, properties and relationships are queryable. It is also used by Azure IoT Plug and Play.
• OPC UA came from the automation industry. Its information model lives inside a server’s address space, so it describes a machine that is running now, with live values, methods and events. It is standardized as IEC 62541 and maintained as the OPC 10000 series.

By 2026 the field has consolidated around these three rather than fragmenting. Proprietary twin schemas have mostly lost the argument with buyers who demand standards-backed portability. 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.

One framing to keep in mind throughout: the models do not compete on the same axis. AAS is strongest at design time and across organizational boundaries. OPC UA is strongest at runtime, next to the machine. DTDL is strongest as a graph in an analytics and application platform. A mature architecture usually uses more than one, which means the real skill is the mapping between them. For the framework standards that sit one layer above all three, see our guide to digital twin standards including ISO 23247 and ISO/IEC 30173.

Status check: what is current as of October 2026

Versions matter because every one of these specifications has moved since most blog posts about them were written. The following was checked against the publishers’ own pages this week.

Model	Current published version (checked)	Notes
AAS metamodel, IDTA-01001	3.2, dated July 2026; previous 3.1.2	3.1 (May 2025) was the first HTML, open-source release; 3.0 was finalized in January 2023 and split the spec into parts
DTDL	v4 published (context dtmi:dtdl:context;4); v3 and v2 remain	Azure Digital Twins documentation lists support for v2 and v3 and does not mention v4
OPC UA Part 5, Information Model	1.05.06, published 2025-10-22	Previous major in this line: 1.04 (2017); primary namespace model version listed as 1.05.07
OPC UA for AAS, OPC 30270	v1.00	Maps the AAS metamodel into an OPC UA address space

Two consequences follow. First, if a vendor tells you ADT “supports DTDL v4”, ask for the documentation; the public Azure page I checked names v2 and v3 only. Second, AAS 3.2 changed some details you may have implemented against 3.0, such as integer-typed version and revision fields. We come back to that in the failure-modes section.

Three Models, Three Centers of Gravity

The short answer to “which one?” is that they answer different questions. AAS describes an asset as a portable package of submodels with globally unique semantic references. DTDL describes types of twins and the relationships between them as a graph. The OPC UA information model describes the live address space of a running server through typed nodes and references. Choose by where the authoritative description must live: in a file you hand to a partner, in a cloud graph, or on the machine.

Figure 1: Where each of the three digital twin information models sits, and why semantic IDs are the shared layer.

Figure 1 shows the structural point. The three models sit at different lifecycle positions and converge on a shared semantic layer. If you remember one sentence from this post, make it this: syntax is cheap to convert, semantics are not. Converting an AAS Property into a DTDL Property is a mechanical transformation. Knowing that both mean the same physical quantity, with the same unit and the same definition, is not mechanical, and it is what the semantic identifier carries.

The Asset Administration Shell: a package for the asset’s life

The AAS metamodel, specified in IDTA-01001, is deliberately small. An AssetAdministrationShell holds an assetInformation block (the global asset identifier and whether the asset is a type or an instance), a list of references to submodels, and an optional derivedFrom reference. A Submodel is an identifiable aspect of the asset: nameplate, technical data, documentation, carbon footprint, operational data. Each submodel has a kind, either Template or Instance, and contains SubmodelElements.

The SubmodelElement vocabulary is where the expressive power sits. The spec defines Property, MultiLanguageProperty, Range, Blob, File, ReferenceElement, Capability, SubmodelElementCollection, SubmodelElementList, Entity, Operation, RelationshipElement and AnnotatedRelationshipElement, plus event elements that the current text still marks as experimental. Properties carry a value type drawn from XML Schema data types. Collections and lists give structure. Operations give you invocable behavior, though in practice they are used far less than Properties.

Figure 2: Structure of an AAS for a pump, showing the shell, submodels, elements and the ConceptDescription link.

The mechanism that makes AAS interoperable is not the container but the semantics. Any element can carry a semanticId, which is a Reference pointing outside the shell, typically to an ECLASS IRDI or an IEC Common Data Dictionary (CDD) entry. A supplementalSemanticId list adds further references; the spec constrains these so that a supplemental ID is only legal when a main semanticId exists (constraint AASd-118). A ConceptDescription can then hold the definition in an IEC 61360 data specification: preferred name, unit, data type and definition. The IDTA publishes many of these as ready-made submodel templates, for example the Digital Nameplate (IDTA-02006, current version 3.0.1 on the IDTA site) and the Generic Frame for Technical Data (IDTA-02003).

The other half of the AAS is its API and exchange story. The specification is split into parts: Part 1 metamodel, Part 2 API, Part 3a data specifications, Part 3b (version 3.0), Part 4 security, and Part 5 the AASX package format. The 3.2 revision pairs Part 1 with API v3.2 and AASX v3.2, with Part 3a at 3.1 and Part 4 at 3.1, per the cover material of the July 2026 document. In practice that means you get a REST interface to read and write shells, submodels and elements, and a zip-based file format to exchange them offline. For a deeper walk through the submodel catalog, see our post on AAS submodels.

What AAS is not: it is not a time-series store, and it has no native notion of a subscription to a value stream. The AAS describes what is true about the asset and where to find data; moving live data is delegated to an endpoint described in the shell, or to a system such as OPC UA. Teams that try to push a kilohertz signal through a Property over HTTP discover this quickly.

DTDL: interfaces and a queryable graph

DTDL is a JSON-LD based language. A model is an Interface with a @id expressed as a DTMI (Digital Twin Model Identifier), such as dtmi:com:example:Pump;1. Inside an interface you declare contents: Telemetry, Property, Command, Relationship and Component. Complex schemas (Object, Enum, Map, Array) shape values. Interfaces inherit through extends, and DTDL v4 raised the maximum extends depth to 12 and the nesting of complex schemas to 8 levels, according to the v4 specification page. It also added unsigned and byte primitives, a uuid type, a scaledDecimal schema, and permitted self-referential complex schemas.

The graph is the point. A Relationship such as feeds or locatedIn between twins is a first-class element, and ADT lets you query across relationships with a SQL-like language. That makes DTDL the natural fit for questions like “all pumps downstream of Tank 3 whose vibration exceeds a threshold”. An AAS can express relationships through RelationshipElement and Entity, and OPC UA through references, but neither is optimized for graph traversal queries over thousands of twins.

DTDL also has a practical restriction worth stating plainly: Azure Digital Twins implements a subset. Per Microsoft’s documentation, ADT supports DTDL v2 and v3, does not support Commands, accepts writable and multiplicity constraints without enforcing them, allows only one level of component nesting, and does not allow inline interfaces. If you write Commands in a model for ADT, you are documenting intent, not creating behavior. DTDL used for IoT Plug and Play is a different consumer with different support. Our DTDL v3 and Azure Digital Twins tutorial goes through upload and query mechanics.

OPC UA: the address space is the model

An OPC UA server exposes an address space made of nodes. Every node belongs to a node class: Object, Variable, Method, View, and the type-side classes ObjectType, VariableType, ReferenceType and DataType. Nodes are connected by typed references, and the standard ones you meet daily are HasComponent, HasProperty, HasTypeDefinition, HasSubtype and Organizes. A client browses the graph, reads and subscribes to Variables, calls Methods and receives Events.

Information models are layered. The base model is OPC 10000-5, currently at release 1.05.06 (published 22 October 2025 by the OPC Foundation). On top of it sit device integration (DI), then domain companion specifications for machine vision, robotics, machine tools, plastics and many more, each shipped with a NodeSet2 XML file that a server loads. Because types are declared in NodeSet2 files with a stable namespace URI, a client that knows a companion specification can interpret an unfamiliar server without custom code. Our write-up on OPC UA companion specifications for robotics and machinery shows that mechanism in action.

The difference from AAS is where the truth lives. An OPC UA model is bound to a server and a connection. There is no portable package, unless you ship the NodeSet2 file for the types, which carry no instance data. That is a feature when you want live machine access with sub-second updates, and a limitation when you want to give a partner the asset’s description without handing over network access.

Worked Example: One Pump, Three Models

Abstract comparisons hide the friction. So take a single centrifugal pump, Pump 7, and describe the same facts in each model. The facts are: manufacturer name, serial number, rated flow in cubic meters per hour, live bearing temperature, and a relationship saying the pump feeds Tank 3. The code below is trimmed for readability and illustrative; identifiers marked as examples are placeholders you must replace with real ones from your registry.

Pump 7 as an Asset Administration Shell

In the AAS JSON serialization, the environment holds shells, submodels and concept descriptions. The Nameplate submodel carries a semanticId pointing at the IDTA template, and its ManufacturerName property carries an ECLASS IRDI. The IRDI shown (0173-1#02-AAO677#002) is the one used for manufacturer name in the IDTA nameplate templates as I know them; confirm it against the template version you build on.

{
  "assetAdministrationShells": [{
    "modelType": "AssetAdministrationShell",
    "id": "https://example.com/aas/pump-7",
    "idShort": "Pump7",
    "assetInformation": {
      "assetKind": "Instance",
      "globalAssetId": "https://example.com/assets/pump-7"
    },
    "submodels": [
      {"type": "ModelReference", "keys": [{"type": "Submodel",
        "value": "https://example.com/sm/pump-7/nameplate"}]},
      {"type": "ModelReference", "keys": [{"type": "Submodel",
        "value": "https://example.com/sm/pump-7/operational"}]}
    ]
  }],
  "submodels": [{
    "modelType": "Submodel",
    "id": "https://example.com/sm/pump-7/nameplate",
    "idShort": "Nameplate",
    "kind": "Instance",
    "semanticId": {"type": "ExternalReference", "keys": [{"type": "GlobalReference",
      "value": "https://admin-shell.io/idta/nameplate/3/0/Nameplate"}]},
    "submodelElements": [
      {"modelType": "Property", "idShort": "ManufacturerName",
       "valueType": "xs:string", "value": "Acme Pumps GmbH",
       "semanticId": {"type": "ExternalReference", "keys": [{"type": "GlobalReference",
         "value": "0173-1#02-AAO677#002"}]}},
      {"modelType": "Property", "idShort": "SerialNumber",
       "valueType": "xs:string", "value": "P7-2026-00418"},
      {"modelType": "Property", "idShort": "RatedFlow",
       "valueType": "xs:double", "value": "120.0",
       "semanticId": {"type": "ExternalReference", "keys": [{"type": "GlobalReference",
         "value": "https://example.com/cd/rated-flow-m3h"}]}}
    ]
  }]
}

Two things deserve attention. The value is a string even for a double, because the AAS JSON serialization stores values as lexical XSD strings. And the RatedFlow semantic ID here is a placeholder; in a real deployment you would point at an ECLASS or IEC CDD entry, so a partner’s tool resolves the unit and definition without asking you. Relationships to other assets, such as the pump feeding Tank 3, go into a RelationshipElement or into an Entity statement in a Bill-of-Material style submodel. That is expressible, but it is a modeling convention more than a graph feature.

Pump 7 as a DTDL v3 interface

The same pump in DTDL is an interface, and a twin instance is created from it. Telemetry and Property are separated: bearing temperature is Telemetry (a stream), while serial number and rated flow are Properties (state). The unit semantics come from the QuantitativeTypes extension, which you enable by adding its context to @context. Check the exact unit names (such as cubicMetrePerHour) against the extension’s published unit list before use; I have not verified that specific token.

{
  "@context": [
    "dtmi:dtdl:context;3",
    "dtmi:dtdl:extension:quantitativeTypes;1"
  ],
  "@id": "dtmi:com:example:Pump;1",
  "@type": "Interface",
  "displayName": "Centrifugal pump",
  "contents": [
    {"@type": "Property", "name": "manufacturerName", "schema": "string"},
    {"@type": "Property", "name": "serialNumber", "schema": "string"},
    {"@type": ["Property", "VolumeFlowRate"], "name": "ratedFlow",
     "schema": "double", "unit": "cubicMetrePerHour"},
    {"@type": ["Telemetry", "Temperature"], "name": "bearingTemp",
     "schema": "double", "unit": "degreeCelsius"},
    {"@type": "Relationship", "name": "feeds",
     "target": "dtmi:com:example:Tank;1"}
  ]
}

Note what is missing: there is no field for an ECLASS IRDI. DTDL has no built-in semanticId. The semantic types in the QuantitativeTypes extension give you a closed set of quantities and units, which is useful but not the same as a dictionary reference. If you need an external identifier you must carry it in a custom annotation, a comment, a naming convention or an adjacent registry. That gap is the single biggest friction when bridging DTDL to AAS, and we return to it below.

In Azure Digital Twins the DTDL v3 features I used are accepted, but remember the service boundary: the Azure documentation says v3 models do not show in the Explorer model graph and must be uploaded through the SDKs, APIs or CLI. And Telemetry has no unique storage in ADT; the current guidance is to store the latest value as a Property and emit Telemetry messages through the SendTelemetry API. In effect, bearingTemp above would be mirrored as a Property in a production ADT model.

Pump 7 as an OPC UA type and instance

In OPC UA the pump is an ObjectType with components, and the running server exposes an Object instance. The NodeSet2 fragment below declares PumpType and one analog Variable. The namespace URI and node ids are examples. To keep it short, I omit aliases and the namespace table.

<UAObjectType NodeId="ns=1;i=1000" BrowseName="1:PumpType">
  <DisplayName>PumpType</DisplayName>
  <References>
    <Reference ReferenceType="HasSubtype" IsForward="false">i=58</Reference>
  </References>
</UAObjectType>

<UAVariable NodeId="ns=1;i=1001" BrowseName="1:BearingTemperature"
            ParentNodeId="ns=1;i=1000" DataType="Double">
  <DisplayName>BearingTemperature</DisplayName>
  <References>
    <Reference ReferenceType="HasTypeDefinition">i=2368</Reference>
    <Reference ReferenceType="HasComponent" IsForward="false">ns=1;i=1000</Reference>
    <Reference ReferenceType="HasModellingRule">i=78</Reference>
  </References>
</UAVariable>

Here i=58 is BaseObjectType, i=2368 is AnalogItemType, the VariableType you use when you want engineering units and range, and i=78 is the Mandatory modelling rule; these are well-known namespace-0 identifiers, but verify them against the NodeSet2 for your target specification version rather than trusting a blog snippet. The AnalogItemType supplies EURange and EngineeringUnits as Properties, and the latter uses the UNECE unit code scheme, which gives you a standard unit identifier with no extra modeling. Semantic dictionary links are possible, since OPC UA defines dictionary entry types and lets a node point to an IRDI, but it is rarely used in practice and not the default experience.

The runtime consequence is large. In OPC UA the client subscribes to BearingTemperature and receives data changes at a sampling interval it requests. Neither the AAS snippet nor the DTDL snippet has an equivalent mechanism.

Semantics and Bridging: Making the Three Agree

Having the same pump in three syntaxes is easy. Making them mean the same thing is the engineering work. This section covers the semantic layer, the bridging patterns that hold up in production, and the tooling for each side.

Semantic identifiers: ECLASS, IEC CDD and what each model supports

A semantic identifier is a globally unique pointer to a definition kept in a dictionary. Two dictionaries dominate industrial use. ECLASS is a classification and property dictionary maintained by the ECLASS association, and identifies concepts with IRDIs (International Registration Data Identifiers) such as 0173-1#02-AAO677#002. The IEC Common Data Dictionary (CDD) holds IEC 61360 style definitions for electrical and electronic concepts. IEC 61360 defines the data element type structure (name, definition, unit, value format) that the AAS reuses for ConceptDescriptions.

Support differs sharply across the three models.

Capability	AAS	DTDL	OPC UA
Native semantic reference on every element	Yes, semanticId plus supplementalSemanticId	No built-in equivalent	Possible via dictionary entries and IRDI-typed properties, but not the default
Definition travels with the model	Yes, via ConceptDescription and IEC 61360 data spec	No, only displayName, description, comment	Partly, via companion spec documentation and NodeSet2
Unit handling	Unit in the data specification	QuantitativeTypes extension with a closed unit set	EUInformation with UNECE codes
Dictionary lookup tooling	Strong in AAS editors	Roll your own	Varies

The pattern that works is to treat the semantic ID as the join key. Whatever the model, each business-relevant element should resolve to an IRDI or an equivalent stable URI. Then a bridge does not need to understand either syntax deeply; it matches by identifier. Our post on digital twin ontologies with Brick, RDF and SHACL takes that join-key idea further, into a full graph with validation.

Bridging patterns that survive production

Figure 3: A bridge service takes live values from the OPC UA server and updates the DTDL twin and the AAS, using semantic IDs as the join key.

Figure 3 shows the topology most teams converge on. The machine speaks OPC UA, because that is what the controller offers. A bridge service subscribes to the relevant Variables, maps them using a table keyed by semantic ID, and writes the values outward: PATCH operations on the cloud twin’s properties, and value updates on the AAS submodel elements in a repository. Each model is authoritative for something different. OPC UA is authoritative for live process values. The AAS repository is authoritative for the asset’s identity, documentation and nameplate. The DTDL graph is authoritative for the plant topology and the analytics-facing view.

There are three recognized bridging patterns.

1. OPC UA server exposes the AAS. The OPC UA companion specification OPC 30270 (v1.00) maps the AAS metamodel into an OPC UA address space, so AAS and its submodels can be represented in a server’s address space. It defines ObjectTypes for the AAS root, referable and identifiable types, asset and submodel types, submodel element types, concept descriptions and data specification templates, along with DataTypes and an I4AAS server facet for conformance. Use it when you need a single endpoint that serves both live data and the shell, and when your client stack is already OPC UA. The cost is that the AAS inside OPC UA is not portable as a file; you still export AASX separately.
2. AAS repository references OPC UA endpoints. The shell describes the asset and its submodels, and a submodel element (often a File or a Property with qualifiers) records the OPC UA endpoint and node id where live values live. A consumer reads the shell, follows the pointer, and subscribes. This keeps AAS the portable package and OPC UA the live channel. It is the lowest-effort pattern and the most honest about division of labor.
3. Translate at the cloud edge. An ingestion service reads OPC UA, annotates with semantic IDs, and writes to ADT or another store. The DTDL twin exists for graph analytics, and an AAS export is generated from it or from a shared registry for external partners.

An often overlooked fourth option is to avoid bridging at all by choosing a single authoritative model per concern and publishing mapping documentation. That is unglamorous and works well for small estates. It collapses once more than two or three suppliers join.

Where ISO 23247 fits

ISO 23247 is a multi-part standard for digital twin frameworks in manufacturing. It defines a reference architecture and the notion of Observable Manufacturing Elements (OMEs), the physical things being twinned, with parts covering overview, reference architecture, digital representation and information exchange. It does not mandate an information model. That is why it sits above this discussion: an ISO 23247 conformant system can represent an OME as an AAS, a DTDL twin or an OPC UA object. The newer parts on digital thread and composition are discussed in our posts on the ISO 23247-5 digital thread and ISO 23247-6 twin composition. Treat ISO 23247 as the vocabulary for describing your architecture to auditors and partners, and the three information models as implementation choices within it.

Tooling by model

For AAS, the Eclipse BaSyx project provides open-source SDKs and server components (repositories, registries, an AAS web UI) that implement the IDTA API, and the AASX Package Explorer is the common desktop editor for building and inspecting AASX files. Our BaSyx tutorial walks through a deployment. For DTDL, Microsoft publishes the DTDL specification repository and parsers, and Azure Digital Twins provides the service, an Explorer and SDKs. For OPC UA, the open62541 library is a widely used open-source C implementation, and the commercial ecosystem (Unified Automation, Prosys, Softing, Siemens, and others) provides servers and SDKs; model authors use a NodeSet2 editor such as the UA Modeler. Tool choice follows model choice, but you should check each tool against the specific spec version you target, because tooling usually lags a new spec release by months.

Selection Matrix: Scoring the Three Models

A weighted matrix keeps the argument honest, provided you set the weights from your own requirements rather than from the table below. The scores here are my judgment as a practitioner, on a one to five scale, and not measurements. Change them, and change the weights, before drawing conclusions.

Criterion	AAS	DTDL	OPC UA
Semantic rigor (dictionary references)	5	2	3
Cross-company portability	5	2	2
Live runtime data and subscriptions	2	2	5
Graph relationships and queries	2	5	3
Vendor neutrality and governance	5	3	5
PLM and lifecycle integration	4	2	2
Machine-side availability today	2	1	5
Cloud platform tooling	3	4	3

Read the table by columns, not totals. AAS wins wherever the question is “what is this asset and who can read its description”, which is why it keeps appearing in regulatory conversations such as digital product passports. OPC UA wins wherever the question is “what is the machine doing right now”. DTDL wins where the question is “how do my twins relate and what does my application need to query”. A total score that averages those would hide the very reason you would pick one.

The PLM column deserves a sentence. PLM systems manage the engineering definition: CAD, bill of materials, configurations, change records. The natural handoff is that the PLM release produces the type-level AAS (kind Template or type-level asset), and manufacturing or commissioning produces the instance-level shell with serial-specific values. The PLM side rarely speaks DTDL or OPC UA directly. If you work with CAD and lightweight formats alongside, see our comparison of 3MF, STEP AP242, glTF and JT for the geometry side of the same handoff.

Figure 4: Decision flow for choosing among AAS, DTDL and OPC UA based on exchange, runtime and cloud needs.

Figure 4 compresses the logic into three questions: where must the description live, do your machines already speak OPC UA, and do you need to give partners a portable description. Most real answers land in a combination, which is why the more useful design question is which model is authoritative for which fact.

A thesis worth arguing with

Here is the position this post takes, stated so you can disagree with it. Do not standardize on one information model for the whole estate. Standardize on semantic identifiers, and let each model be authoritative where its center of gravity is. Most failed twin programs I have seen standardized on a syntax and left semantics to convention, which means every project re-invents what “bearing temperature” means. The syntax war is largely a distraction. The programs that last put effort into a governed dictionary, a mapping table and a validation step in CI.

Trade-offs, Gotchas, and What Goes Wrong

Every one of these models fails in recognizable ways. The following are the ones that cost real time.

Version drift inside AAS. The metamodel moved from 3.0 (finalized January 2023) through 3.1 (May 2025, first open-source HTML release) to 3.2 (July 2026). Version and revision attributes are integers in 3.2 rather than text, timestamps have clarified semantics, and a minimum recursion depth of 32 is recommended for container elements. Submodel templates version separately again: the Digital Nameplate has a 3.0.1 release on the IDTA site, built against a specific metamodel. A repository that accepts files from many suppliers will see a mix. Pin versions in your contracts and validate on ingest.

Semantic IDs that look right but resolve nowhere. A semanticId is only as good as the dictionary behind it. Teams invent URLs under their own domain, then never publish a definition. Six months later, two plants use the same URL for different units. Treat placeholder IDs like the ones in my pump example as technical debt from day one, and register real ones.

DTDL features that parse but do nothing. DTDL as a language lets you declare writable and multiplicity constraints, and ADT accepts them without enforcing them; Microsoft’s guidance is that models for ADT must not define Commands at all. A model written against the generic language can look valid while the missing enforcement surfaces only in production. Also watch the v2 and v3 rules: a v2 interface cannot extend a v3 interface, and v3 models are not shown in the Explorer graph. The ecosystem is also drifting toward v4 on the specification side, so confirm service support before adopting v4 syntax.

OPC UA models coupled to one server. Instances only exist while the server runs, and a NodeSet2 file carries types but not data. Teams that treat the server as the twin’s database lose history and lose the asset when the controller is replaced. Pair it with a historian, as described in our post on ingesting OPC UA historian data for digital twins. Also mind the specification line: 1.05 is current for Part 5, and our 1.03 vs 1.05 migration guide covers certification impact.

Bridge logic that becomes the real model. The mapping table in a bridge accumulates exceptions until it is the de facto information model, undocumented. Version it, review it and test it like the schema it is.

Units and datatypes lost in translation. An AAS string value like "120.0", a DTDL double and an OPC UA Double with an EUInformation structure carry different amounts of unit information. When a bridge copies a number without its unit, you get the classic factor-of-sixty error between per-minute and per-hour. Bridge the unit as a first-class field, validated against the dictionary.

Performance mismatches. AAS REST updates for a signal sampled many times per second will saturate a repository. Keep high-rate streams in a time-series path and put only the latest or aggregated values, or a pointer, in the AAS.

Practical Recommendations

Start from the question of who must read the description. If suppliers, customers or regulators must read it without access to your network, the AAS is the right authoritative container, and you should build on IDTA submodel templates instead of inventing your own. If a controller or gateway on the shop floor must be read live, OPC UA is already there and its companion specifications give you a model for free. If the consumer is an analytics or application layer that needs relationships between assets, a graph model such as DTDL on ADT is a strong fit, with the caveats above.

Then invest where the leverage is. Define a small governed set of semantic IDs for the fifty or so properties that matter, resolve them against ECLASS or IEC CDD where a definition exists, and publish your own definitions where one does not. Write the mapping table as a versioned artifact, with one row per property: semantic ID, AAS path, DTDL name, OPC UA browse path, unit, and datatype. Test it in CI by round-tripping a sample pump through all three and comparing.

Be skeptical about two common plans. The first is a “universal canonical model” that sits above all three: it nearly always becomes a fourth model that nobody else supports. The second is converting everything to one syntax through a script run once. Models drift, and a one-off conversion has no owner.

Finally, plan for versions. Record the metamodel version of every AAS you accept, the DTDL context version of every interface, and the NodeSet2 namespace publication date of every OPC UA model. Treat version bumps as releases of your own integration.

Checklist

• [ ] Name the authoritative model for each class of fact (identity, live values, topology)
• [ ] Choose a semantic dictionary and register real IDs, no placeholder URLs
• [ ] Pin spec versions: AAS metamodel, DTDL context, OPC UA Part 5 and companion specs
• [ ] Keep high-rate telemetry out of AAS REST paths; store pointers instead
• [ ] Keep a versioned mapping table with units and datatypes, tested in CI
• [ ] Store history outside the OPC UA server
• [ ] Confirm service support for your DTDL version before using new syntax
• [ ] Validate every inbound AASX against the declared metamodel version

Frequently Asked Questions

What is the difference between AAS, DTDL and OPC UA?

They sit at different layers. AAS is a portable, standardized package that describes an asset and its submodels with semantic references, maintained by the IDTA. DTDL is a JSON-LD language for typed twins and relationships, used by Azure Digital Twins. OPC UA is a runtime protocol and information model where nodes in a server’s address space expose live values, methods and events. They are complementary more often than competing, and the practical task is mapping between them.

Is DTDL compatible with the Asset Administration Shell?

Not directly. There is no official standard mapping between them. You can translate structure mechanically: interfaces and properties to submodels and properties. The hard part is semantics, since DTDL has no native semantic ID field, so you need an annotation or a registry to carry ECLASS or IEC CDD references. Many teams keep DTDL internal to their cloud platform and generate AAS at the boundary toward partners.

Can an OPC UA server expose an Asset Administration Shell?

Yes. The OPC Foundation companion specification OPC 30270, version 1.00, maps the AAS metamodel into an OPC UA address space, defining ObjectTypes for shells, submodels, submodel elements and concept descriptions, plus a server facet for conformance. It lets one endpoint serve both live data and the shell. The AAS inside the server is not itself a portable file, so you still export AASX for exchange.

Which version of the AAS specification is current?

As of the July 2026 publication, IDTA-01001 Part 1 Metamodel is at version 3.2, preceded by 3.1.2 and the open-source 3.1 release of May 2025. Version 3.0 was finalized in January 2023. Companion parts are versioned separately; the 3.2 document lists API at 3.2 and AASX package format at 3.2. Always check the IDTA site before starting, since parts and templates update independently.

Does Azure Digital Twins support DTDL v4?

The Microsoft documentation I checked in October 2026 states that Azure Digital Twins supports DTDL v2 and v3, with v3 recommended, and does not mention v4. The DTDL v4 specification itself is published, with a larger nesting and inheritance limit and new primitive types. If you need v4 features, confirm service support with Microsoft documentation or support before depending on them.

Which information model should I choose for a new digital twin program?

Choose by where the authoritative description must live. If it must cross company boundaries, start with AAS and IDTA templates. If it must come from running machines, use OPC UA and its companion specifications. If it must feed a graph-based application on Azure, use DTDL there. Invest first in semantic IDs and a mapping table, because those survive any change in syntax.

Further Reading

• Digital twin standards: ISO 23247, ISO/IEC 30173 and the DTC
• Asset Administration Shell submodels explained
• Asset Administration Shell reference architecture
• DTDL v3 and Azure Digital Twins tutorial
• OPC UA companion specifications for robotics and machinery
• External: IDTA-01001 AAS Part 1 Metamodel v3.2, DTDL v4 specification, OPC 10000-5 Information Model, OPC 30270 AAS companion specification

By Riju — about