---
# System prepended metadata

title: Untitled

---

<img src="https://i.imgur.com/egufNfr.png" width="100%">





---


<img src="https://i.imgur.com/E5gbZUh.png"
 width="100%">



*LMtec Digital Solutions* is a global company with headquarters in Germany, the US and other countries, that provides business consulting, software and product lifecycle management solutions as well as information technology services in the manufacturing industry. Their mission is to help companies introduce new products and digital services by enabling process and technology innovation. *LMTec Digital Solutions* helps organizations address industry trends and develops new products with regulatory requirements in mind while improving performance. As a *Siemens Digital Industries* software partner, they help customers evaluate, acquire and implement the *Siemens* product platform. The *Digital Twin of the Cocktail Bar Mixing Unit* was under the supervision of Carolin Pankrath *(PLM Consultant & Software Developer at LMtec Digital Solutions*) and Alexander Barduhn *(Managing Partner, Senior PLM Consultant & Team Lead at LMTec Digital Solutions)*.



---


## *Table of contents*

[TOC]
   
   
   
##### *Project members*
<img src="https://i.imgur.com/7NarbC7.png" width="100%">

---




* **Nour-El-Houda Khelifi** *(Product Owner, HTW Berlin)*
* **Julian Hemsing** (*Scrum Master, HTW Berlin)*
* **Gabrielle Walker** *(Developer Lead, UTS Sydney)*
* **Aya Khaleel** *(Developer, HTW Berlin)*
* **Poojaben Darji** *(Developer, UTS Sydney)*


#####  *Problem space*
<img src="https://i.imgur.com/Z6HdnA0.png" width="100%">

---



A common problem in the industry is the lack of open/non-proprietary standards for exchanging data and/or linking different systems. Based on the fact that each company has its own proprietary software for processing data, this often leads to problems exchanging data between systems within the company or even across companies. The urge to keep the same data in different systems then leads to data redundancy, error-proneness, and ultimately a lack of relevant data due to missing links between systems.




##### *Project idea & vision*
<img src="https://i.imgur.com/AtXCv8E.png" width="100%">

---



Interdependent _Asset Administration Shell_ should be implemented to deliver data from distributed systems in real time throughout the product lifecycle in distributed environments (topic: digital twin/asset administration shell/interoperability).
* Understand the various use cases of _Asset Administration Shells_ and how asset data can be structured
* Develop an interface to retrieve original asset data in real time from authoring systems (e.g., _Teamcenter_) (using _AAS_ as an asset framework)
* Evaluating the benefits of using interdependent and standardized _asset administration shells_ as asset scaffolding in distributed environments

:::spoiler
Establishing a system-independent, non-proprietary, open standard for providing, exchanging, and linking asset data from disparate systems can be realized by using asset scaffolds and their dependencies within the _Asset Administration Shell_. To avoid data redundancy, such scaffolds can contain meta-information about the location of asset master data. Depending on the use case, it can be defined whose metadata information can also be contained in the *AAS*, detailed purpose-related asset data can be retrieved in real-time from distributed systems (_PLM/ALM_, _ERP_, _SAP_ and more) within LANs or even WANs.


The advantage of creating such standardized system model and asset frameworks instead of storing data for all possible use cases in the _Asset Administration Shell_ itself, is to avoid data redundancy. Dangerous loss of information about asset relationships and thus connections between assets can be avoided by describing the asset and its dependencies on other assets in a meta-description contained in the *AAS* that contains the asset framework.
_Asset Administration Shells_ can be addressed via URIs and thus queried within a network, they can be established as an independent standard, are free for sharing, and can also be transformed into non-proprietary formats such as XML, JSON, etc. to be further processed by any conceivable application.
:::



##### *Technical framework*
<img src="https://i.imgur.com/2fvpDqe.png" width="100%">

---



***Developement environment***
* _Mendix_ (lowcode platform)
* _Teamcenter_ (PLM)
* _Google APIs_ (Rest API access)
* _Windows Server_ & _Google Sheets_ (File System)
* _Asset Administration Shell_ / *AAS* package Explorer



##### *Project target*
<img src="https://i.imgur.com/VkezpJV.png" width="100%">

---


The project is successful when the framework of a demonstrator (e.g., wire harness list or simpler) within _Asset Administration Shells_ is based on the basis of an _AAS_ repository that contains and provides data for incoming contains and provides data for incoming requests. 
In summary, a unified data retrieval system that connects all data management sources using the Asset Administration Shell should be implemented.
:::spoiler 

Our target is to use *AAS* properties to build request URLS to further data sources. The *AAS* should hold asset relation information as well as asset meta information from authoring systems. The schema of the _AAS_ structure containing an asset harness with all associated information is designed.
Micro services are able to load data from authoring systems based on the scaffolding information used in the authoring systems with asset & property IDs.

A microservice to deliver _Teamcenter_ data must be able to deliver asset data for the demonstrator on demand in real time to a third party app (could be a console app for demonstration purposes). Whenever a new microservice comes into play, it should be easily introduced into a data agent that controls the routing of requests to the appropriate authoring system and distributes the data from the authoring system back to the recipient.
:::





##### *Solution*


<img src="https://i.imgur.com/wKJz9c3.png" width="100%">


---
There are 4 key functionalities that are implemented in order to complete the proposed system. These include:

**1.** ***Identification of AAS*** sub-models and creation of AAS scaffolds using the AAS package explorer

**2.** ***Integration of the AAS*** into the system via a generic data handler

**3.** ***Development of digital cocktail bar*** functionalities using Mendix development platform, including:
* **a.** ***Customer cocktail ordering***
    *i.* View cocktail menu - filter by name, ingredients, category
*ii.* Add cocktail to order
*iv.* Remove cocktail from order
*vi.* Confirm Order

* **b.** ***Bartender cocktail mixing and order fulfillment***
    *i.* View cocktail menu 
*ii.* View cocktail details *(name, ingredients, price, recipe, required utensils, instructional videos)* 
*iii.* View current/ongoing orders
*iv.* Complete cocktail order


**4.** ***User role authentication*** system for managing access to cocktail information

                                        

<img src="https://i.imgur.com/1jA8e7u.png" width="100%">


---


##### ***Architecture of the Cocktail Mixing Bar Unit***
To demonstrate how the *AAS* could be integrated into the system, the user role authentication displays a proposed system architecture diagram that provides an abstract outline of the system components relationships, constraints and boundaries.
![](https://i.imgur.com/IpN8QsG.png)

In this diagram, the user *(bartender and customers)* interacts with the application via the user interface *(UI)*. As each page of the application loads, the *UI* will request the required data from the data handler. Depending on whether the *UI* requested *Asset* or Entity data, the data handler will route the request to the *AAS* server or directly to the *Mendix* application entity database via an API. The *AAS* server holds each asset administration scaffold containing each asset metadata.

If the *AAS* can successfully fetch the asset metadata based on the *UI* request (*e.g*., if the *UI* is requesting cocktail information that is stored in the *AAS*), the system will then direct the request to the required data mapper for that asset data *e.g.*, *Teamcenter* or *Google Drive*.

Such a microflow is shown in the following figure consisting of a request where all cocktails are being returned from teamcenter in a list. <img src="https://i.imgur.com/NCiKmYB.png" width="80%">


Since the *AAS* metadata contains the authoring credentials for each data source, the asset information is being retrieved and then returned directly from the source to the data handler. If the request is after simple Entity data (*e.g.*, a cocktail order details), the request will remain within the *Mendix* application. Once the asset data passes back through the data handler, it is then directed back to the *UI* and will be displayed to the users.

                              

<img src="https://i.imgur.com/f0Wlkub.png" width="100%">

---


##### ***User Interfaces of the final product of the Cocktail Bar Mixing Unit***

1. ***Homepage***
This is the homepage where users *(both customers and bartenders)* can access the app. Only the bartender is required to log in through the `Sign In Bartender!` button.

     <img src="https://i.imgur.com/H2RRNsr.jpg" width="90%">




2. ***Start Ordering Process***
The button `click here to start ordering`  prompts customers to enter their table number to start the ordering process. After clicking on the button `Enter` customers are directed to the following overview to finally place their orders.
<img src="https://i.imgur.com/cEiUw7F.jpg" width="90%">

 
 3. ***Customer Overview & Ordering Cocktails***
In this user interface, customers have the possibility to view their table number from which the orders originate, which orders are still pending and which have already been accepted and/or mixed by the bartender and therefore ready to pick up by the customer at the bar. In addition, cocktails can be filtered by name, ingredients, and flavor categories. 
<img src="https://i.imgur.com/wTsKljY.jpg" width="90%">









##### *Conclusion*
<img src="https://i.imgur.com/8b0qmMM.png" width="100%">



    

---

Overall, the project carried out shows that the development of a *Data Handler* for an Asset Administration Shell *(AAS)* as a *Digital Twin* is a promising way to improve the monitoring, control and optimization of plants in industrial automation. The *Data Handler* enables fast and efficient processing of large amounts of data collected from the plant and provides a central platform for integrating and linking different data sources.

By using a *Digital Twin* as a virtual representation of the real plant, decisions can be made based on real-time data and processes can be optimized, leading to increased efficiency and productivity. Therefore we are convinced that the use of a *Data Handler* in combination with an *AAS* and a *Digital Twin* can make a significant contribution to the realization of *Industry 4.0* and the Internet of Things *(IoT)*.



##### *Future improvements*

<img src="https://i.imgur.com/rOQyzMl.png" width="100%">



---


One possible improvement for our digital twin is the addition of semantic technologies to enable a uniform description of the data and thus facilitate interoperability between different *AAS*.
Another key player could be the integration of machine learning algorithms to predict plant conditions and optimize production processes. Even the use of blockchain technology for secure and decentralized storage of *AAS* data to prevent manipulation or data loss may prove to be a promising option for the future.


An additional important aspect for the future of *AAS* is the integration of human-machine interfaces *(HMI)* to make it easier for the user to interact with the system. Here, for example, virtual or augmented reality systems could be used to facilitate the operation of equipment or to support the performance of maintenance tasks.

Overall, the further development of *AAS* offers enormous potential for industrial automation and the realization of *Industry 4.0*.
By integrating new technologies and improving interoperability and operability, *AAS* can help to further increase the efficiency, flexibility and cost-effectiveness of production processes.












##### *Glossary*




<img src="https://i.imgur.com/DVpMUQE.png" width="100%">


---




* **Asset**
Anything of value to a company e.g. parts, components, requirements, documents, processes, etc.

* **Asset Administration Shell *(AAS)***
An Asset Administration Shell *(AAS)* is a digital twin that contains information about a physical object or asset in a standardized format to improve communication and interoperability between different systems and organizations.



* **Digital Twin**
A digital copy of an asset with the objective of data exchange between physical and digital world.

* **Industry 4.0**
Ocurred through the rapid networking of industry machines and processes assisted by advances in information and communication technology. It has lead to increased automation, predictive maintenance, self-optimazation of process improvements, new levels of efficiences and responsiveness to customers through the use of technologies such as IoT, AI and Big Data.

* **Data handler**
A data handler is a software or hardware component that stores, processes, or transmits data.


* **Internet of Things (IoT)**
IoT *(Internet of Things)* refers to the networking of physical devices and objects using sensors and Internet connectivity to collect, transmit and process data.


---


###### ©2023, Nour-El-Houda Khelifi, Gabrielle Walker, Julian Hemsing, Poojaben Darji, Aya Khaleel