For a supplier, the Asset Administration Shell is a standard digital package that describes the product you ship, delivered as an AASX file or served through an API, so your German customer's systems can read the nameplate, technical data and documents without anyone retyping them. If you make sensors in Pune, gearboxes in Ohio or control panels in the Midlands and sell into German machine building, expect the question "can you supply an AAS?" to appear in purchase specifications and supplier questionnaires.
We covered the concept in our Asset Administration Shell explainer. This article is the supplier's view: what customers are likely to ask for first, which details trip up non-German suppliers, and how to produce a first shell for one product family without buying a platform.
Why the Asset Administration Shell for suppliers is becoming a purchase requirement
German component makers are committing to it. In December 2025, 75 electrical and digital companies signed a declaration with IDTA and ZVEI to integrate the AAS into their products within 12 months (all-about-industries). When the drives, sensors and controllers inside a machine arrive with shells, the machine builder wants the rest of its bill of materials to match, and that includes you.
Regulation adds a second push. The EU Ecodesign for Sustainable Products Regulation, (EU) 2024/1781, has been in force since 18 July 2024 and introduces a Digital Product Passport, described by the Commission as a digital identity card for products, components and materials (European Commission). IDTA already publishes AAS templates for passport data, so customers see the shell as the natural carrier.
The submodels customers ask for first
A shell is a container; submodels hold the content. IDTA publishes the templates (IDTA submodel templates). Requests usually start with the following:
| Submodel template | IDTA number | What it carries |
|---|---|---|
| Digital Nameplate for Industrial Equipment | 02006 (v2.0) | Manufacturer, product designation, serial number, markings |
| Contact Information | 02002 (v1.0) | Who to call for service, sales and support |
| Generic Frame for Technical Data | 02003 (v2.0) | Technical properties, ideally keyed to ECLASS or IEC CDD |
| Handover Documentation | 02004 (v2.0) | Manuals, certificates, declarations with metadata |
| Digital Product Passport, Part 1: Metadata | 02099 (v1.0) | Passport data points per EN 18223:2026 |
For batteries, IDTA publishes a seven-part Digital Battery Passport, conformant to DIN DKE SPEC 99100, covering nameplate, handover documentation, carbon footprint, technical data, product condition and more. If you supply storage systems or battery packs into Germany, start there.
Identifiers: the detail that breaks most first attempts
Every shell and every asset needs a globally unique, stable identifier. Change it later and every system that linked to it breaks. Decide early whether you supply a type shell (one per product type) or instance shells (one per serial number); customers increasingly want both, with each instance pointing at its type.
On the physical product, IEC 61406-1:2022 defines the Identification Link: a globally unique identifier in URL format, attached to the object as a 2D symbol or NFC tag, that leads to its digital information (IEC). In practice that is a QR code on the nameplate that resolves to your shell or product page. It does not prescribe the layout of the nameplate itself, so you can add it to an existing plate.
Building your first shell, step by step
- Pick one product family with steady volumes into Germany and a customer who has asked.
- Collect the data you already have: type plate content, data sheet values, manuals, declarations of conformity, certificates. Most of it exists in PDFs and ERP fields.
- Map each value to a template property and its ECLASS or IEC CDD identifier. Leave out what you cannot fill reliably rather than guessing.
- Build the shell in the open-source AASX Package Explorer, which reads and writes AAS files.
- Attach documents through the Handover Documentation submodel with proper metadata, not as loose PDFs.
- Assign identifiers for the shell, the asset and each submodel, and record them in your product master data.
- Send the AASX file to the customer and ask what their system could and could not read. Fix the gaps before scaling to other product families.
Digital Twin Expert Talks Ep.5: AAS through the entire life cycle (Michael Hoffmeister)
Industrial Digital Twin Association
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeMistakes we see from suppliers outside Germany
- Treating the AAS as a one-off export for one order instead of part of product master data.
- Filling the Digital Nameplate from marketing copy instead of the legal type plate.
- Shipping documents in one language when the customer needs German operating instructions. Our article on AI search for technical manuals explains why German instructions are required.
- Regenerating identifiers with each software update of the shell.
- Waiting for a platform decision. A file-based AASX is a legitimate and useful first deliverable.
When live data matters
Static shells describe what you shipped. If your product has a controller, the customer may later want live values such as operating hours or energy consumption. That is where OPC UA and the AAS meet: the shell describes the asset, OPC UA carries the live data. Our comparison of OPC UA vs Asset Administration Shell covers the split, and the ISO 23247 framework shows where both sit in a full manufacturing twin.
Where Wartens fits
Wartens builds machine and line twins for German machine builders and can structure them for interoperability on request, for example with the Asset Administration Shell in mind. For machines with PLCs we can also design the controller data so that live values are ready for OPC UA. See our digital twin services and automation engineering.
Next step: send us the data sheet and type plate of one product and we will propose a submodel structure for your first shell. Contact us.
