Structured Development of Digital Twins—A Cross-Domain Analysis towards a Unified Approach
Abstract
:1. Introduction
- to identify relevant information (roles, activities, etc.) from empirical studies
- to abstract from domain-specific particularities and specify a proper level of abstraction in order provide a frame of reference for further DT developments.
- Research Question 1: What empirically valid knowledge (in form of in-depth studies) exists (in different application domains) about the process for developing DTs?
- Research Question 2: In how far can a generally applicable model be defined for the construction and further development of DTs?
2. DT Literature Review
- Virtual Twin—a virtual representation is created based on a physical asset (in the cloud)
- Predictive Twin—physics, data, or hybrid models based on a virtual twin in order to predict behavior of a physical asset
- Twin Projection—the data obtained through the predictive twin is analyzed in order to gain insights in terms of underlying operations and processes
- With respect to data handling, issues of protection, security, and quality should be supported by cryptography, blockchain, and Big Data technologies.
- Real-time communication should be supported through compression techniques or proper communication technologies including 5G and IoT protocols.
- Real-time modeling and modeling the unknown requires combined sensing, symbolic regression, reduced order modeling, or multivariate data-driven models along cybernetic life cycles in order to continuously update an existing model.
- Interfacing physical assets technologically and organization-wise should be enabled through sensor technologies, physics-based simulation, data-driven models, and human-accessible interaction mechanisms such as natural language interfaces, augmented or virtual reality features.
- The variability of system topologies requires edge, fog, and cloud computing approaches.
- Maintainability should be based on transparent and interoperable architecting, allowing for hybrid analysis and modeling
3. Material and Research Methods
4. Results
4.1. Product Lifecycle Management
4.2. Manufacturing
- Envision: Ideas and inputs to implement them are collected and documented.
- Design: (i) Creation of 3D CAD models of the mechatronic components of the system with some modeling tool; (ii) Instantiate the 3D models using a design tool, such as Line Designer, by accessing the base data model; (iii) The functional groups are added; (iv) The mechanical dependencies of the system are created; (v) The finished 3D CAD model is stored as a higher-level system model in the base data model.
- Develop: (i) Creation of an electronic model based on the 3D CAD model; (ii) Using a direct interface between Automation Designer and other tools, the input and output signals of the components as well as the control functions, controllers and functional groups are created; (iii) After the electrical model has been created, the signal and function blocks are transferred from Automation Designer to a portal; (iv) The PLC control programs are also created in this portal.
- Verify/Validate: (i) The PLC programs are tested by virtual test runs; (ii) As different models of DTs are created, they are now integrated into an overall system; (iii) The overall system is again tested by virtual test runs, checking whether the overall system meets the requirements.
- Deploy: After completion of the previously described model, it is deployed and can then be used.
- Use: After the system has been deployed, it can be used.
- Evaluate: The system is continuously monitored and maintained if necessary, see subsequent step Maintain.
- Maintain: The maintenance of the DT model can be achieved in two different ways, either by step Tune or step Rebuild.
- Tune: The already existing model can be improved.
- Rebuild: If maintenance requires rebuilding, re-design or re-development has to be performed.
- Park et al. [16] describes a DT architecture, which can be divided into four layers. The first two layers, including the IoT network, can be assigned to the physical environment, aside from the manufacturing application and the cloud application that can be assigned to the virtual environment. Utilizing the described architecture, Design, Development, and Verification are affected for the construction of the DT. It supports considering the efficiency in terms of cost and production, and affects the Use of DTs, and their further development (Deployment, Evaluation, Maintenance, Tuning, and Rebuilding).
- Kong et al. [17] address the storage, integration, and analysis of data, which are major challenges in the development of DTs. The proposed framework for managing the data fits into the DT development model for production systems.
- Wang et al. [18] show, analogous to [16], an architecture with three modules to implement the DT concept. The data capture module is responsible for capturing data from the physical space. The data module is used for data management and data processing. Lastly, the DT Intelligence module can be seen as the service part, where it also contains the logic for the dashboard to display the information. The connection between physical and virtual space for data transfer is solved via an IoT network. The described architecture thus coincides in its basic characteristics with the previously discussed work.
- Stark et al. [19] defined 8 dimensions that contribute to the description of the behavior and context of a specific DT. With regard to specifying a DT development model of the manufacturing domain, no specific process steps can be derived from this study, but understanding the creation of DTs is facilitated which is an essential aspect for development—it affects Evaluation and further development activities, leading to redesign and improvements. The latter is indicated in the DT development model for activities like asking for the fitness of design (Figure 8).
- The architecture of [21] coincides with the other sources, and focuses on the processing of information for the integration of real-time data and the evaluation of the system component for information retrieval. This is intended to enable optimization of throughput times. In terms of the development model, this source provides information on how to automatically create a DT, but also to optimize the lead time of the production process.
- Moyne et al. [11] introduced two adopted phases, that have been embedded, providing for the development of the DT in an off-line mode, and its productive use in an on-line mode.
4.3. Predictive Maintenance
4.4. Towards a Cross-Domain, Unifying DT Development Model
- Digital Model—it is understood as a digital representation of an existing or planned physical object. It is essential that this category does not have an automated way of exchanging data between the physical and virtual model. The digital representation can have a more or less comprehensive description of the physical object. In addition, the digital representation can consist of simplified simulated models, planned factories, mathematical models of new products, but also other models of physical objects, provided that these do not exhibit any form of automated digital integration. A change in the status of the physical object has no direct effect on the digital object, and vice versa [28].
- Digital Shadow—it is an extension of the Digital Model definition. A Digital Shadow was created if, in addition to the definition of the Digital Model, there is an automated data flow starting from the physical object towards the virtual object, but not vice versa. A status change in the physical object therefore leads to a status change in the digital object, but not vice versa [28].
- Digital Twin—in contrast to a digital shadow, the automated data flow is bidirectional, and thus a change in the status of the digital object also results in a change of status in the physical object [28].
- Definition of the components of the machine;
- Definition of the degree of modeling;
- Creating the model of the machine.
- Definition of the required virtual data;
- Selection of the model for virtual sensors;
- Integration of the virtual sensors into the model of the machine.
- Selection of the components to be coordinated with each other;
- Definition of the real data;
- Selection of the parameters that are to be matched.
- Prepare includes not only a use case description as provided above, but also the collected inputs to develop a DT. For the transportation case, the major rationale was the objective of designing all devices in way that a minimum of stationary equipment and information for dispatching is required, so that the process can be applied in various physical settings, and thus does not require a certain physical environment. The goods and devices should ‘carry’ all process-relevant information to trigger the next step. For instance, the vaccine to be dispatched contains information under which conditions it needs to be transported.
- Design: In this step the virtual representations of the physical counterparts is modeled following the procedure of manufacturing DT design. For equipping containers with IoT systems to transport vaccines as required, 3D CAD models of the mechanical part to plug in sensors into container are created. In addition, the storage system for containers and IoT systems is constructed. Finally, these 3D CAD need to be instantiated to identify the mutual interaction and functional dependencies. The final step includes the completion of a 3D model including the three models. These models lay the groundwork for developing the DT including the business logic required to operate the CPS. All incoming and outgoing message, control functions, and functional groups are specified in this step. It includes abstractions for the robot movements to accomplish packaging after picking up the vaccine.
- Verify/Validate targets the CPS behavior for the entire dispatching procedure, including testing its components in a virtual test run. Of particular importance is the interaction between component to accomplish the packaging task. The different behavior models are integrated into a network of processes.
- Deploy: The fully developed and validated DT becomes part of the transportation workflow and can be installed and configured for practical use. For each component, a corresponding runtime needs to be set up and successively integrated with the other components to successfully enable the required interaction for picking up and packaging. The transportation case also requires synchronization, which means to couple the physical devices with their digital counterpart at runtime.
- Use: Once the DT can be used to control the dispatching process involving the physical CPS components (robotic system fir picking up the vaccine and plug in IoT system devices, container, IoT systems).
- Evaluate: When in use, the DT operation is evaluated in terms of successfully picking up the vaccine by the robot system, equipping a container with the required IoT systems, and packaging the vaccine for further transportation. Adaptation might be required in case of adjusting components, changes in the physical handling, or the logic to handle the business case. In this case, the DT management must be maintained.
- Tune: If the adjustment is minor, the existing DT model can be changed during runtime. In other cases, the DT model changes lead to the redesigning of the CPS structure and/or component behavior of the transportation components.
- Rebuild: Changing requirements or faulty behavior can lead to a total DT revision, affecting the transportation workflow and its structure (including physical components). For instance, the distribution of information and IoT devices could be affected if dispatching information is not located on the vaccine to be packaged and/or IoT systems need to be composed and tested before being plugged into the container.
5. Discussion
- What empirically valid knowledge exists (in different application domains) about the process for developing DTs?
- In how far can a generally applicable model be defined for the construction and further development of DTs?
6. Conclusions
- to identify relevant roles and processed information from the empirical data
- to determine the proper level of abstraction, both for domain-specific modeling, and for providing a frame of reference for further DT developments
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Acknowledgments
Conflicts of Interest
Glossary
Digital Twin | A digital twin is a digital representation of a physical asset |
Process | A process describes a value-generating procedure in terms of actors or systems that perform activities in a sequential and logical order, while processing data, in order to accomplish a business-relevant task or objective |
Stakeholder | A stakeholder is a person in a specific role involved in the development and/or operation of system or process |
Domain | A domain is an application sector of Cyber-Physical Systems |
Cyber-Physical System | A cyber-physical system is a socio-technical system composed of information technology and physical elements. These components are connected and have the capability to exchange data, in order to control the system’s operation via a network, such as the Internet |
Internet-of-Things | The Internet-of-Things denotes interconnected computing devices via an Internet communication protocol. The devices can thus exchange data |
Socio-technical System | A socio-technical system is a system involving people and technology. It comprises individuals, communities, digital and physical technologies. Humans interact with these technologies to accomplish their tasks and adapt them according to their needs |
References
- Sauer, O. The Digital Twin-An Essential Key Technology for Industrie 4.0. ERCIM News 2018, 32–33. [Google Scholar]
- Glaessgen, E.; Stargel, D. The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles. In Proceedings of the 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference, Honolulu, HI, USA, 23–26 April 2012; American Institute of Aeronautics and Astronautics: Reston, VA, USA, 2012. [Google Scholar] [CrossRef]
- Grieves, M. Origins of the Digital Twin Concept; Florida Institute of Technology: Melbourne, FL, USA, 2016. [Google Scholar] [CrossRef]
- Jones, D.; Snider, C.; Nassehi, A.; Yon, J.; Hicks, B. Characterising the Digital Twin: A systematic literature review. CIRP J. Manuf. Sci. Technol. 2020, 29, 36–52. [Google Scholar] [CrossRef]
- Lu, Y.; Liu, C.; Kevin, I.; Wang, K.; Huang, H.; Xu, X. Digital Twin-driven smart manufacturing: Connotation, reference model, applications and research issues. Robot. Comput.-Integr. Manuf. 2020, 61, 101837. [Google Scholar] [CrossRef]
- Rasheed, A.; San, O.; Kvamsdal, T. Digital twin: Values, challenges and enablers from a modeling perspective. IEEE Access 2020, 8, 21980–22012. [Google Scholar] [CrossRef]
- Liu, M.; Fang, S.; Dong, H.; Xu, C. Review of digital twin about concepts, technologies, and industrial applications. J. Manuf. Syst. 2021, 58, 346–361. [Google Scholar] [CrossRef]
- Tao, F.; Zhang, H.; Liu, A.; Nee, A.Y.C. Digital Twin in Industry: State-of-the-Art. IEEE Trans. Ind. Inform. 2019, 15, 2405–2415. [Google Scholar] [CrossRef]
- Zheng, Y.; Yang, S.; Cheng, H. An application framework of digital twin and its case study. J. Ambient Intell. Humaniz. Comput. 2019, 10, 1141–1153. [Google Scholar] [CrossRef]
- Negri, E.; Fumagalli, L.; Macchi, M. A review of the roles of digital twin in cps-based production systems. Procedia Manuf. 2017, 11, 939–948. [Google Scholar] [CrossRef]
- Moyne, J.; Qamsane, Y.; Balta, E.C.; Kovalenko, I.; Faris, J.; Barton, K.; Tilbury, D.M. A Requirements Driven Digital Twin Framework: Specification and Opportunities. IEEE Access 2020, 8, 107781–107801. [Google Scholar] [CrossRef]
- Tao, F.; Sui, F.; Liu, A.; Qi, Q.; Zhang, M.; Song, B.; Guo, Z.; Lu, S.C.-Y.; Nee AY, C. Digital twin-driven product design framework. Int. J. Prod. Res. 2019, 57, 3935–3953. [Google Scholar] [CrossRef]
- Tao, F.; Cheng, J.; Qi, Q.; Zhang, M.; Zhang, H.; Sui, F. Digital twin-driven product design, manufacturing and service with big data. Int. J. Adv. Manuf. Technol. 2018, 94, 3563–3576. [Google Scholar] [CrossRef]
- Lim KY, H.; Zheng, P.; Chen, C.-H. A state-of-the-art survey of Digital Twin: Techniques, engineering product lifecycle management and business innovation perspectives. J. Intell. Manuf. 2020, 31, 1313–1337. [Google Scholar] [CrossRef]
- Haag, S.; Anderl, R. Digital twin—Proof of concept. Manuf. Lett. 2018, 15, 64–66. [Google Scholar] [CrossRef]
- Park, K.T.; Nam, Y.W.; Lee, H.S.; Im, S.J.; Noh, S.D.; Son, J.Y.; Kim, H. Design and implementation of a digital twin application for a connected micro smart factory. Int. J. Comput. Integr. Manuf. 2019, 32, 596–614. [Google Scholar] [CrossRef]
- Kong, T.; Hu, T.; Zhou, T.; Ye, Y. Data Construction Method for the Applications of Workshop Digital Twin System. J. Manuf. Syst. 2021, 58, 323–328. [Google Scholar] [CrossRef]
- Wang, K.-J.; Lee, Y.-H.; Angelica, S. Digital twin design for real-time monitoring—A case study of die cutting machine. Int. J. Prod. Res. 2021, 59, 6471–6485. [Google Scholar] [CrossRef]
- Stark, R.; Fresemann, C.; Lindow, K. Development and operation of Digital Twins for technical systems and services. CIRP Ann. 2019, 68, 129–132. [Google Scholar] [CrossRef]
- Deb, A. Crashworthiness design issues for lightweight vehicles. In Materials, Design and Manufacturing for Lightweight Vehicles; Elsevier: Amsterdam, The Netherlands, 2010; pp. 332–356. [Google Scholar] [CrossRef]
- Biesinger, F.; Meike, D.; Kraß, B.; Weyrich, M. A digital twin for production planning based on cyber-physical systems: A Case Study for a Cyber-Physical System-Based Creation of a Digital Twin. Procedia CIRP 2019, 79, 355–360. [Google Scholar] [CrossRef]
- Ashtari Talkhestani, B.; Weyrich, M. Digital Twin of manufacturing systems: A case study on increasing the efficiency of reconfiguration. Automatisierungstechnik 2020, 68, 435–444. [Google Scholar] [CrossRef]
- Centomo, S.; Dall’Ora, N.; Fummi, F. The Design of a Digital-Twin for Predictive Maintenance. In Proceedings of the 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Vienna, Austria, 8–11 September 2020; pp. 1781–1788. [Google Scholar] [CrossRef]
- Aivaliotis, P.; Georgoulias, K.; Chryssolouris, G. The use of Digital Twin for predictive maintenance in manufacturing. Int. J. Comput. Integr. Manuf. 2019, 32, 1067–1080. [Google Scholar] [CrossRef]
- Aivaliotis, P.; Georgoulias, K.; Arkouli, Z.; Makris, S. Methodology for enabling Digital Twin using advanced physics-based modelling in predictive maintenance. Procedia CIRP 2019, 81, 417–422. [Google Scholar] [CrossRef]
- Aheleroff, S.; Xu, X.; Zhong, R.Y.; Lu, Y. Digital Twin as a Service (DTaaS) in Industry 4.0: An Architecture Reference Model. Adv. Eng. Inform. 2021, 47, 101225. [Google Scholar] [CrossRef]
- Barricelli, B.R.; Casiraghi, E.; Fogli, D. A Survey on Digital Twin: Definitions, Characteristics, Applications, and Design Implications. IEEE Access 2019, 7, 167653–167671. [Google Scholar] [CrossRef]
- Kritzinger, W.; Karner, M.; Traar, G.; Henjes, J.; Sihn, W. Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 2018, 51, 1016–1022. [Google Scholar] [CrossRef]
Search No. | Database | Search Terms Including Designation and Link Sources from 2014 | Number of Entries Found | Note |
---|---|---|---|---|
1 | Google Scholar | digital twin AND “product” | 12,100 | 3 in-depth sources selected |
2 | Google Scholar | digital twin AND “implementation” AND “case study” | 17,200 | 7 in-depth sources selected |
3 | Google Scholar | digital twin AND “tuning” | 2110 | 0 Sources selected |
4 | Google Scholar | “case study” AND “digital twin” AND “tuning” | 859 | 2 in-depth sources selected |
5 | Google Scholar | case study AND “digital twin” AND “learning” | 5150 | 0 Sources selected |
6 | Google Scholar | case study AND “digital twin” AND “improvement” | 6710 | 0 Sources selected |
7 | Google Scholar | case study AND “digital twin” AND “lifecycle” | 4950 | 2 in-depth sources selected |
8 | Google Scholar | case study AND “digital twin” AND “validation” | 6210 | 1 in-depth sources selected |
Product-Lifecycle Management | Manufacturing | Predictive Maintenance | Indepth Study | Year |
---|---|---|---|---|
x | An application framework of Digital Twin and its case study [9] | 2019 | ||
x | Digital twin-driven product design framework [12] | 2019 | ||
x | Digital twin-driven product design, manufacturing and service with big data [13] | 2018 | ||
x | A state-of-the-art survey of Digital Twin: techniques, engineering product lifecycle management and business innovation perspective [14] | 2020 | ||
x | Digital Twin—proof of concept [15] | 2018 | ||
x | Design and implementation of a Digital Twin application for a connected micro smart factory [16] | 2019 | ||
x | Data construction method for the application of workshop Digital Twin system [17] | 2020 | ||
x | Digital Twin design for real-time monitoring—a case study of die cutting machine [18] | 2020 | ||
x | Development and operation of Digital Twin for technical systems and services [19] | 2019 | ||
x | A Digital Twin for production planning based on Cyber-Physical Systems: A case study for a Cyber-Physical System-based creation of a Digital Twin [20,21] | 2019 | ||
x | Digital Twin of manufacturing systems: a case study on increasing the efficiency of reconfiguration [22] | 2020 | ||
x | Requirements-driven Digital Twin framework: Specification and opportunities [11] | 2020 | ||
x | The design of a Digital-Twin for predictive maintenance [23] | 2020 | ||
x | Methodology for enabling Digital Twin using advanced physics-based modelling in predictive maintenance [24] | 2019 | ||
x | The use of Digital Twin for predictive maintenance in manufacturing [25] | 2019 |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2022 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/).
Share and Cite
Heindl, W.; Stary, C. Structured Development of Digital Twins—A Cross-Domain Analysis towards a Unified Approach. Processes 2022, 10, 1490. https://doi.org/10.3390/pr10081490
Heindl W, Stary C. Structured Development of Digital Twins—A Cross-Domain Analysis towards a Unified Approach. Processes. 2022; 10(8):1490. https://doi.org/10.3390/pr10081490
Chicago/Turabian StyleHeindl, Wolfgang, and Christian Stary. 2022. "Structured Development of Digital Twins—A Cross-Domain Analysis towards a Unified Approach" Processes 10, no. 8: 1490. https://doi.org/10.3390/pr10081490