Our Product Passport Is an Asset Administration Shell

Two worlds that never spoke to each other

On a factory floor, a product already has a digital twin. It is called the Asset Administration Shell (AAS) — Verwaltungsschale in the original vocabulary — and it has been the backbone of German Industrie 4.0 for a decade. MES, PLM, machine configurators and commissioning tools read it natively.

Alongside it, since the ESPR and the Batteries Regulation, the same product must carry a Digital Product Passport: a regulatory, public object built around compliance, lifecycle and end of life.

For a machine builder, an appliance manufacturer or a battery pack maker, the question was never "which of the two". It was "how many times will I have to describe the same product". A regulatory passport on one side, a digital twin on the other, and a home-grown export to maintain in between.

We decided to remove the middle: an Arianee passport is served, as is, as a standard Asset Administration Shell.

The AAS in five lines

The Asset Administration Shell is standardised as IEC 63278-1 and specified by the IDTA (Industrial Digital Twin Association), the consortium that carries the industrial digital twin together with Plattform Industrie 4.0.

Its structure is simple: a shell identifies an asset, and information is filed into submodels — one per aspect. The IDTA publishes a normative catalogue: Digital Nameplate (IDTA 02006), Technical Data (02003), Carbon Footprint and Environment (02023), Handover Documentation (02004), Hierarchical Structures for bills of material (02011).

The IDTA has also opened a DPP4.0 workstream whose thesis is exactly the one in this article: the European product passport does not need a brand-new format, it needs to be expressed in the model industry already uses — work run in coordination with the IEC and CEN-CENELEC JTC 24.

What is implemented

The platform exposes the canonical AAS Part 2 façade. Identifiers in paths are base64url-encoded as the specification requires, and the shell identifier is derived from the passport identifier.

•GET /shells/{id} — the AssetAdministrationShell object, with its assetInformation and references to every submodel.
•GET /shell-descriptors/{id} — the registry Shell Descriptor (AAS Registry / DTR).
•GET /submodels/{id} — a full submodel, with the ?content= (normal, value, metadata) and ?level= (deep, core) modifiers.
•GET /submodels/{id}/submodel-elements/{idShortPath} — one element, resolved by idShort path.
•GET /lookup/shells — Basic Discovery: from a data carrier to its shell.

Three points matter more than the list.

One submodel per data profile, carrying its semantics. Every schema selected by the passport becomes a distinct submodel, stamped with the schema's semanticId. For the SAMM models of the battery passport, semantics go all the way down to the property: each SubmodelElement carries the aspect-model URN it came from, not just the envelope.

The bill of material is navigable. A passport can declare its components; they are rendered in the normative IDTA 02011 shape — an EntryNode, one entity per component, HasPart relationships. Each component is referenced by its data carrier, which /lookup/shells resolves to that component's own shell. In practice: from a telehandler down to its battery pack, then to that pack's regulatory battery passport, with no proprietary directory service in between.

Nothing is duplicated. The shell and its submodels are generated on the fly from the passport's live data. There is no second copy to resynchronise, so no drift between the passport a consumer reads and the twin a machine reads.

Catena-X: where we stand

Catena-X is the European automotive data space. Its product passport building block is the Eco Pass, standardised as CX-0143 and implemented open source in Eclipse Tractus-X. OEMs and tier ones are pushing their suppliers towards it.

What is in place on the platform:

•The Catena-X DigitalProductPassport aspect (io.catenax.generic.digital_product_passport), with metadata and identification blocks shaped per the official aspect model. The default is version 4.0.0, the one referenced by the released CX-0143; newer versions are configurable.
•The economic operator's BPNL identity, carried through to metadata.economicOperatorId.
•The Industry Core specificAssetIds in the shell descriptor — manufacturerId, manufacturerPartId, digitalTwinType — with the visibility setting that goes with them: part-type identifiers are public by default, the serial number stays restricted.
•The CX-0002 EDC addressing: once the connector is configured, descriptor endpoints carry subprotocol: DSP and the body a consumer uses to negotiate its access contract.

And what is not: Eco Pass certification is in progress, not obtained. It runs through a Conformity Assessment Body (CAB) mandated by Catena-X, as it does for every application provider in the ecosystem. We will publish the date once it is signed, and not before.

What this actually changes

You stop describing the product twice

The regulatory passport and the digital twin are the same object, served through two views. The integration you fund for ESPR compliance also feeds your industrial tooling, and the other way round. The cost line that disappears is the integration, more than the licence.

Your existing tools read the passport with no development

A conformant shell loads in AASX Explorer, in BaSyx, in any AAS client. A manufacturing engineering team can open a product passport the same day, without waiting for someone to write them a connector. It is also what makes acceptance testing real: you verify against a third-party tool rather than against our own documentation.

An automotive customer can consume you

If your customer asks for a Catena-X Eco Pass, the answer is not a six-month project. The aspect model, the BPNL, the Industry Core identifiers and the dataspace addressing are already there; what remains is connector configuration and access-contract negotiation, which are deployment matters.

You are not betting on a single standard

The same passport is already served through three standardised surfaces: AAS / Catena-X for industry and automotive, CEN/CENELEC EN 18222-18223 for the future European registry, and the business API for your own applications. One set of data, three grammars. On the day the delegated act for your product category settles on one of them, there is no migration to run.

Granularity follows the regulation

The shell declares an assetKind aligned with the passport's granularity: Type for a model, Instance for a batch or an item. That is the distinction the ESPR and the Batteries Regulation impose, and it is carried by the standard rather than by an internal convention.

What it does not solve

Three limits, stated up front.

Certification is not compatibility. Serving the CX-0143 aspect correctly and being certified as a Business Application Provider by a CAB are two different things. We are in the first, on our way to the second.

The data space needs a connector. A descriptor without DSP addressing yields a twin that is registerable but not consumable through the data space. An EDC is deployed and configured; it is not a toggle in a user interface.

The AAS does not replace compliance. Expressing a passport in the right format says nothing about the completeness of the regulatory data. That is the compliance engine's job, upstream, and it remains in full.

Why it matters now

The regulatory calendar and the industrial calendar are converging. The battery passport is due on 18 February 2027, the first ESPR delegated acts follow, and at the same time automotive customers are pushing their suppliers into Catena-X.

A manufacturer treating those two movements as two separate projects will pay twice, and will maintain two versions of the truth about the same product. Treating them as one requires infrastructure that speaks both languages natively.

That is the point of this implementation: the format in which you will have to deliver your product data is not fully settled yet, and it should be neither a decision you make today, nor one you make again in three years.