The Asset Administration Shell is well documented and poorly explained in the Industrie 4.0 context. The specification describes precisely how a shell is structured. It does not describe why anyone would want one.
Starting point
In a grown manufacturing operation, every system describes the same machine differently: the ERP knows an asset number, maintenance knows a serial number, the controller knows an IP address. Anyone wanting to answer a question about the machine first has to know where they are allowed to ask.
One level down, at the supplied component, the pattern repeats. The pump manufacturer has its data in full, as a catalogue PDF, as a spreadsheet in sales, as a manual in the shipping box. At the customer’s end, whatever is needed at that moment gets retyped, and the rest is left untouched.
One level further out, at the company’s own product leaving the plant, what ships with it is a stack of paper or a download link. Installation, maintenance, resale and disposal then happen outside the manufacturer’s view.
The same problem three times over. The description exists in each case, but in a form only humans can read, and freshly at every station.
The Asset Administration Shell stores that description once in a standardised way, following the same rules for every asset, whether it is a machine, a component or a product. That makes it what is commonly called a digital twin, only in a defined form: the term describes the idea, the shell gives it a format two companies can agree on without having talked to each other beforehand.
Difference from an in-house format
Any company could define a uniform store for itself. The difference from such an in-house structure is organisational rather than technical. The Asset Administration Shell is maintained by the Industrial Digital Twin Association, exists in version 3, and its metamodel is standardised in the IEC 63278 series. Access runs through a single API instead of an interface renegotiated with every partner.
In practice that means a supplier produces the description of its component once, and every customer can read it without agreeing a data model first. That is the actual gain. It only materialises once both sides genuinely use the same standard.
Type and instance
Produced once, but for the product line or for each individual unit? The specification answers this with two kinds of shell, and the distinction explains a great deal in practice.
The type shell describes a product or product line, in substance what used to be the catalogue: dimensions, performance data, permissible operating conditions, manual. It applies to all units alike and always reflects the current state.
The instance shell belongs to a single unit that was actually manufactured: serial number, production data, later the maintenance history. It is the digital twin in the narrower sense: the twin of this one unit, not of the design.
Operations mostly care about the instance, sales about the type. The two belong together: the instance references its type rather than repeating its data. What holds for the design is stated exactly once.
Product description and documentation in one place
Both are filled the same way: with submodels. The IDTA standardises these submodels individually; more than 70 are available by now. Three of them together cover what is generally called product documentation:
- Digital Nameplate: the digital type plate with manufacturer, type designation, serial number and year of construction, machine-readable instead of a sticker on the housing.
- Technical Data: technical characteristics, classified against ECLASS or IEC CDD, so comparable properties instead of prose in a datasheet.
- Handover Documentation: the handover pack with drawings, manuals and certificates, classified to VDI 2770 and referenced as files.
This turns the Asset Administration Shell into the product description including its documentation, in one place instead of spread across a datasheet, a PDF folder and an ERP field.
The basis for the digital product passport
That assembles what ought to accompany a product throughout its life. It is also what legislators now require. The Digital Product Passport comes from the Ecodesign Regulation (EU) 2024/1781, in force since 18 July 2024. It calls for a structured dataset that accompanies a product across its lifecycle and documents material composition, recycled content, repairability and disposal. It has to remain available for ten years beyond the product’s lifetime.
Back to type and instance: a product passport sits close to the instance without coinciding with it. The underlying idea is the same, a standardised description attached to the object. What is added are regulated access rights, prescribed content, and a different audience: not the operator, but customers, testing bodies and eventually the recycler.
How close is decided case by case. The Ecodesign Regulation does not prescribe that a passport belongs to exactly one manufactured unit; whether it sits at model, batch or item level is set by the respective delegated act. For the Asset Administration Shell that is familiar ground: a passport at model level meets the type, one at item level the instance, and the batch sits in between.
Batteries come first. From 18 February 2027, traction batteries, batteries for light means of transport and industrial batteries above 2 kWh require a battery passport. The Ecodesign working plan lists iron and steel, textiles, tyres, aluminium and furniture after that.
The working plan is not a commitment, however. At least 18 months pass between a delegated act being adopted and it applying, and postponements have so far been the rule rather than the exception. Anyone starting today should do so because the data is needed anyway, not because of a deadline.
Limits of the standard
So much for the prospect. The submodels prescribe the fields. They do not prescribe which values belong in them, where those come from, or who keeps them current. That is where the work sits.
A digital type plate is filled quickly. The technical characteristics bring the first real decision: which ECLASS properties are the right ones for this product? The handover documentation brings the second: which of the PDFs in the project folder is the valid version, and who notices when a new one arrives? And when the ERP and maintenance assign different values to the same machine, no format decides that; someone in the company does.
That is not an objection to the Asset Administration Shell but its side effect: it is a view onto existing data, not a data source. Where master data is poorly maintained, it makes that visible. It does not make it better.
When the effort pays off
Three situations in which the calculation works out. First: the same information is needed repeatedly, across plants, across system boundaries, towards customers and suppliers. Second: you supply components, and your customers’ purchasing departments increasingly request the shell along with the delivery; then it is less an IT project than part of the product. Third: your product falls under a product passport obligation. At that point the question is no longer whether, only when.
That leaves the case where none of this applies: a single machine in a single hall, nobody asking from outside, no regulation in force. There an Asset Administration Shell is effort without return. The right answer is then to wait, and not to build half of one as a precaution.
Trying it out
The AAS Suite is our own platform for creating, viewing and managing Asset Administration Shells. It is IDTA-compliant and has recently been released as open source.
At aas-ecosystem.de we show, together with M&M Software, how existing open-source building blocks combine into a running environment: BaSyx as the AAS server, the AAS Suite as the interface, the AAS Twin Engine for generating instances. The starting point is a Docker Compose file, and the first worked example is a digital product passport.