Asset Admin­is­tra­tion Shell (AAS)

What is an asset admin­is­tra­tion shell?

An asset admin­is­tra­tion shell is a struc­tured, machine-read­able container that holds all rele­vant asset infor­ma­tion across the asset life­cycle. In German the concept is called Verwal­tungss­chale, some­times trans­lated liter­ally as manage­ment shell. The asset can be almost anything that has value in produc­tion: a single sensor, a motor, a complete machine, a produc­tion line, a piece of soft­ware or even a service. Together, the phys­ical asset and its AAS form what the German Plat­tform Indus­trie 4.0 calls an Industry 4.0 compo­nent.

The idea goes back to the Refer­ence Archi­tec­ture Model Indus­trie 4.0 (RAMI 4.0), published in 2015. RAMI 4.0 described how assets should be repre­sented in the digital world, and the asset admin­is­tra­tion shell became the concrete answer: a stan­dard­ized digital twin that every vendor can imple­ment in the same way. Today it is a key concept of Industry 4.0 and the common data model behind initia­tives such as Manufacturing‑X and Catena‑X.

In simple terms: the asset is the thing, the shell is its digital iden­tity card plus every­thing you need to know to work with it. A drive manu­fac­turer delivers the motor together with its AAS. The machine builder reads it during engi­neering, the oper­ator uses it for commis­sioning and main­te­nance, and at the end of the life­cycle the same data supports repair, recy­cling and disposal.

Why manu­fac­turers need a stan­dard­ized digital twin

Almost every manu­fac­turer already has digital twins in some form: CAD models, data sheets, PLC vari­ables, ERP records, PDF manuals. The problem is that each of them uses its own struc­ture. A machine builder who buys compo­nents from twenty suppliers receives data in twenty formats and has to map every one of them by hand. Multiply this by the number of customers, soft­ware systems and life­cycle phases, and the inte­gra­tion effort explodes.

The asset admin­is­tra­tion shell replaces these point-to-point inte­gra­tions with one stan­dard­ized inter­face. Because the struc­ture, the meaning of each value and the way to access it are defined in the stan­dard, a soft­ware tool that under­stands one shell can under­stand all of them. Admin­is­tra­tion shells stan­dardize the data exchange and simplify it end to end, which is the precon­di­tion for smart manu­fac­turing and for scaling the indus­trial internet of things (IIoT) beyond single pilots. This is what inter­op­er­ability means in prac­tice: less custom inte­gra­tion code, fewer manual data trans­fers, and no depen­dency on a single vendor’s plat­form. It is also the reason the AAS plays a central role in avoiding vendor lock-in across indus­trial value chains.

How the AAS is struc­tured

The struc­ture of the AAS is defined in a meta­model (IDTA Part 1, version 3). Every AAS consists of the same hier­archy, no matter which asset it describes:

• The shell iden­ti­fies the asset with a glob­ally unique ID and states whether it describes an asset type (for example a product model) or a specific asset instance (one serial number). Type and instance shells are linked, so data from the product catalog carries over to each deliv­ered unit.
• Submodels group infor­ma­tion by topic, such as iden­ti­fi­ca­tion, tech­nical data, docu­men­ta­tion, carbon foot­print or oper­a­tional data. A shell can contain as many submodels as different use cases require.
• Submodel elements hold the actual content: prop­er­ties with values, collec­tions, lists, files, refer­ences to other assets and even oper­a­tions that can be called.
• Semantic IDs link every element to a shared defi­n­i­tion, for example from ECLASS or the IEC 61360 Common Data Dictio­nary, so that “rated voltage” means exactly the same thing at every vendor.

The modular design is what makes the AAS scale. A simple sensor may only carry a digital name­plate and tech­nical data. A complex machine adds main­te­nance records, time series data, energy consump­tion and soft­ware versions. Both follow the same struc­ture.

Submodel templates: stan­dard­ized building blocks

To keep submodels compa­rable across vendors, the IDTA publishes submodel templates. They define which prop­er­ties a submodel contains and what each one means. Commonly used templates include:

Passive, reac­tive, proac­tive: the three types of AAS

Not every shell has to be a running service. The stan­dard distin­guishes three levels of inter­ac­tion:

• Type 1, passive: the AAS is a file, usually an AASX package. It is exchanged like a docu­ment, for example attached to a delivery or down­loaded from a manu­fac­turer portal.
• Type 2, reac­tive: the shell runs on a server and answers requests through a stan­dard­ized REST API. Systems can read and update values in near real-time while the asset is in oper­a­tion.
• Type 3, proac­tive: the shell acts on its own, commu­ni­cates with other shells and nego­ti­ates, for example, a produc­tion order. This level is still mostly in research and pilot projects.

Most indus­trial projects today work with types 1 and 2. In the Open Industry 4.0 Alliance, the Proac­tive AAS project explored the next step and published a submodel proposal for rule-based AAS behavior, which links machine-read­able rules to AAS elements to vali­date values and trigger events.

AAS, OPC UA and MQTT: how they fit together

A common ques­tion is whether the AAS competes with OPC UA or MQTT. It does not. The three solve different prob­lems and work best together:

• The asset admin­is­tra­tion shell defines the content: what infor­ma­tion exists about an asset over its entire life­cycle and what it means.
• OPC UA provides a rich infor­ma­tion model and secure commu­ni­ca­tion on the shop floor, ideal for live machine data. A companion spec­i­fi­ca­tion maps the AAS meta­model to OPC UA.
• MQTT is a light­weight trans­port that distrib­utes events, for example the message that a submodel has changed.

The OI4 Product Change Noti­fi­ca­tion demon­strator shows how the three work together: a supplier publishes a change in a PCN submodel on an Eclipse BaSyx server, an MQTT broker noti­fies subscribed customers, and their systems read the shell to check which assem­blies are affected.

What the asset admin­is­tra­tion shell is used for

Admin­is­tra­tion shells pay off wher­ever product data crosses a boundary between compa­nies, systems or life­cycle phases. OI4 members have tested these use cases in joint projects:

• Digital Product Pass­port: a proof of concept gener­ates the shell of a config­ured bicycle from the shells of its compo­nents and calcu­lates the product carbon foot­print along the way. The result is a Digital Product Pass­port built from real produc­tion data, not static docu­ments.
• Auto­matic asset onboarding: the SCADA plat­form zenon reads the Asset Inter­faces Descrip­tion submodel from an AAS repos­i­tory and connects Modbus, HTTP and MQTT devices without manual config­u­ra­tion.
• Product change noti­fi­ca­tions: compo­nent changes reach customers as struc­tured data instead of PDF attach­ments in emails.
• Digital cali­bra­tion certifi­cates: cali­bra­tion data is exchanged across compa­nies through the AAS, a project with PTB, Siemens, Endress+Hauser and Boehringer Ingel­heim among others.
• Cross-company transfer: the Cross-Enter­prise AAS Transfer answers prac­tical ques­tions such as who owns a shell after delivery and how IDs stay trace­able.
• Multi-vendor access: at the “Follow the Twin” chal­lenge at Hannover Messe 2024, visi­tors retrieved product data from several vendors across two inde­pen­dent AAS repos­i­to­ries.

Further appli­ca­tions include predic­tive main­te­nance, energy moni­toring, the commis­sioning of produc­tion lines and the exchange of simu­la­tion models. Because all of them use the same struc­ture, a company that starts with one use case can reuse its asset admin­is­tra­tion shells for the next, which turns digi­tal­iza­tion from a series of projects into a shared foun­da­tion.

Stan­dards and orga­ni­za­tions behind the AAS

Several bodies shape the asset admin­is­tra­tion shell and its stan­dard­iza­tion. Plat­tform Indus­trie 4.0 devel­oped the orig­inal concept. The IDTA, founded in 2020, now main­tains the spec­i­fi­ca­tions and the submodel templates and publishes them free of charge. The IEC turned the struc­ture into the inter­na­tional stan­dard IEC 63278. ECLASS and the IEC 61360 dictio­naries provide the seman­tics. Data space initia­tives such as Factory‑X and Catena‑X use it as their common format for digital twins, which links it to the wider topic of data spaces.

The docu­ment set covers the meta­model (Part 1), the API (Part 2), data spec­i­fi­ca­tions (Part 3), secu­rity with access control and authen­ti­ca­tion (Part 4) and the AASX package format (Part 5). Open-source imple­men­ta­tions such as Eclipse BaSyx, Eclipse AAS4J and the AASX Package Explorer let devel­opers start without license costs.

How to get started with the AAS

1. Pick one use case with a clear owner, for example digital name­plates for goods-in or tech­nical data for engi­neering. A narrow start beats a company-wide program.
2. Reuse submodel templates from the IDTA instead of designing your own struc­ture. Start with Digital Name­plate and Tech­nical Data.
3. Create a first AASX file with the AASX Package Explorer and vali­date it.
4. Move to a server such as Eclipse BaSyx once systems need live access through the API.
5. Test with part­ners. The value of the AAS appears when a second company reads your data without a custom inter­face. OI4 hackathons and projects exist for exactly this step.

Digital twin tech­nology does not have to start big. For a non-tech­nical intro­duc­tion, read AAS for 5 year olds. The OI4 down­loads include white papers on AAS basics, common misun­der­stand­ings, the AAS tool land­scape and AAS secu­rity.

Common misun­der­stand­ings about the AAS

• “The AAS is a commu­ni­ca­tion protocol.” It is a data model with an API. Trans­port happens via HTTP, OPC UA, MQTT or files.
• “It only works for new machines.” Admin­is­tra­tion shells can be created for existing equip­ment, too. The onboarding project above regis­ters devices without a shell in the repos­i­tory.
• “It is a plat­form you have to buy.” The spec­i­fi­ca­tions are open and free. Plat­forms are optional imple­men­ta­tions.
• “It replaces OPC UA.” Both comple­ment each other, as described above.

Frequently asked ques­tions