Skip to content
Product Data & Architecture

Digital Product Passport vs Digital Twin vs Asset Administration Shell (AAS)

Compare a Digital Product Passport, digital twin and Asset Administration Shell, including IDTA’s AAS-to-DPP pathway and when a simpler DPP is enough.

Reading time
8 min
Last verified
Sources
11
Share article
LinkedIn X Email
A large capacitor resting on a circuit schematic with a hand holding a phone showing an active passport and a green battery

A Digital Product Passport, a digital twin and an Asset Administration Shell can share product information, but they are not three names for the same thing. The useful distinction is the job each one owns, then whether combining them solves a real operational problem.

Direct answer

A Digital Product Passport is a governed set of product information with regulatory identity, access and interoperability requirements. A digital twin is a broader virtual representation of an asset, system or process and may include synchronised state, behaviour or lifecycle information. An Asset Administration Shell, or AAS, is a standardised industrial way to represent an asset and organise its information into submodels.

IDTA's current AAS v3.2 guidance makes the boundary explicit: an AAS is not, by itself, the DPP required by the European DPP standards. A DPP can, however, be derived from an AAS where the AAS contains the required regulatory-data submodels and DPP metadata.

You can therefore combine them, but you do not have to. A simple DPP can be implemented without a full digital twin or AAS stack. AAS and digital-twin architecture becomes more useful when the same product model must also support engineering structure, component relationships, operational state, service or controlled cross-company exchange.

Activatea Product.
Share
LinkedInXEmail
Navigate this page

DPP vs digital twin vs AAS

QuestionDigital Product PassportDigital twinAsset Administration Shell
Primary jobProvide governed product information required for the applicable DPP regimeRepresent an asset, system or process for a defined operational useStandardise an industrial asset representation and its submodels
Is it a legal DPP concept?YesNo, not by itselfNo, not by itself
Does it inherently require live state?NoOften includes synchronisation at a use-case-appropriate frequency, but definitions varyNo, the AAS model can contain static or changing information
Can it contain more than DPP data?It can contain permitted information, but the regulated DPP scope remains governedYesYes
Can it help produce a DPP?It is the target product-information object/systemIt can contain DPP-relevant informationYes. IDTA describes a pathway to derive a DPP from suitable AAS submodels and metadata
Is it universally required by ESPR?The DPP is required when the applicable product rules require oneNoNo

The three concepts overlap because they can describe the same physical product. They differ because overlap in data does not create overlap in purpose.

What a Digital Product Passport is

For architecture purposes, a DPP is the governed product-information layer required by the applicable product rules. Regulation (EU) 2024/1781 sets the horizontal requirements around identifiers, data carriers, interoperability, access and data exchange. Product-specific acts determine which data is required and at what legal granularity.

Nothing in that horizontal framework says a compliant DPP must simulate the product, mirror its live operating state or run predictive models. Those can be valuable capabilities, but they belong to a richer operational representation rather than to the minimum meaning of a DPP.

That is why the EU DPP Registry should also stay conceptually separate. The Registry records and validates defined registration information. It is not the DPP itself and it is not a digital twin.

What a digital twin adds

There is no single digital-twin definition that covers every industry without qualification. In manufacturing standards and industry definitions, the common idea is a virtual representation connected to a physical asset or process, with synchronisation at a frequency and fidelity appropriate to the use case.

That can add things a DPP may not need at all:

  • current condition or operating state;
  • engineering configuration;
  • simulation inputs and outputs;
  • maintenance or service history;
  • relationships between assemblies and components;
  • telemetry or other time-varying information;
  • behaviour needed by operational software.

A DPP can sit inside that wider representation, or draw from it, without becoming synonymous with it.

A useful test is: does the business decision depend on the product's changing operational state, or mainly on governed product information? If it is the latter, a full digital-twin architecture may be unnecessary.

What an Asset Administration Shell standardises

The Asset Administration Shell is an industrial representation architecture standardised through IDTA specifications and IEC 63278. It gives an asset a structured digital representation made up of identifiable information and submodels.

That makes AAS useful where organisations want reusable industrial semantics across engineering, production, service and lifecycle systems. It is not simply a DPP file format. An AAS may hold far more information than the regulated passport needs.

It also does not automatically become the source of truth. Your ERP, PLM, PIM, quality or evidence systems can remain authoritative while an AAS represents selected governed facts. The same principle is covered in which system should own each product fact.

IDTA's key boundary: an AAS is not by itself the DPP

IDTA's v3.2 DPP annex is unusually helpful because it says directly what industry diagrams often blur.

An AAS is not by itself the Digital Product Passport required by EN 18222 or EN 18223.

That does not make AAS irrelevant. It means the regulated DPP and the industrial representation should not be collapsed into one label.

The distinction protects two decisions:

  1. What must the DPP contain and expose under the applicable rules?
  2. What wider digital representation does the organisation want for engineering, lifecycle or exchange purposes?

Those decisions can lead to one technical implementation, but they start from different requirements.

How a DPP can be derived from AAS submodels

IDTA's current pathway is to keep DPP-relevant information in suitable AAS submodels and add the metadata needed to identify what forms the passport. A DPP can then be assembled or derived from that governed AAS content.

That is attractive when the organisation already uses AAS because it can avoid maintaining a second independent representation of the same facts. The DPP can become a regulated view over selected information rather than a disconnected copy.

But IDTA also acknowledges other methods. The current DPP ecosystem includes AAS and RDF-based approaches, with active interoperability work between them. Semantic interoperability is the requirement. One modelling stack is not established as the only universal legal route.

For the legal and semantic mapping problem itself, see what the EU's published definitions ask of your product data.

How Catena-X combines DPPs, digital twins and AAS

Catena-X is a concrete example of composition rather than a definition of what every DPP must be.

In Catena-X, digital twins are represented using AAS-aligned structures. A Digital Twin Registry supports discovery of twins and their aspects. The DPP use case attaches DPP-related information to those digital-twin and semantic structures, then exchanges selected information through the wider Catena-X data-space architecture.

That architecture is particularly relevant where several companies need controlled access to structured industrial information. It does not make AAS or Catena-X a requirement of EU DPP law.

The exchange architecture is covered separately in what a data space is and how Catena-X fits DPP architecture.

A simple DPP does not need a full twin stack

The strongest counterexample to overbuilding is that a DPP can be useful and compliant without being a live digital twin.

A comparatively simple architecture can use:

  • a persistent product identifier;
  • a durable web address or resolver;
  • a governed product record;
  • an appropriate data carrier;
  • the access controls required by the applicable rules;
  • EU Registry integration when the product is in scope.

CIRPASS-2 research has explored deliberately simple web-based DPP architecture. That does not prove the simple route fits every industrial use case. It does prove that a full twin/AAS stack is not inherent to the idea of a DPP.

The choice should follow the problem, not the vocabulary.

Choose the architecture by the problem

Public or mostly static compliance information

Start with the DPP requirement itself. If the information is largely stable, broadly accessible and already governed in existing systems, a durable web publication architecture may be enough.

Do not add a digital twin because the product has a serial number. Do not add AAS because it is an industrial standard unless the representation solves a real reuse or interoperability problem.

Industrial lifecycle and service representation

AAS and digital-twin architecture becomes more compelling where the same asset representation also needs to support engineering structure, condition, maintenance, service or component relationships.

In that case, deriving the DPP from governed submodels can reduce duplicate representations. The value comes from reuse across several real processes, not from labelling the passport a twin.

Cross-company controlled exchange

When several organisations need governed access to selected industrial information, a digital twin may be combined with a data-space layer such as Catena-X. The data space deals with participants, discovery, contracts, policies and transfer. The twin/AAS deals with representation. The DPP remains the regulated product-information requirement.

Keeping those jobs separate makes it easier to decide which layers you actually need.

What is settled now and what is still moving

NOW: AAS is a standardised industrial representation architecture. IDTA v3.2 explicitly distinguishes AAS from the DPP and documents an AAS-to-DPP derivation path. ESPR does not require a DPP to have real-time state, simulation or predictive behaviour. Catena-X currently uses AAS-aligned digital twins in its DPP architecture.

EMERGING: semantic convergence between AAS, RDF and other modelling approaches continues to develop. Different sectors will also make different choices about how much digital-twin capability sits behind their passports.

NOT ESTABLISHED: commercial products offering AAS, Catena-X or nested-product capability do not by themselves prove market-wide adoption or return on investment. Architecture capability and economic outcome are different claims.

What would change this page

This answer would need material review if:

  • IDTA materially changes the AAS v3.2 DPP boundary or derivation model;
  • a harmonised DPP standard or product-specific EU act makes AAS or a particular digital-twin implementation mandatory;
  • digital-twin standards materially change the composition boundary used here;
  • Catena-X materially changes how it represents DPP information through digital twins;
  • independent production evidence changes the case for simple versus richer architectures.

Keep exploring

The questions this page usually raises next.

Sources

Does this reach your products?

Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.

Activate My product How a value is decided