Product Lifecycle Management with the Asset Administration Shell
- Due to individual item naming in the systems, different interpretations of an artefact occur within companies.
- Different data formats are used for the same processes.
- Data should be accessible in such a way that it can also be used in areas for which it was not intended when it was created. This also includes independence from the location as well as from the company.
- The completeness of data cannot be guaranteed because it is often stored in different data repositories or even exists as documents in digital or paper form.
- Data access is hindered by data security requirements.
- Effort is needed to make the data of one PLM system accessible to other systems.
2. Related Background
2.1. PLM and Systems Engineering
2.2. Digital Twin
- A Digital Twin is a digital representation of an asset.
- A Digital Twin is located in several places simultaneously.
- A Digital Twin has multiple states.
- The Digital Twin has a context-specific state in a specific interaction situation.
- The information model for Digital Twins is infinitely large. It is called the real information model.
- The real information model can be finitely approximated for a specific application scenario, becoming a rational information model.
- The rational information model cannot be stored in a single place.
- The rational information model is never completely visible.
2.3. Asset Administration Shell (AAS)
2.4. Selected Data Models in PLM Processes
2.5. OSLC-Based Data Integration
3. Major Research Goals and Research Method
- OCP—Order-Controlled Production;
- AF—Adaptable Factory;
- SAL—Self-organizing Adaptive Logistics;
- VBS—Value-based Service;
- TAP—Transparency and Adaptability of Delivered Products;
- OSP—Operator Support in Production;
- SP2—Smart Product development for Smart Production;
- IPD—Innovative Product Development.
4. AAS-Based Engineering Process
- R1: The concept must be based on a standard in order to enable vendor-independent integration.
- R2: The underlying data model must provide comprehensive access to all data created for or by an asset in order to include data other than PLM/ALM data.
- R3: It must be possible to link a Polarion work item with a Teamcenter item and vice versa.
- R4: It must be possible to link a Teamcenter item with a Polarion document.
- R5: It must be possible to access the data of any attribute of a Polarion work item from the linked Teamcenter item and vice versa.
- R6: It must be possible to link more than one Polarion work item with one Teamcenter item in a single action.
- R7: When creating a traceability report in Polarion, all linked Teamcenter items must be included and vice versa.
- R8: The status of a Polarion work item can only be changed if the status of the linked Teamcenter item has a dedicated status.
4.2. Design and Implementation
4.3. Requirements Validation
5. AAS-Based Production Infrastructure
5.1. Requirements of the AAS-Based Production Infrastructure
- R10 (automatic creation of a Digital Twin): during the ordering process, an instance AAS must be created automatically based on a template.
- R11 (extend/change a Digital Twin): since a server hosts the AAS and communication protocols are implemented, the AAS must be changed and/or extended.
- R12 (versioning a Digital Twin): two different types of the same product must be created to demonstrate how to manage the production of different products.
- R13 (views on the AAS): to protect certain information, types and instances must be implemented. Instance information shows only selected information of that type.
- R14 (production based on AAS data): the manufacturing process must use instance and type data when producing an asset.
- R15 (automatic production data): the production process manufacturing information must be entered to create the “Digital Nameplate” (see Section 2.3).
5.2. Design and Implementation
- PLM/ALM data and tools
- To create the engineering data of the product (see Section 4).
- Ordering System
- To trigger the production of the asset by creating the instance(s).
- Production System
- System to produce the asset.
- Several AAS
- To store production, engineering, and operation data.
- AAS Registry
- Provides addresses for all AASs involved in the production.
5.3. Requirements Validation
- R10 (automatic creation of a Digital Twin): the AAS is automatically created by the ordering system when a customer orders a product.
- R11 (extend/change a Digital Twin): several AASs are integrated into the system. By exchanging data, they mutually modify their data models. Additional information can be added to a specific AAS at any time.
- R12 (versioning a Digital Twin): it is possible to order different configurations of the same product. For each of these configurations, the production infrastructure creates a separate AAS instance representing a specific product configuration.
- R13 (views on the AAS): Data access to the AAS type is restricted or can be controlled. This ensures the protection of sensitive product-type data.
- R14 (production based on AAS data): as shown in Figure 11, the production infrastructure significantly uses the concept of the AAS, which is a major goal in this work.
- R15 (automatic production data): The AAS of the assembly station enters production data into the AAS instance of the product. In this way, it enriches the information model delivered to the customer.
6. Overall Evaluation and Solution Success Factors
6.1. Evaluation of Industry 4.0 Application Scenarios
- Description : “This application scenario revolves around orders and describes how to dynamically organize the production resources required for the order”.
- Evaluation: The OCP is among the main aspects of the presented infrastructure in Section 5. In the AAS-based infrastructure, an AAS is created for each order. This “order AAS” communicates to the AAS of the production facilities to control the manufacturing process.
- Description : “In contrast to the OCP scenario–which focuses on the order–this application scenario focuses on a specific production resource and explains how it can be made adaptable and how this affects both the resource supplier and the system integrator.”
- Evaluation: The AF is another scenario that is fulfilled by the given infrastructure. Since the AAS uses Industry 4.0-based communication protocols to determine whether or not an assistance system is suitable for the production of the product, it is also possible to use this technology for other production operations to further increase AF capabilities.
- Description : “This application scenario is closely linked to the OCP application scenario, but focuses on the entire inter-and intra-logistics structure.”
- Evaluation: Even if the presented infrastructure does not contain a logistic node, it is highly adaptable for all kinds of self-driven processes. It is mentioned in Section 5 that the given infrastructure can be enlarged by adding more AASs into it. These AASs do not have to be production machinery but can also be representatives for materials or an automated delivery system to deliver them to the place where they are needed.
- Description : “This application scenario describes how service can be integrated into the value network by making specific product and/or process information available on an IT platform.”
- Evaluation: The AAS data model is based on the idea of collecting all information connected to its asset. This also includes real-time data from production machinery or from the product itself. This work previously discussed the problems around the proprietary interfaces and vendor-dependent solutions for the gathering of such information. Overcoming this interaction barrier could be the first step towards data collection that is accessible for every service available to a company or customer.
- Description : “In contrast to the VBS scenario—which focuses on the value network—this application scenario focuses on the product and how to use an IT platform to ensure that products are transparent and adaptable.”
- Evaluation: Using the AAS distinction between types and instances, it is possible to obtain a running digital representative in the hands of the customer, which still has a connection to the vendor. Since the customer owns the instance, the customer has full control over the data that are made accessible and those that are not. In this state, the instance can be used to deliver software updates and live data analysis to guide and help the customer to use the product to its full potential.
- Description : “This application scenario describes how new technologies can provide support for production operators.”
- Evaluation: The use of an assistance system in the given infrastructure (see Section 5) addresses the OSP scenario. The assistance system uses engineering data automatically to guide the operator in the assembly process in the most effective way.
- Description : “This application scenario describes collaborative product engineering, which is based on product requirements and is aimed at creating a seamless engineering process and enabling production and service to access the information they require.”
- Description : “This application scenario describes new methods and processes in product development and is focused on the early phases of product development.”
- Evaluation: The solution presented in this work does not address this application scenario. However, it does not prevent the realization of the IPD scenario.
6.2. Success Factors for AAS-Based Product Lifecycle Management
- Submodels for the AAS;
- AAS market success;
- Tool vendor support.
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
- Stark, J. Product Lifecycle Management. In 21st Century Paradigm for Product Realisation; Springer: Berlin/Heidelberg, Germany, 2015; Volume 1. [Google Scholar]
- Compare Product Lifecycle Management Software. Available online: https://www.capterra.com/product-lifecycle-management-software (accessed on 17 March 2021).
- Sääksvuori, A.; Immonen, A. Product Lifecycle Management, 3rd ed.; Springer: Berlin/Heidelberg, Germany, 2008. [Google Scholar]
- Lacheiner, H.; Ramler, R. Application Lifecycle Management as Infrastructure for Software Process Improvement and Evolution: Experience and Insights from Industry. In Proceedings of the 37th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Oulu, Finland, 30 August–2 September 2011; pp. 286–293. [Google Scholar]
- Shilovitsky, O. Can We Unify PLM and ALM Models? 2018. Available online: http://beyondplm.com/2018/09/21/can-unify-plm-alm-models (accessed on 17 March 2021).
- Warner, J. Who Needs PLM-ALM Integration? 2019. Available online: https://www.kovair.com/blog/who-needs-plm-alm-integration (accessed on 17 March 2021).
- Prendeville, K.; Pitcock, J. Maximizing the Return On Your Billion-Dollar R&D Investment: Unified ALM-PLM. 2013. Available online: https://www.accenture.com/in-en/insight-outlook-maximizing-roi-unified-application-lifecycle-management (accessed on 17 March 2021).
- Deuter, A.; Otte, A.; Ebert, M.; Possel-Dölken, F. Developing the Requirements of a PLM/ALM Integration. An Industrial Case Study. In Product Lifecycle Management. The Case Studies; Stark, J., Ed.; Springer: Berlin/Heidelberg, Germany, 2019; Volume 4, pp. 125–143. [Google Scholar]
- Open Services for Lifecycle Collaboration (OSLC). Available online: https://open-services.net (accessed on 17 March 2021).
- Polarion Integration for Windchill. Available online: https://extensions.polarion.com/extensions/339-polarion-integration-for-windchill (accessed on 17 March 2021).
- Trauer, J.; Schweigert-Recksiek, S.; Engel, C.; Spreitzer, K.; Zimmermann, M. What is a Digital Twin? Definitions and Insights from an industrial case study in technical product development. In Proceedings of the DESIGN Conference, Online, 26–29 October 2020; pp. 757–766. [Google Scholar]
- Boschert, S.; Rosen, R. Digital Twin the Simulation Aspect. In Challenges and Solutions for Mechatronic Systems and their Designers; Springer: Berlin/Heidelberg, Germany, 2016. [Google Scholar]
- Walden, D.D.; Roedler, G.J.; Forsberg, K.; Hamelin, R.D.; Shortell, T.M. (Eds.) Systems Engineering Handbook: A Guide For System Life Cycle Processes and Activities, 4th ed.; Wiley: Hoboken, NJ, USA, 2015. [Google Scholar]
- Deuter, A.; Pethig, F. The Digital Twin Theory. Ind. Manag. 2019, 35, 27–30. [Google Scholar] [CrossRef]
- Plattform Industrie 4.0: Details of Asset Administration Shell, Version 2.0.1. 2019. Available online: https://www.plattform-i40.de/PI40/Redaktion/DE/Downloads/Publikation/Details_of_the_Asset_Administration_Shell_Part1_V2.html (accessed on 31 May 2021).
- AASX Package Explorer. Available online: https://github.com/admin-shell-io/aasx-package-explorer (accessed on 17 March 2021).
- Basissystem Industrie 4.0. Available online: https://www.basys40.de (accessed on 17 March 2021).
- Eclipse Basyx. Available online: https://www.eclipse.org/basyx (accessed on 17 March 2021).
- PLMXML. Available online: https://www.plm.automation.siemens.com/global/de/products/plm-components/plm-xml.html (accessed on 17 March 2021).
- OMG: Requirements Interchange Format (ReqIF). Available online: https://www.omg.org/spec/ReqIF (accessed on 17 March 2021).
- Plattform Industrie 4.0 Aspects of the Research Roadmap in Application Scenarios. Available online: https://www.plattform-i40.de/PI40/Redaktion/EN/Downloads/Publikation/aspects-of-the-research-roadmap.html (accessed on 10 May 2021).
- Goldkuhl, G. Action research vs. design research-using practice research as a lens for comparison and integration. In Proceedings of the Workshop on IT Artefact Design & Workpractice Improvement (ADWI), Tilburg, The Netherlands, 5 June 2013. [Google Scholar]
- BaSysPLM. Available online: https://www.softwaresysteme.pt-dlr.de/media/content/Projektblatt_BaSys_PLM.pdf (accessed on 17 March 2021).
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Deuter, A.; Imort, S. Product Lifecycle Management with the Asset Administration Shell. Computers 2021, 10, 84. https://doi.org/10.3390/computers10070084
Deuter A, Imort S. Product Lifecycle Management with the Asset Administration Shell. Computers. 2021; 10(7):84. https://doi.org/10.3390/computers10070084Chicago/Turabian Style
Deuter, Andreas, and Sebastian Imort. 2021. "Product Lifecycle Management with the Asset Administration Shell" Computers 10, no. 7: 84. https://doi.org/10.3390/computers10070084