ArchitectureDigital Twins

Digital twin standards compared, and how to layer them for multi-vendor integration

No single digital twin standard covers everything. OPC UA gives structured access to equipment data, the Asset Administration Shell describes an asset and its information in submodels, DTDL defines twin types and relationships for graph-based platforms, ISO 23247 frames how manufacturing twins should be organized, and NGSI-LD addresses cross-domain context. A sound architecture assigns each a layer and fixes identity, units and time across them.

Reviewed 6 min read

On this page
  1. Why multi-vendor twins break at the integration layer
  2. Layers of an interoperable twin and the standards that serve each
  3. What each standard defines, and what it leaves to you
  4. Asset Administration Shell: identity first, then submodels
  5. DTDL and graph-shaped twin models
  6. Mapping rules to agree before connecting a second vendor
  7. Picking a combination of standards for your situation
  8. Lock-in traps in twin data architecture
  9. Questions and answers
  10. Sources

Why multi-vendor twins break at the integration layer

The modeling is rarely what sinks a digital twin. Integration is. A pump from one vendor reports discharge pressure under a tag name nobody documented, a drive from another reports power in different units, the maintenance system knows the asset by a third identifier and the twin platform wants its own. Each mapping is small; together they consume the project and break whenever equipment is replaced.

Standards reduce that work only if they are applied in the right place. Teams get into trouble when they expect one standard to do everything, for example treating a twin platform's modeling language as the plant's information model, or treating a connectivity protocol as a semantic model. The layered view below separates those concerns.

Layers of an interoperable twin and the standards that serve each

Scenarios and decisions01Twin model and graph02Asset description03Data access and transport04Equipment and controllers05
  1. Scenarios and decisions

    Calibrated models, scenario comparison and operator views; mostly your own logic.

  2. Twin model and graph

    Twin types and relationships between assets, for example in DTDL.

  3. Asset description

    Identity, nameplate, documentation and operating data as Asset Administration Shell submodels.

  4. Data access and transport

    OPC UA information models and services, or MQTT and other protocols at the edge.

  5. Equipment and controllers

    Sensors, PLCs, drives and historians that produce the raw signals.

Conceptual layering of a multi-vendor digital twin. Standards are shown where they are typically applied; real systems often blur the boundaries.

What each standard defines, and what it leaves to you

StandardWhat it definesStrong atLeaves to you
OPC UA (IEC 62541)A platform-independent, service-oriented architecture with information modeling, security and a PubSub option12Structured, secure access to equipment data, with industry companion specifications1Which assets matter, cross-site identity and the twin's behavior model
Asset Administration Shell (IEC 63278-1)A standardized digital representation of an asset, organized into submodels and submodel elements with a uniform interface3Vendor-neutral asset identity and descriptive information across the lifecycleLive behavior models and scenario logic
DTDLA language for twin interfaces, built on JSON-LD and RDF5Graphs of twins and their relationships on platforms that use itEquipment access and cross-vendor asset semantics
ISO 23247-1The framework, vocabulary and requirements for digital twins in manufacturing6A shared vocabulary for scoping and reviewing a manufacturing twinConcrete data formats and APIs
NGSI-LD (ETSI GS CIM 009)An API for context information management across domains7Linking entities from different domains, such as a plant and its surroundingsDetailed industrial asset semantics

OPC UA is treated briefly here. Its role alongside MQTT and a unified namespace is covered in the unified namespace, OPC UA and ISA-95 guide.

Asset Administration Shell: identity first, then submodels

The Asset Administration Shell (AAS) gives each asset, physical or not, a shell with a global identity and a set of submodels: for example a digital nameplate, technical data, documentation or operational data. IEC 63278-1 sets out this structure3, and the Industrial Digital Twin Association publishes the detailed specifications in parts covering the metamodel, APIs, data specifications based on IEC 61360 and on units of measurement, security and the AASX package format4.

Its value for a twin is that suppliers can deliver asset information in a known shape, and the operator can add submodels for their own needs without inventing a new format. The trade-off is effort: submodels need to be populated and kept current, and older equipment rarely arrives with a shell. Start with the submodels the first decision actually uses.

DTDL and graph-shaped twin models

DTDL, the Digital Twins Definition Language, describes twin types as Interfaces whose contents are Telemetry, Properties, Commands, Relationships and Components8. Relationships point to other twins by reference, so a site can be modeled as a graph: a pump feeds a header, which serves a zone. Version 3 is used by Azure Digital Twins and IoT Plug and Play, and a version 4 is listed for Azure IoT Operations5.

DTDL is a good fit for the twin-graph layer when the chosen platform uses it. It is not designed to be the plant-wide asset description, and units are not native to the core language in version 3; they come through the QuantitativeTypes extension8. Keep DTDL models generated from, or mapped to, your canonical asset model rather than letting them become the only place that knowledge lives.

Mapping rules to agree before connecting a second vendor

0 of 6 checked

Picking a combination of standards for your situation

  • If

    Your equipment already exposes OPC UA servers, ideally with companion specifications.

    Then

    Use OPC UA as the access layer and map its information model into your asset description.

    Re-modeling data that already arrives structured adds work and risk.

  • If

    You buy equipment from many suppliers and want asset information delivered in one shape.

    Then

    Specify Asset Administration Shell submodels in procurement for new equipment.

    It moves the cost of describing assets to the point where the supplier knows them best.

  • If

    Your twin platform models assets as a graph using DTDL.

    Then

    Generate DTDL interfaces from your canonical model and keep the mapping in version control.

    You can then replace the platform without losing the asset knowledge.

  • If

    The twin must relate plant assets to data from other domains, such as a city or a grid.

    Then

    Evaluate NGSI-LD for the cross-domain context layer.

    It is designed for linking entities across domains rather than describing machines in depth.

Lock-in traps in twin data architecture

The platform's model becomes the only model

Early signalAsset relationships exist only inside one vendor's twin service.

MitigationHold a canonical asset model in a neutral form and treat platform models as generated outputs.

Proprietary connectors hide mappings

Early signalNobody can export the tag-to-asset mapping as a file.

MitigationRequire exportable mappings and documented transformations in contracts.

Standards adopted in name only

Early signalA shell or interface exists, but key submodels are empty or vendor-specific.

MitigationDefine the minimum required submodels and fields, and test deliveries against them.

Questions and answers

Do we need to adopt all of these digital twin standards?

No. Most projects use two or three. A common combination is OPC UA for equipment access, the Asset Administration Shell for asset descriptions and the twin platform's own modeling language for the graph, with ISO 23247 used as a reference vocabulary when scoping a manufacturing twin. Add a standard only when it removes a mapping you would otherwise maintain by hand.

What about legacy equipment that does not support OPC UA?

Use a gateway or edge device that reads the native protocol, such as Modbus or a vendor fieldbus, and republishes values with identity, units and timestamps added. Document each mapping, because the gateway becomes the place where meaning is attached. Plan to replace the mapping with native support when the equipment is renewed.

Can the Asset Administration Shell and DTDL be used together?

Yes. They serve different layers. The shell describes what an asset is and holds its information in submodels; DTDL can describe the twin types and relationships a particular platform uses to run scenarios. Keep the mapping between them explicit and versioned so a change in one is reflected in the other.

When does NGSI-LD make sense for a digital twin?

When the twin has to relate entities from different domains, such as factory assets, building systems, traffic and weather, and exchange that context with other organizations or city platforms. For detailed machine semantics inside one plant, industrial standards such as OPC UA companion specifications and AAS submodels are usually the better fit.

Sources

  1. Unified Architecture — OPC Foundation · checked 10 October 2026
  2. IEC 62541-1:2025 OPC unified architecture – Part 1: Overview and concepts — Standards Council of Canada (catalog entry) · checked 10 October 2026
  3. IEC 63278-1:2023 Asset Administration Shell for industrial applications – Part 1: Asset Administration Shell structure — IEC · checked 10 October 2026
  4. AAS specifications — Industrial Digital Twin Association · checked 10 October 2026
  5. Digital Twins Definition Language (DTDL) repository — Microsoft (GitHub) · checked 10 October 2026
  6. ISO 23247-1:2021 Automation systems and integration — Digital twin framework for manufacturing — Part 1: Overview and general principles — ISO · checked 10 October 2026
  7. ETSI GS CIM 009 V1.8.1 Context Information Management (CIM); NGSI-LD API — ETSI · checked 10 October 2026
  8. Digital Twins Definition Language (DTDL) version 3 — Microsoft (GitHub) · checked 10 October 2026

More in Digital Twins

Back to Digital Twins

Next step

Send us your equipment list and we will sketch the twin data layers

Share the main equipment types, the protocols they expose and the systems that already hold asset data. We will reply with a suggested layering, the identity scheme to agree first and the mappings that carry most risk.

Review my twin data model