The Asset Administration Shell (AAS) is an emerging concept in connection with the digital twin data management. It is a virtual representation of a physical or logical unit, such as a machine or a product. The AAS enables relevant information about this unit to be collected, processed and used to ensure efficient and intelligent production. The architectural standardization of the AAS enables communication between digital systems and is therefore the basis for Cyber Physical Systems (CPS). You can find out more about the need for digital twins in the industry here: ZEISS Digital Innovation Blog – The digital twin as a pillar of Industry 4.0

The following article focuses on the actual implementation of an example. In one scenario, we will use a reference implementation from the Fraunhofer Institute for Experimental Software Engineering IESE (BaSyx implementation of AAS v3) to establish an information exchange between two participating partners. For the sake of simplicity, both parties are based within one company and share the infrastructure.

Note: This application is also suitable for cross-company distribution. The respective security aspects are not part of this scenario.

Scenario

Factory A is a manufacturer of measuring head accessories and produces pushbuttons, among other products.

Factory B manufactures measuring heads and would like to install pushbuttons from factory A on its measuring head.

In addition to the physical forwarding of the pushbutton, information must also be exchanged. The sales department of factory A provides contact information so that the technical purchasing department of factory B can access and negotiate prices. Moreover, factory A must also provide documentation, etc.

For this exchange of information:

• Contact details and
• documentation

the AAS concept is to be used.

Infrastructure

In our scenario, we want to use type 2 of the Asset Administration Shell. Here, the AAS is provided on servers and there is no exchange of AASX files, but rather communication between the different services via REST interfaces.

In our scenario, the different services run within a Kubernetes cluster in Docker containers.

Services

To provide the AAS, we use the BaSyx implementation (https://github.com/eclipse-basyx/basyx-java-server-sdk). To be specific, we use the following components:

• AAS repository,
• submodel repository,
• ConceptDescription repository,
• discovery service,
• AAS registry as well as
• a Submodel Registry.

AAS repository, submodel repository and ConceptDescription repository are provided within one container – the AAS environment.

Technical implementation

The communication is only done via API calls to the corresponding REST interfaces of the services.

For this, we will use simple Python scripts to represent a communication in which the manufacturing factory B wants to receive information about a product (here: a pushbutton for a sensor) from the component factory A.

Procedure

Factory B only knows the asset ID of one pushbutton, but knows nothing else about this component.

1. Factory B uses the Asset ID to request the discovery service in order to obtain an AAS ID.
2. This AAS ID is used for requesting the central AAS registry, which provides the AAS repository endpoint of factory A.
3. Via this endpoint and the AAS ID, factory B receives the complete Asset Administration Shell including the relevant submodel IDs.
4. With these submodel IDs (e.g., for contact details and documentation), factory B requests the submodel registry of A and receives the submodel repository endpoints.
5. Factory B requests the submodel endpoints and receives the complete submodel data. This data includes the desired contact information for the buyer and complete documentation for the pushbutton asset.

The process is illustrated in detail below using UML sequence diagrams.

UML sequence: Creation of AAS registration in component factory A

Factory A is responsible for registering its own component.

Figure 1: UML sequence: Creation of the AAS registration in component factory A

 

UML sequence: Requesting the component data

Factory B requires data about the component and requests it from the AAS infrastructure. Here, factory B may only have access to the asset ID of the component, in our case that of the pushbutton.

Figure 2: UML sequence: Requesting the component data

Implementation

For the process described above to work, the services mentioned must be made available. Secondly, shells and submodels must be created and also stored in the registries.

Service deployment

Deployment takes place via Docker containers that run within a Kubernetes cluster. For this, each BaSyx image receives a Kubernetes deployment which starts the corresponding pods via Kubernetes replica sets.
By means of port forwarding, for example, the corresponding ports are made accessible by the host. This is necessary to address the APIs according to the example Python scripts.

A relatively simple Kubernetes deployment configuration looks like this. There are four deployments, each with a replica set.

Figure 3: Kubernetes deployment configuration

Creating the AAS from factory A

Factory A would like to provide the contact details for its pushbutton component, for example.

For this, submodels are created in the AAS repository (here: in the AAS environment) and registered in the submodel registry.

Subsequently, the Asset Administration Shell is created in the AAS repository and registered in the AAS registry.

The shell reference is then added to the AAS repository.

This completes the registration process from the component factory.

Contact details requests from factory B

Factory B would like to receive the contact details and requests the various AAS services according to the workflow described above. Ultimately, the submodel data set containing the required values is obtained and can then be made available within a user interface, for example.

Conclusion

The Type 2 Asset Administration Shell is a distributed system that is based on the corresponding repositories, registries and the discovery service. In our example, we have only used a simple submodel template for contact data. However, there are far more templates available for many applications.

Communication between the services for the provision and retrieval of data is relatively straightforward, although aspects such as security were not a focus in this scenario.

The example implementation described in this article gives an idea of the immense potential of the AAS concept and encourages users to start concrete implementations.

This post was written by:

This post was written by: