The Asset Administration Shell in the Industry 4.0
We are getting deeper into Industry 4.0 with this new post, with the objective of presenting a concept in the Industry 4.0 environment that is not very common to talk about because it was, until a few months ago. The reason is that it was a theoretical idea without much practical implementation, often limited to R&D developments. The topic is the Asset Administration Shell (or AAS).
We assume that Industry 4.0 solutions require interoperability among all their actors so that they can communicate among themselves without any kind of problem. The AAS has been created with the aim of being the basis for interoperability within and between companies, based on an open standard.
It could be defined as a software wrapper or a digital layer that is superimposed on an object in a way that we can interact or communicate with it, being the set of both elements what is the so called I4.0 Component or also Asset 4.0.
The object could be anything, depending on how we define the granularity of our system, and such an object can have internal AAS. Thus, our element could be a sensor, a PLC, a machine or even a factory, made up of AAS. However, my opinion is that the objective is to define devices or parts of a machine, not to define factories or entire organisations.
Finally, what we know as Industry 4.0, defines an Asset as any element that requires a connection to communicate within or with an I4.0 solution, so although the idea is that this object is something physical, it could also be a digital asset, such as blueprints, documents or electrical diagrams.
Origin
The origin comes from one of the theoretical models that define the architecture of the Industry 4.0 concept. We are referring to RAMI 4.0 (Reference Architecture Industry 4.0). As a reference architecture, it seeks a theoretical framework in which all participants in an Industry 4.0 environment share the same meaning for each element, as well as their specific function and the communications that exist between them. RAMI 4.0 has a three-dimensional structure as shown in the following image.
The X-axis represents the life cycle of the product from manufacturing to disposal or recycling. Here lies two of the concepts that are later transferred to AAS, and which could be similar to what we call Object Oriented Programming (OOP) in programming: Type and Instance. Type is our product in the early stages of the cycle (design, simulation…), it is not real, that is, the class without instantiation. Once we start manufacturing, they become Instances, i.e., the final product or real part, or we could also call it the object in OOP.
The vertical axis represents the interoperability layers, describing the properties of an asset or a combination of them, with a focus more related to the IT world of I4.0.
The last dimension, the Y axis represented in the figure, represents the hierarchy levels, being very similar to the classic pyramidal representation of automation where different elements that are present within a factory are shown: plant level devices, SCADAs, PLCs… reaching the “Connected World” level, i.e. what would be the IoT or the connection of the factory to the Internet.
Definition of the Asset Administration Shell
A good definition of the Asset Administration Shell or component 4.0 would be an element that has processing and communication capabilities. It would be the first step towards having a digital twin of each asset with its associated digital wrapper and with all the information stored in it available, also taking into account the privacy, security and confidentiality of the stored information.
As I briefly mentioned in the introduction, it is a kind of digital wrapper that is superimposed on an element so that it can communicate within the network or environment in which it is located , exchanging data and information. As I said, it does not have to be a tangible or physical object, as it could be a document such as plans or specifications. With the following diagram we will better understand the idea, applied to a widely known device such as a Raspberry.
The Asset is the object that is owned by the organisation, while the AAS is the digital representation of the Asset, identifying it univocally and with different approaches to the information that is stored in the sub-models, which we will discuss later.
To better understand the idea and where AAS fits in Industry 4.0, we can look again to the RAMI 4.0 figure, and we will see that the lowest layer on the vertical axis is called Asset, while in the next one we have integration. The AAS would be integrated in these layers, with the physical element being in the lowest layer, while the integration one would be the wrapper that would allow us to communicate with it.
Official documentation
There are 3 documents currently under development, the first two of them have already been published and are collectively known as the “Details of the Asset Administration Shell”. As an example, the document “Details of AAS – Part 1” describes all the features of the AAS, as well as its internal structure and also defines the information stored within it. It would be like our main source for all the details of the AAS.:
- Part 1. Information on the AAS template for the exchange of information (or the file itself) between value chain partners. It is now in version 3.0RC01, with publication date 23/11/2020. Here is the link. This document defines the basis of the AAS, definitions of each concept, its internal structure… and very important, how to map and translate the structure to other formats.
- Part 2. Interoperability in runtime. This document focuses on access to the information provided by the AAS by the enterprise or users through the use of APIs. The version is 1.0 RC01, with publication date 23/11/2020. Here is the link.
Part 3. Infrastructure to contain and interconnect multiple AAS. This work is currently ongoing.
Each of these points correspond to different types of AAS interaction. The first would be a Type 1 or Passive interaction, the second point would be a Type 2 or Reactive interaction, while the third point would be, you guessed it, a Type 3 or Proactive interaction.
Characteristics
The Asset Administration Shell describes a device, which may or may not be intelligent, so that it can integrate, operate and communicate with various systems without requiring major changes or modifications. In other words, it is designed to be compatible with as many systems as possible, regardless of the asset technology or manufacturer, while allowing access to all its properties and functions.
An asset may have several AASs, depending on its lifecycle environment. For example, a manufacturer may have its own AAS for the device that they are designing and have another AAS to send to its customers. Then, the user of the device may use another AAS of the same physical element, but focused on production, with different metrics. However, they would all be compatible with each other and in the case of using the data generated by the production line usage, it would be easy to import it into the manufacturer’s AAS for troubleshooting, improvement or upgrading.
The most important feature and possibly the main objective is that an Asset Administration Shell allows interoperability between companies. It would allow for a standard and open format, enabling horizontal communication, between the product manufacturer, the supplier, the integrator and the end user.
For example, the manufacturer could have access to all the data generated during the lifetime of each of its parts, allowing for continuous improvement and a predictive maintenance approach.
It also takes into account security aspects, defining access permissions to stored information based on the ABAC (Attributes Based Access Control) concept.
Identifiers
Each AAS has a unique identifier, as do the assets themselves, the sub-models or the internal properties of the AAS. There are two global standards for identification and a customized one:
IRDI (International Registration Data Identifier): it would be the identifier for properties and classifications. It is also used in the eCl@ss repositories.
IRI (Internationalized Resource Identifier): is the identifier for assets, AAS and other types of properties and classifications.
Customized: Another identifier is also allowed but for internal use within the AAS and used by the manufacturer itself. This is the GUID (Globally Unique Identifier).
Functionalities
All these features enable a number of functionalities as for example:
Use in flexible and reconfigurable manufacturing systems.
Quick integration, improving start-up time.
Easy updating of production lines.
Persistent and updatable information from manufacturers to integrators and end users.
Multilanguage, with all data stored in different languages.
On the other hand, if we define the digital twin as a digital representation of an object with data that represents the main and secondary characteristics of an asset, as well as its behaviour and how it relates to the environment through functions, we can also say that the AAS could be used as the implementation of a standardised digital twin within Industry 4.0.
Internal Structure
The internal architecture of an AAS is based on sub-models, which stores the information of the asset, while integrating different aspects of the 4.0 component. These sub-models can also include capabilities or functionalities of the asset itself, such as cooling, movement or cutting. These sub-models are intended to use standards such as IEC, ISO or eCl@ss in order to have a coherent definition with all the actors in the environment.
On the other hand, each of the sub-models has to be perfectly described, as well as having a unique identifier.
There are a number of standardised sub-models such as technical data or component identification, but it is also possible to add new sub-models as needed to integrate the asset within a company, organisation or value chain. Therefore, the sub-models contain different elements that provide the information related to the sub-model.
We can understand this better with the example shown in the image. In addition to the sub-models, new definitions could be added that are of specific interest to the company: stored files, folder structure…
On the other hand, the entire description of the Asset Administration Shell is defined in UML (Unified Modeling Language). As it is independent of the technology used, it allows the AAS to be mapped or “translated” to other standards such as OPC-UA, AutomationML (which I will talk about in a separate post), RDF (Resource Description Framework) or formats such as XML or JSON.
There is also another element which is events, a very useful mechanism that can be bidirectional. Some examples that can be implemented would be the generation of logs, security alarms, device shutdowns, firmware updates…
Creation and programming
Perhaps it is when it comes to deploy the AAS into the real world when more doubts arise: how to create an AAS? how to implement it in a practical case? what kind of software or hardware do I have to use? Basically, there are two important questions: how do I create an AAS and how can we access this information, let’s say, online.
Creation of an Asset Administration Shell: AASx Explorer Package
For generating our AAS, we could use the AASX Package Explorer, which is a viewer and editor developed in C# and that you have at your disposal in the following Github page: https://github.com/admin-shell-io/aasx-package-explorer
The bad thing about the tool is that it is not very intuitive and the concepts are not easy to understand, although it will show you the existing errors or several recommendations if you do not fill in some of the necessary information.
For that reason, it is advisable to watch a series of video tutorials where they explain step by step how to work with the software, as well as I4.0 concepts, Security or basic AAS topics. Here is the link: http://admin-shell-io.com/screencasts/. The information is in English and German.
If we download the binaries and run the exe, we find this screen.
To be able to edit and create an AAS, we have to go to menu > Workspace > Edit. In this way we can start creating an AAS from scratch. In the following image we can see how the system is informing us of the lack of an AAS.
The best thing to have a clear idea of the structure of an AAS is to open a previously created AAS, so let’s open an example from the following page: http://www.admin-shell-io.com/samples/. There you will find quite a few examples that will give you a real idea of what an AAS would look like. Specifically we choose the file 22_Festo. This is a Festo valve in which you can find all the information about the element.
As we can see, we have several Submodels already created as Nameplate or Identification, with several “Submodel Element” inside of them, as properties or collections. Other documents such as pdf or CAD files can also be embedded in them.
I also leave you a link where you can download an example of an AAS for a Raspberry 3B+: https://github.com/i40-Tools/RAMIOntology/tree/master/AssetAdministrationShell_examples
File format of AASx
The file we have opened has the extension *.aasx, which is a standard format defined by the previously mentioned documents in order to carry out the data exchange. It is based on the ISO/IEC 29500-2:2012 standard. This exchange format is used for secure transmission of AAS.
It is actually a .zip format, which you can open with the program 7Zip, for example, and which allows you to see the structure of the file. In the case of integrated files such as plans or 3D files, they are stored in the zip file. We see the same file visualised with 7Zip.
Accesing information
On the other hand, how can I access the information? This format is really an archive, it is not something that is accessible externally or in online mode. It allows us to exchange AAS and information, but not to access it.
In order to achieve this, basically what you have to do is to make all this information available through a specific communication protocol, for example by creating a server and connecting to it. One idea would be to map all the information to OPC-UA, generate a server and connect externally to access the data.
A clear example is an implementation of an AASX server that makes existing information accessible in AASX packages using REST, OPC-UA or MQTT. In this github development you have a possibility of knowing how to do it: https://github.com/admin-shell-io/aasx-server. They have an example server at https://admin-shell-io.com:5001/, where if we click on the element shown in the following figure, we can see that it is the same as the one I have previously chosen as an example of the AASX explorer.
Other solutions and implementations
In addition to the AASX Package Explorer, which is arguably the “official” implementation, there are several implementations being developed in open source. I mention a few of them:
SAP i40-aas: https://github.com/SAP/i40-aas
In addition, there are many developments from companies and institutions that work with different solutions, as there is no universal one at the moment. We mention a few, but there are many more:
For example, in the paper “Connecting PLCs with their Asset AdministrationShell for Automatic Device Configuration” (link) they use BaseX (XML-based DB) and XQuery as a means to access the DB and load the AAS information that was previously mapped to AutomationML format.
In “Toward the Plug-and-Produce Capability for Industry 4.0”, (link), where Plug-and-Play with the use of AAS is explored, the creation of an OPC-UA server is used as an option.
In the case of “Implementing Industry 4.0 Asset Administrative Shells in Mini Factories”, (link), they use an IoT platform called ThingWorx and a Kepware software to obtain the connection between the real AAS and the ThingWorx platform.
As we can see, there are many possibilities and choosing one of them will depend on the characteristics and the specific environment in which you want to develop and implement an AAS-based system.
APIs definition in Part 2
The publication of the document “Details of the AAS – Part 2” mentioned above, which specifies and defines the interfaces as well as the APIs that enable access to the AAS and its sub-models, allows for greater standardisation of access to the AAS, as they are technologically neutral specifications, i.e. they tell you how they should be implemented, but not the technology to use. REST, MQTT or OPC-UA could be used, as well as the languages that the developers consider: C#, C++, Java, Python…
This document defines associated concepts for different levels: services, interfaces and APIS and operations. The following image, obtained directly from the document, shows the existing relationships.
Finally, there is a document that defines the AAS from a functional point of view, which you can find at https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/Functional-View.html. Anyway, there is a lot of information that already exists in Part 2. Moreover, as far as I have checked, at least at the moment, there are format errors and wrong figure references that are not correctly edited.
Asset Administration Shell examples
The concept of AAS has been a purely theoretical concept until the last year, although with implementations from an academic and research point of view. Therefore, there is no clear example of how to implement it in real life, and developments can be found that make use of databases, IoT platforms, OPC-UA servers, etc. All in the interest of finding the right way to put the idea into practice.
There are several European projects that are working on the basis of applying AAS in a series of prototypes. We can name the DIMOFAC: Digital Intelligent MOdular FACtories, https://dimofac.eu/ or the project CanvAAS: a common language for machines, https://eitmanufacturing.eu/canvaas-a-common-language-for-machines-entering-the-industry-4-0-era/.
In addition to European projects that are working on the practical implementation of the AAS concept, there are also other developments to exploit its potential. One of them transfers the typical machine nameplate with technical information or serial number to digital format by including all the information in an RFID tag where it is stored in AAS format: https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2020/November/Das_Digitale_Typenschild_-_ZVEI-Empfehlung/Digital_Nameplate.pdf.
Summarizing
To sum up, in this post we have only scratched the surface of the AAS concept, as well as what its application in industry can bring us. A few years ago it was just a theoretical idea with few practical applications, but nowadays it is proving its potential to obtain interoperability between different actors in the value chain, or even if it is applied within the same organisation, it would allow a quick connection of new devices or sending of standardised information between different departments.
If you have more questions about what AAS means or how to implement it, you do not hesitate to contact me or through the comments.