Top Interoperability Standards for Digital Twins: A 2026 Business Guide

Let AI summarize this article instantly

ChatGPT Perplexity Claude Grok Gemini

A digital twin becomes drastically more useful if it can exchange information with the systems it needs to communicate with.

A manufacturing twin needs data from PLCs and sensors, engineering models from CAD systems, maintenance records from an EAM platform, production information from an MES, and analytics from a cloud platform. If those systems use different data structures, protocols and naming conventions, the twins will not be accurate and identical.

Interoperability standards for digital twins address these very challenges. Businesses have to follow an established set of approaches for a number of causes like representing assets, exchanging information, connecting systems, and giving different applications enough context to interpret the data they receive.

ISO 23247, for example, is a framework for manufacturing digital twins, OPC UA’s focus is on industrial information exchange and communication, the Asset Administration Shell provides a standardized digital representation of an asset, and MQTT addresses lightweight messaging.

The reason these distinctions are so important is because businesses have to consider those at the architecture and design level.

Before looking at interoperability standards, it helps to understand how digital twins connect physical assets with their virtual counterparts and why that connection becomes more complex as businesses expand their twin ecosystems.

In brief: Digital twin interoperability standards are established mandates that denote how digital twins are named, modeled, connected, and exchanged between systems and organizations. Some of the most widely referenced are ISO 23247, ISO/IEC 30173, the Asset Administration Shell (IEC 63278), OPC UA, DTDL, and NGSI-LD.

What is Digital Twin Interoperability?

Digital twin interoperability is the ability of digital twins, physical assets, software applications and data platforms to exchange and interpret information across different technologies, platforms, and lifecycle stages.

It has several layers.

• Syntactic interoperability means systems can exchange data using compatible structures or formats.
• Semantic interoperability means the receiving system understands what the data represents. For example, both systems need to interpret “temperature” in the same way.
• Communication interoperability concerns how systems exchange messages and commands.
• Model interoperability defines how physical and digital assets, relationships, properties and behaviors are represented.
• Lifecycle interoperability extends the connection for engineering, production, maintenance and other stages of an asset’s life.

This distinction businesses need to be aware of because adopting MQTT, for example, does not automatically make two digital twins semantically interoperable. Also, MQTT can transport messages, but the applications still need an agreed way to describe and interpret the payload.

Importance of Interoperability in Digital Twin?

Industry experts have been observing a rising spending on twins is rising quickly. Grand View Research valued the global digital twin market at USD 35.8 billion in 2025, estimated USD 49.5 billion for 2026, and projected USD 328.5 billion by 2033, a compound annual growth rate of 31.1%.

Other analysts apply narrower definitions and report lower baselines, such as USD 18.9 billion for 2025 from Global Market Insights, yet every forecast points upward, and these digital twin statistics and market growth forecasts offer further figures. As the number of twins in one business grows, the cost of connecting them naturally outpaces the cost of building them.

Practitioner evidence agrees. A survey reported in a 2025 overview of digital twins in defense found that 62% of respondents cited interoperability issues as the major consequence of the barriers to twin development and operation, compared with 24% for deployment delays, 10% for higher costs, and 4% for security risks.

Interoperability for digital twins helps organizations:

• Connect heterogeneous devices and applications
• Reduce dependence on proprietary interfaces
• Reuse digital twin models for multiple systems
• Maintain consistent asset information
• Support data exchange throughout the asset lifecycle
• Integrate legacy and modern technologies
• Enable multi-vendor digital twin ecosystems
• Create a foundation for analytics, simulation and AI, including predictive maintenance with digital twins

Top Digital Twin Interoperability Standards

The table highlights the most important digital twin interoperability standards at a glance:

ISO 23247: Digital Twin Framework for Manufacturing

Best suited for: Manufacturing digital twin architecture and lifecycle interoperability.

ISO 23247 is a multi-part series titled Digital twin framework for manufacturing.

• Part 1, published in October 2021, sets out general principles and requirements. 
• Part 2 defines a reference architecture.
• Part 3 covers the digital representation of manufacturing elements.
• Part 4 addresses information exchange, with use cases documented in its annexes.
• Part 5, on the digital thread, was published in June 2026.
• Part 6, on digital twin composition, has reached the final draft stage of approval.

What the Series Standardizes

The series describes a layered architecture for what it calls observable manufacturing elements, and it rests on the IoT reference architecture in ISO/IEC 30141. It does not prescribe a single wire format.

An implementation selects the models best suited to its use, and the text names existing options such as ISO 10303 (STEP), IEC 62264 (ISA-95), the Asset Administration Shell, IEC 62541 (OPC UA), MTConnect, and QIF.

Where It Fits and Where It Stops

ISO 23247 gives an architecture board a defensible reference model. It leaves the choice of exchange format, protocol, and semantic model to other standards, so most programs pair it with the specifications below. The newer parts on digital thread and composition address relationships between twins, where the integration burden grows.

Asset Administration Shell (IEC 63278)

Best suited for: Standardized digital representations of industrial assets.

The Asset Administration Shell (AAS) is central to the European Industry 4.0 approach to interoperable asset information.

IEC 63278-1:2023 defines the structure of an Asset Administration Shell, which provides standardized access to information and services associated with an asset. It applies in industrial processes and asset lifecycles, including physical, digital and intangible entities.

An AAS can contain different submodels representing specific aspects of an asset. One submodel could describe technical specifications, another could contain operational information, and another could represent maintenance-related data.

This structure allows applications from different vendors to work with a common digital representation rather than creating a custom interpretation for every asset.

The standard is also evolving. IEC 63278-4:2026, published in September 2026, focuses on applications of the Asset Administration Shell and provides additional requirements and recommendations for selected scenarios.

For businesses working toward Industry 4.0 interoperability, AAS is particularly relevant when the challenge is how an industrial asset should be represented and described with consistency.

OPC UA: Runtime Connectivity for Plant Systems

Best suited for: Industrial communication, information modeling and machine-to-business interoperability.

OPC UA is widely used in industrial environments because it combines communication capabilities with well-structured information models.

Its architecture supports discovery, transport, information access, security and reliability. Information models can then be layered on top to represent real-time and historical variables, alarms and industry-specific concepts.

OPC UA Companion Specifications extend this approach for specific industries, devices and use cases. These specifications allow organizations to exchange standardized industry information models rather than simply moving raw values between systems. OPC Foundation describes this as interoperability at the semantic level.

For a digital twin, that distinction is significant.

Consider a production machine exposing a spindle-speed value. A basic connectivity protocol can transport the number. An OPC UA information model can provide context around what that value represents, its type, relationships and other associated information.

OPC UA therefore fits well between the physical or operational environment and higher-level digital twin applications.

DTDL: A Modeling Language for Cloud Twin Graphs

The Digital Twins Definition Language (DTDL) is a JSON-LD-based language for describing twin models, their properties, and the relationships between them. Microsoft documents that Azure Digital Twins supports DTDL versions 2 and 3, recommends version 3 for new modeling, and states that DTDL is not exclusive to Azure Digital Twins.

That openness allows other platforms to adopt it, although teams should confirm tool support for the version they choose, because the Azure Digital Twins Explorer has handled version 3 models with limited functionality. Checking this kind of tool support is also a core step when choosing the right digital twin platform for your architecture.

DTDL suits the model layer inside a cloud platform, and it does not replace the industrial exchange standards. Research in the journal Sensors demonstrated a transformation from DTDL to AAS, tested on a physical asset, so the two can be bridged. Teams with a mixed estate should budget for that mapping and keep it under version control.

MQTT

Best suited for: Lightweight, scalable telemetry and event messaging.

MQTT is a messaging protocol rather than a complete digital twin modeling standard.

The OASIS MQTT 5.0 specification defines a lightweight client-server publish/subscribe protocol designed for machine-to-machine and IoT environments. It supports different quality-of-service levels and decouples publishers from subscribers.

This makes MQTT useful when digital twins need continuous streams of sensor or device data.

For example:

Sensor → Edge gateway → MQTT broker → Digital twin platform → Analytics application

MQTT handles the message transport efficiently, particularly where devices have limited resources or networks have bandwidth constraints.

However, organizations should avoid treating MQTT alone as a semantic interoperability solution. The protocol is intentionally agnostic about the content of its payload. The payload still needs a meaningful data model, schema or information model.

This is why MQTT is often paired with interoperability standards for digital twins, such as OPC UA, AAS, or domain-specific information models.

W3C Web of Things

Best suited for: Web-based interoperability in heterogeneous IoT systems.

The W3C Web of Things (WoT) addresses a different interoperability for digital twins challenge: how diverse connected things can be described and exposed through a common web-oriented model.

The W3C WoT Thing Description 1.1 is a formal information model describing the metadata and interfaces of physical or virtual things. It supports properties, actions and events, along with data schemas, security definitions and protocol-related information.

Its use of JSON and JSON-LD also gives the model a route toward machine-readable semantics.

For digital twins, WoT can help describe how a connected asset can be discovered and interacted with without requiring every application to understand the underlying device implementation.

The current W3C landscape is also worth watching. Thing Description 1.1 remains a Recommendation, while Thing Description 2.0 and related WoT deliverables are under development.

WoT is therefore particularly interesting for organizations building distributed IoT and digital twin ecosystems that need web-friendly discovery and interaction.

ISO 10303 STEP

Best suited for: Engineering and product lifecycle data exchange.

ISO 10303, commonly known as STEP, addresses product data representation and exchange. Its relevance to digital twins becomes apparent when engineering information needs to move between CAD, PLM, manufacturing and other lifecycle systems.

ISO 10303-1:2024 defines the architectural principles and structure of the broader STEP series, including its approaches to representing and exchanging product information.

For a digital twin, STEP can provide important engineering and product context that operational telemetry alone cannot supply.

For example, a manufacturing twin may combine:

• Product geometry
• Engineering specifications
• Manufacturing data
• Equipment telemetry
• Maintenance information
• Production history

STEP is therefore valuable when interoperability extends from shop-floor data into engineering and product lifecycle environments, as in digital twins used for product development and design validation.

How to Choose Digital Twin Standards for Your Business

The right standards depend on the systems you need to connect and the information those systems must exchange. For the wider program context, a guide to digital twin strategy and adoption covers the planning steps around these choices.

1. Match Standards to the Domain

Manufacturers usually begin with ISO 23247 as the reference model, the AAS for exchange with partners, and OPC UA for plant connectivity. City and utility programs tend to begin with NGSI-LD and the Smart Data Models. Organizations that build twin graphs inside a cloud platform will meet DTDL, and should plan the mapping to whichever exchange standard their partners require.  

2. Build a Layered Stack Instead of Selecting One Winner

A workable stack assigns one standard to each layer and documents the mappings between them. A typical manufacturer might adopt ISO/IEC 30173 for vocabulary, ISO 23247 for architecture, OPC UA at the machine boundary, the AAS for lifecycle and partner exchange, and DTDL inside the cloud platform.

Added mappings carry an engineering cost, so the stack should follow actual integration needs.

Questions to Put to Every Vendor

• Which versions of each standard do you support and what is your policy when a version changes as with AAS 3.0 or DTDL 3?
• Can twin models be exported and imported in an open format without paid tooling?
• Which mappings between standards ship with the product, and which are left to the customer?
• How are identity, authorization, and audit handled when twin data crosses company boundaries?

Buyers comparing providers can pair these questions with guidance on how to choose a digital twin development partner.

Pitfalls That Delay Programs

Teams sometimes model assets before the vocabulary is agreed. The outcome of this practice is forced rework after a second business unit joins. Others treat a claim of standard support as proof of interoperability for digital twins, when conformance often covers only part of a specification. 

Brownfield equipment and missing version policies complete the usual list, and a sound IoT development and data engineering foundation reduces the effort of bridging older assets.

Next Steps for Your Digital Twin Standards Strategy: How MindInventory Can Help

Before MindInventory’s engineering team writes any twin logic, the standards stack is already documented – one specification per layer, one canonical information model, and a mapping register that names an owner for every translation between formats.

Later work inherits those decisions, the reason being when a second plant, a new supplier, or a change of cloud platform becomes a configuration task, it leaves the architecture intact.

How an Engagement Proceeds

1. Assessment: reviewing your asset inventory, existing protocols, and partner data requirements.
2. Architecture and standards roadmap: defining the layer-by-layer stack, the canonical model, and the mapping plan.
3. Pilot twin: building one twin against the agreed model and testing every interface for conformance.
4. Scale-out: extending the model to further assets, sites, and suppliers under version control.

If your organization is planning a new twin program or reconciling several existing ones, our team can review your current architecture, identify standards gaps, and create a roadmap tailored to your assets and partners. Explore our digital twin development services to see how we can support your initiative. Connect with us to schedule an architecture review.

Send your integration constraints.

A senior architect replies with scope options and a call slot.

Schedule an Architecture Review

FAQs