The administration shell as a standardized “digital twin”

Interoperability is a pillar of the mission statement for Industry 4.0 in addition to sovereignty and sustainability, and it is precisely in this field of action that standards and integration are at stake. Especially for our customers in mechanical and plant engineering, integration is a major topic and thus also the administrative shell (VwS, AAS: Asset Administration Shell), as it helps to facilitate this integration through standards and to make it fit for the future.

In an interview, Christian Heinrich from XITASO explains what exactly the administrative shell is, and in which use cases it can provide concrete support. A project with our customer Wittenstein SE provides insights into practice.

Explained in two sentences: What is this administration shell?

Put simply, the administration shell is a “data connector”, i.e., the one (intersection) point through which I can find or store all data or information about a specific asset/device/component. One can also go further and say that the administration shell is an (some would say “THE”) implementation of the “digital twin” and thus also represents the basis for Industry 4.0.

Do you have a concrete example of the administration shell?

Sure! For example, together with our customer Wittenstein SE, we provided data on components from the SAP system via administration shells in the Wittenstein Service Portal.

For this purpose, the SAP database is synchronized into an “SAP Drop” in the cloud and the administration shell repository is populated via an Extract Transform Load (ETL) process. For this ETL process, we have a mapping of SAP characteristics to the IRDI number from the ECLASS catalog, so that the characteristics are provided with the correct semantics and can be clearly understood by everyone. A REST API now provides the information for the components, i.e., for each individual instance, in the standardized administration shell format. This means, for example, that you can ask for the production date of the gearbox, which is right in front of me here, via this REST API.

In this example, the metaphor “data connector” is also easily tangible, because the information about a component can now be used by different systems via this REST API. As a result, the integrability of these components has improved sustainably.

What does such an administration shell look like?

The administration shell is divided into sub-models with each sub-model covering an aspect or a use case. Ultimately, sub-models are groups of characteristics. You can also retrieve some administration shells online here and quickly get your own idea of an administration shell.

Here you can see a section of the administration shell list. An administration shell (AAS) always has the sub-models’ “Nameplate”, “Document” and “Identification”, most have even more.

Within a sub-model, you will find the characteristics (Prop, Properties) that can also be managed in lists (Coll, Collections). A characteristic consists of a value (Value), the value type (Value Type), and a Semantic ID to clearly describe what this characteristic means. The highlighted example in the screenshot is the characteristic “ManufacturerName” in the sub-model “Nameplate” of the administration shell “Festo_3S7PM0CP4BD”. This characteristic has the value “Festo AG & Co. KG” (on the right in the screenshot) of type “string”. The SemanticID is here as “IRDI” with the number “0173-1#02-AAO677#002”. This IRDI (International Registration Data Identifier) is a unique identifier of the characteristic and defined in the ECLASS catalog so that everyone knows exactly what that characteristic means.

An administration shell can be provided not only as a REST API, but also as an aasx file. This aasx file is in Open XML format, i.e. simply replace the extension .aasx with .zip and unpack it and you can see the individual XML or JSON files that describe the asset. Images and PDFs can also be stored there. Some administration shells in aasx file format for download can be found here.

You can also open these aasx files with the Aasx Package Explorer and then clearly see the sub-models and data of the administration shell. The Aasx Package Explorer is available open source on github and is constantly being further developed. Meanwhile, it can even provide a REST API locally and also visualize live data. It’s definitely worth taking a look here.

Which sub-models or use cases does the administration shell support?

Some sub-models are already standardized, but everyone is free to create a new sub-model for their use case and share it with their integration partner. The standard sub-models are maintained and published by the “Standardization Council Industry 4.0” supported by the VDE DKE. In addition, the “InterOpera” project aims to develop 50 concrete, practicable and interoperable sub-models. A regular look at this page is certainly worthwhile.

An important sub-model is, for example, “identification“, with the help of which the specific asset can be identified. It contains, for example, the name of the manufacturer, the serial number and also the unique identifier of the asset (i.e., the specific instance).

Another partial model is the “type plate“. A partial model that provides the basis for Industry 4.0, because it allows global access to device information, which can also be unlimited in size and extensive. In addition, this information can also be dynamically adjusted and displayed on any display, making paper documentation superfluous. Especially with small or inexpensive components, the relatively high proportion of costs for printing and shipping is eliminated.

On this website of the i4.0 platform, some examples of administration shells with partial models “type plate”, “identification” or “documentation” are presented and give a good impression of what information is transported here.

Are further use cases conceivable?

Sure! It is open to everyone to define their own sub-model and adapt it for their individual application. How to create a sub-model is well described in the publication “Administration Shell in Practice / How do I define sub-models, exemplary sub-models, and interaction between administration shells?”

Since all elements within a sub-model are semantically described (because this is required by the VwS specification), the newly created sub-models can be understood by everyone.

For example, I can define the sub-model “drilling” and give it the assets that can drill and describe there which materials, what minimum and maximum depth and diameter the boreholes can have. This makes it possible to automatically find the correct asset for a specific order. And not only for me in my company, but also across companies, because everyone else understands what I have described in the sub-model “drilling”.

In addition, expected behavior of the asset can also be mapped under different conditions in a sub-model. This knowledge of the behavior can then be used, for example, for simulations in conjunction with other components in order to identify any problems before the actual commissioning. In addition, maintenance or repairs can be initiated during operation if the actual behavior no longer corresponds to the expected behavior.

Is there an open source community?

Yes! In September 2020, the “Industrial Digital Twin Association” was founded by VDMA, ZVEI together with bitkom and 20 companies to provide a contact point for developers and designers.

Where can I find more information about an easy start with the administration shell?

  • A good place to go is Home of AAS, which is the website for the github repository mentioned above.
  • As part of the bitkom event “Administration Shell for Software Providers” on 30.3.2021, I presented a practical report together with Bernd Vojanec from Wittenstein SE.  Click here</span for a recording of the lecture.
  • A whole series of screencasts can be found here.

Other interesting information

Here is a visualization by the “Asset Administration Shell Viewer”, which we built on the Siemens Mindsphere platform as part of the Wittenstein project mentioned at the beginning to visualize an administration shell.

The administration shell shown here offers a sub-model that holds the history of teach-in runs, i.e., Wittenstein’s Smart Services write to the administration shell via the REST API and thus make this information available to other services.

A detailed description of the project can be found here.

Author & contact person

Christian Heinreich