Characterizing the Digital Twin in Structural Mechanics

Abstract

The Digital Twin is one of the major technology trends of the last decade. During the course of its rapid expansion into various fields of application, many definitions of the Digital Twin emerged, tailored to its respective applications. Taxonomies can cluster the diversity and define application-specific archetypes. This paper presents a systematic characterization of the Digital Twin in the context of structural mechanics and lightweight design. While the importance of a shared understanding and the development of holistic solutions for implementing Digital Twins in various application areas is widely recognized, a general framework for implementing Digital Twins in structural mechanics has not yet been established. In this paper, we systematically characterize Digital Twins and develop a framework for their application in structural mechanics, enabling the digital design and monitoring of structures for improved performance and maintenance strategies. The key contributions include collecting and clustering design and operational requirements and deriving two central archetypes: structure-designing and structure-monitoring Digital Twins. The primary goal is to reduce the complexity of conceptualizing Digital Twins of structures by providing a preliminary framework and reconsidering the Digital Twins of structures as a holistic system throughout the product life cycle. Overall, in this paper, we take a systematic approach to enhancing the conceptualization and implementation of Digital Twins in structural mechanics.

1. Introduction

The Digital Twin (DT) is one of the major technology trends of the last decade [1]. Initially introduced in 2002 by Micheal Grieves [2] under the name “Conceptual Ideal for Product Life Cycle Management”, many interpretations have arisen, generating various definitions from diverse fields of application. As a result, the Digital Twin, with its characteristic features, is not clearly outlined. Consequently, new definitions are often created for new developments to focus on the relevant aspects of a particular application. The derivation of a generally valid definition fails due to the sheer variety in the different fields of application for Digital Twins.

Several approaches were pursued to address this problem. Jones et al. [3] present a systematic literature review to generate 13 characteristics and processes of the Digital Twin. Furthermore, gaps and future directions for research were identified, including “Digital Twin across the Product Life Cycle” or “Integration between Virtual Entities”. They highlight the importance of framing future Digital Twin use cases with a consolidated common understanding and terminology. Josifovska et al. [4] developed a reference framework for developing Digital Twins of physical entities which are part of a cyber-physical system (CPS). A key result is the main building blocks of a Digital Twin framework in CPSs with their properties and interrelations. Semeraro et al. [5] explore the main features of Digital Twins from a manufacturing perspective. One of the research challenges highlighted here is the missing architecture of Digital Twins, which leads to partial Digital Twin solutions using different technologies, interfaces, communication protocols and models for specific applications. Van der Valk et al. [6] generalize this approach further to derive an application-independent taxonomy. All studies emphasize the relevance of a shared understanding and the development of holistic solutions for implementing Digital Twins in various application areas.

One such application field is structural mechanics. While manufacturing [7], simulation [8], human health [9] and infrastructure [10] are frequently mentioned applications of Digital Twins, structural mechanics appears less often. Nevertheless, Digital Twins are seldomly applied for marine and off-shore [11] or aircraft structures [12]. Aircraft structures, in particular, were a central starting point for the Digital Twin paradigm [13,14]. Here, the Digital Twin is proposed as a highly realistic, integrated, multiphysics, multiscale, probabilistic simulation of an aircraft system that uses diverse data sources to continuously forecast its health, remaining useful life (RUL) and mission success probability [13]. The Digital Twin should manage the aircraft over its entire life cycle by creating a tail-number-specific model for each aircraft [14]. The concept, in its full complexity, has, to the best of the authors’ knowledge, not yet been implemented. Nevertheless, individual aspects of the product life cycle, such as the design and operation of structures with Digital Twins, are discussed.

Focusing on design aspects, Ryll et al. [15] investigate the potential of a Digital Twin in the design phase for an application in a hybrid lightweight structure. The method to develop a Digital Twin was demonstrated on a table-sized demonstrator. Kokkonen et al. [16] discuss the Digital Twin in the context of the robust and lightweight design of a fatigue-critical welded structure with measured misalignments. Zhu and Wang discuss another aspect of the Digital Twin in the context of design aspects [17] using the example of prestressed steel structures, employing Digital Twins and random forests using the string-supported beam structure as a test object. This approach determines key design parameters affecting mechanical parameters, laying the foundation for intelligent control of structural safety.

In addition to the development phase, the interface for the monitoring and predictive maintenance is often discussed. A systematic review on predictive maintenance using Digital Twins in general is provided by van Dinter et al. [18]. The specific benefits of supporting structural monitoring are discussed in a number of papers [19,20,21,22]. For example, Tygesen et al. [19] introduce the “true Digital Twin concept” for improving Digital Twin performance in predicting marine structure fatigue life. This concept, implemented through a three-level process with decision gates, facilitates accurate fatigue estimation models, potentially enhancing updated marine structures’ fatigue life to reflect real conditions better.

In the presented papers, individual approaches to solving important challenges in implementing Digital Twins in structural mechanics are developed and realized, whether for design or monitoring. Nevertheless, there is still no general framework for implementing Digital Twins in structural mechanics as recommended by [4,5,6]. This paper aims to close the gap of a missing framework for the Digital Twin of structural components towards a holistic approach. Through the methodical structuring of requirements, we intend to characterize and classify the requirements in the existing taxonomy of van der Valk et al. [6] and derive two linked archetypes. In particular, we focus on the distinction between the design and operational phase and the associated challenge of realizing a holistic Digital Twin in structural mechanics.

The text is structured as follows: Section 2 presents the state of the art concerning existing definitions and classification schemes for categorizing Digital Twins. Furthermore, we present existing design methodologies for structures. Based on the state of the art, two key tasks emerge: we derive requirements first for the Digital Twin in the design (Section 3.1) and second for the operational phase (Section 3.2) of structures. These requirements are then merged (Section 3.3) based on the taxonomy of van der Valk et al. [6], see Section 4. We conclude the paper with a summary of the results and point out future research activities of Digital Twins in structural mechanics.

2. Related Literature

At the beginning, we present different definitions of a Digital Twin and existing proposals for better capturing them in different application areas, see Section 2.1. In the second step, we introduce the basics of structural design used in the following chapters, deriving requirements for a Digital Twin, see Section 2.2.

2.1. Digital Twin Definitions and Categories

The concept of the Digital Twin goes back to a presentation in 2002 held by Michael Grieves at the University of Michigan [2]. The presentation slides, shown in the context of establishing a centre for Product Life Cycle Management (PLM), initially called the concept of the future Digital Twin the “Conceptual Ideal for PLM”. The concept already contained the three central building blocks to define a Digital Twin: a physical instance, a virtual instance, and a data flow from the physical to the virtual instance and vice versa. In 2014, Grieves published his white paper “Digital Twin: Manufacturing Excellence through Virtual Factory Replication” [2], in which he postulated the previously published concept as the “Digital Twin” concerning recent technological advances [2].

A key feature of Grieves’ definition [2] is the bi-directional coupling between real and virtual instances, see Figure 1. This coupling feature is adopted in many definitions of Digital Twins [23,24]. Fuller et al. [23] distinguish the terms “Digital Model” and “Digital Shadow” from the term Digital Twin based on the extent of the coupling. The model describes a digital version of a planned or existing component, which coexists without coupling to an existing real component. If the information flows from the component to the model, the model will become a digital shadow. However, the digital shadow does not provide feedback to the real component. The defined Digital Twin will only be obtained if the flow of information is designed bi-directionally. The coupling factor and the feedback components make this definition particularly interesting for control applications and structural monitoring.

In addition to the extent of the coupling, other aspects and perspectives have also shaped the definition of the Digital Twin. In the context of simulation technology [8] and Internet of Things [25] applications, the focus is particularly on interconnected, holistic modelling. Glaessgen and Stargel [13] describe the central feature as a holistic simulation in the form of a “multiphysics, multiscale, probabilistic simulation” that combines sensors, flight and fleet data along with a maintenance history. Other papers [26,27,28] also share the idea of Digital Twins as holistic simulation models that reveal all functional properties of a physical system. Roßmann and Schluse [29] define the term “Experimental Digital Twin” as an exact representation of an Industry 4.0 component with its structures, models and data, interfaces and communication capabilities. All-encompassing twins are highly attractive, but their implementation is not feasible or even sensible for many applications due to their complexity.

Another industry that shapes the definitions of Digital Twins is production engineering and manufacturing [7]. Here, the focus lies on the accuracy of mapping a specific process, enabling all information to be recorded and displayed at any time [30,31]. The Scientific Society for Production Technology in Germany therefore calls the Digital Twin a “supplier of an as identical as possible image […] via a process model” [30]. Here, the term digital shadow is used for a “real-time capable evaluation basis of all relevant data”.

To sum up, we can state that each industry and application defines its own requirements and characteristics of the Digital Twin. No appropriate classification or definition has yet been made for the field of structural mechanics. Due to the increasing number of existing definitions, an overview and organization of the definitions and application areas of the Digital Twin are required. This has been performed in various reviews [3,5,32]. Jones et al. [3] reviewed 92 publications to derive 13 characteristics of the concept of a Digital Twin. Enders and Hoßbach [33] analyze Digital Twin applications across different industries and propose a classification scheme with six dimensions to describe the founded applications. In the context of so-called cyber-physical systems (CPSs), Josifovska et al. [4] develop a reference framework and specify the main building blocks of a Digital Twin in terms of structure and interrelations. All these approaches allow for categorizing and structuring the most diverse Digital Twin approaches and applications. Van der Valk et al. [6] generalize this approach further. Their aim is the derivation of an independent taxonomy as presented in

Table 1. Taxonomy of Digital Twins according to van der Valk et al. [6].

Meta-Dimension	Dimension	Characteristics
Data Collection	Data Aquisition	Automated	Semi-manual
	Data Source	Multiple Source	Single Source
	Synchronization	With	Without
	Data Input	Raw Data	Preprocessed Data
Data Handling	Data Gouvern.	Rules Applied	Rules Not Applied
	Data Link	Bi-Directional	One-Directional
	Interface	HMI	M2M
	Interoperability	None	Via Translator	Fully
	Purpose	Processing	Transfer	Repository
Conceptual Scope	Accuracy	Identical	Partial
	Conceptual Elem.	Independent	Bound
	Time of Creation	Digital First	Physical First	Simultaneously

. Based on this taxonomy, five archetypes of Digital Twins are presented, supported by literature reviews and interviews with various industry experts.

The presented definitions of the Digital Twin can be roughly summarized; overall they form a blurry and partly contradictory picture for the Digital Twin. Many reviews have therefore taken on the task of creating overviews and clustering aspects. One of these efforts is the taxonomy for Digital Twins according to van der Valk et al. [6]. Based on such fundamentals, application-specific generic archetypes can now be formed, which exhibit relevant characteristics. To close the gap of a missing framework for the Digital Twin of structural components, we derive suitable archetypes for structures. Due to the very detailed preliminary work in developing a generalized taxonomy for Digital Twins by van der Valk et al. [6], we use this taxonomy as a basis for the development of two archetypes for the structure of a Digital Twin.

2.2. Structural Design Process

The classification and formalization of structural mechanics in the named taxonomy require an understanding of the structural design process. We present the definition of a structure according to Wiedemann [34] and the product development process regarding the VDI 2221 [35].

2.2.1. Definition of a Structure According to Wiedemann

Wiedemann [34] defines a structure as a load-bearing framework or system and differentiates between its mission, function and geometry. The mission refers to “the task of the supporting structure to bring forces acting at certain points, lines or surfaces […] into material equilibrium”. “Function” refers to the load-bearing capacity to implement this mission based on analytical models, for example, beams, tension or compression rods, shear walls and shells. This decomposition takes place at different functional levels based on the size scale, so a hierarchical model must be assumed. The geometry determines the external and internal dimensions of the load-bearing system and can be divided into “topology”, “form” and “dimensioning” levels:

• Wiedemann [34] defines “topology” as the number of variables and their relationship within the function. For example, the topology of a beam consists of the variance of its cross-section over its length and that of a truss variances by the number of its rods.
• The “shape” determines the geometric characteristics of the structural system. These are, for example, the external dimensions of a beam cross-section or the nodal coordinates of a truss.
• The “dimensioning” determines the quantitative wall thicknesses of the individual cross-section parts and thus completes the geometric description of the load-bearing system.

2.2.2. Product Development According to VDI Guideline 2221/2019

According to VDI Guideline 2221 [35], product development is an interdisciplinary corporate process for developing a marketable product based on the definition of initial goals and requirements for the product, which are continuously developed and iteratively adapted in the course of the process. Thereby, a product is a material or immaterial product or service that is offered alone or as a system to satisfy the market and users’ needs in a targeted group-oriented manner. Furthermore, a system is “the number of elements delimited by a system boundary, which are in relation and interaction with each other”. A function is defined as a “general and intentional relationship between the input and output of a system to fulfil a task”.

The VDI Guideline 2221 [35] establishes a general model, which names activities to be performed within product development. The chronological order of these activities and the resulting bundling into phases depend on the respective product and its so-called context factors and are thus to be determined individually. The guideline is limited to the definition of a central guideline expressed in the general product development model. A connection to software development tools, such as the unified modelling language (UML), is made at various points, as a necessary step to formalize the design process of the structure.

2.2.3. Summary of Structural Design Process

Wiedemann [34] bases their approach for structural design on the fundamental hypothesis that the design process is a creative process that can only be formalized to a limited extent. In particular, the conception phase requires an exceptionally high degree of creativity and can only be automated for simple problems. Wiedemann places the creatively acting human being at the centre of the design process. Consequently, the process is subject to the logic of the construction methodology. The point mentioned regarding the creative process contradicts the objective of a formal description for the digital representation of the design process as needed in a Digital Twin. This is contrasted by the attempt of VDI Guideline 2221 [35] to standardize the product development process as far as possible. However, the VDI 2221 process is a general framework and not tailored to specific issues within the structural design process. In the following, we will merge the definitions of Wiedemann and the VDI 2221 with the aim of providing a formalized description for the structural design process in the Digital Twin.

3. Analyzing the Product Life Cycle of Structures for Digital Twins

To analyze the requirements for a structure’s Digital Twin, we generally follow the product life cycle (PLC) and divide our analysis into the design, the manufacturing and the operational phase of a structure, see Figure 2. The instances of the Digital Twin are viewed in parallel. We assume a purely virtual instance in the design process; i.e., no real counterpart exists at this point in time. Both virtual and real instances of the twin pair are present during production and operation. In the context of this paper, the end of life in the PLC is not considered. We start with breaking down the design process, see Section 3.1, and continue with the operational phase, see Section 3.2.

3.1. Requirements of the Design Phase

To describe the levels of a structural system, first, the following definitions are introduced: A “subsystem”, which is geometrically independent. This means that changes in geometry and shape do not affect the neighboring systems. An “assembly” represents a module of the subsystem. Modularity may be motivated by installation, allocation or transport/handling. The assembly, unlike the subsystem, is not geometrically independent from the neighboring assemblies. A “component” represents the smallest continuous, non-joined unit of the structural system.

Next, we transfer the activities of the general model of VDI 2221 [35] to the structural design process. For this purpose, three development phases are defined: In the conceptionphase, the loads and boundary conditions are determined. The load-bearing structure solution, including the technology, is determined and evaluated. In the preliminary design, the topology in the form of subsystems, assemblies and components is defined and optimized. Within the design, components are optimized in shape and dimensioned. In the next step, we propose the following sequence of activities according to VDI 2221 [35] and their assignment to the previous named development phases:

• Conception:

  –

  Clarify and specify the problem or task.

  –

  Determining functions.

  –

  Searching for solution principles.

  –

  Evaluating and selecting the solution concept.

• Preliminary Design:

  –

  Structuring into subsystems, components and interfaces.

  –

  Layout of components and interfaces.

• Design:

  –

  Integrating the entire product.

  –

  Implementing the design and usage specifications.

  –

  Ensuring the fulfillment of requirements by dimensioning and optimizing chosen components and interfaces.

Table 2. Overview of chosen requirements in the design phase.

Phase	Information Type	Data	DT Requirements
Conception	Principal Solution	-	Concept database
	Conceptual load-bearing system	-
	Material	Characteristics	Material database
		Cost
	Boundaries	Positions	Virtual environment
		DOF
		Bearing
		Installation space
	Loads	Type	Virtual test-bed for generating and testing simulation-based load cases
		Direction
		Size
		Position
Preliminary Design	Subsystem	-	Models with a low detail level (implicit) for identifying and testing influencing parameters
	Interface	Position
		DOF
	Component	Length
		Cross-section
		Orientation
		DOF
Design	Component Shape	Dimensions	Models with a high detail level (explicit) for verification
	Dimensioning	(Wall) Thickness
		Safety factors
	Joints	Typ
		Positions
		Number
		Dimensions

shows the design phases, the general activities according to VDI 2221, and the information and the associated data or data sets, which are defined in the individual phases of the structural design and are summarized and provided with suggestions for the inclusion of a Digital Twin. In summary, we derived a series of steps and requirements that a Digital Twin must represent in the context of the design phase of a structure:

• Formalized representation of the three steps of conception, preliminary design, and design.
• Providing a virtual environment that represents the boundary conditions and the associated subsystem.
• Interface to databases, e.g., for material comparisons, which provide additional information about properties, costs, availability, etc.
• Modelling approaches with an increasing level of detail depending on the design phase organized in hierarchical modelling.
• Virtual test-bed for interaction with the (virtual) environment in an early design stage and simulation-based load case development.

The result of the design phase is the complete definition of all structural parameters, typically documented in the set of technical drawings. In the following, we look at the requirements of a Digital Twin of a structure in the operational phase.

3.2. Requirements of the Operational Phase

The design phase described here ends with the manufacturing of real structural components. Manufacturing thus represents the beginning of coexistence between the Real Twin and the Digital Twin of the design phase. We divide the transition to the operational phase into three steps: completing the design phase, manufacturing the structures and calibrating the Digital Twin in multiple instances, see Figure 3. The design phase quantifies all structural properties with definite target values. They represent our expected design values after manufacturing the structure (${\mu }_{Design}$). However, in manufacturing, these properties are scattered around this expected design value [36]. The properties of the real instance thus may not correspond to the virtual instance, i.e., the Digital Twin from the design phase, but rather to a normal distribution around it. If a Digital Twin of the individual real instances will be created for further use in operation, this deviation must be individually recorded. In order to achieve this necessary coupling with the Digital Twin, or, respectively, a model, from the design phase, an initial calibration is always required. This calibration is a necessary condition to turn a model into a Digital Twin and link the design phase with the operational phase [21].

At this point, new Digital Twins for each instance are created to accompany, monitor and document the real structures in their individual operational phases. During the operational phase, the manufactured structures as individual instances are now confronted with their environment. Each component can experience individual use with different exposures. The Digital Twin in operation has the task of recording and displaying the individualization of the structure during its use phase and evaluating individual assessments concerning further use.

Figure 4 visualizes the potential degradation of a structural property, e.g., stiffness $EI$, based on the shift in the expected value ${\mu }_{1,0}$ from the originally calibrated value to worse values at later points in time (${\mu }_{1,1}$, ${\mu }_{1,2}$, ${\mu }_{1,3}$). With increasing temporal distance from the calibration, we expect a higher degradation in the structural properties. Furthermore, additional to the degradation, the uncertainty in predicting the actual properties increases, due to an increase in assumptions made, e.g., regarding the experienced loads, potential damages and environmental influences. Depending on the actual mission, different instances of the same structure experience different product lives. This higher uncertainty regarding the actual structural state means that the connection between the Real and the Digital Twins will increasingly decrease during operation if they are not constantly re-calibrated. An SHM system carries out the necessary continuous monitoring, evaluation and adaptation in the case of structures [21]. The SHM system is the central coupling element between the real and digital structure in operation. In addition to processing the SHM data, a Digital Twin must be extended to the system via usage and operating data.

A Digital Twin must provide suitable models to aggregate and store all information from the load monitoring, the SHM system and the operating status. Depending on the application, the suitability is determined by requirements regarding local and global accuracy, computation time, memory, automation capability and other aspects. In order to keep the memory and computational requirements low during operation, selecting only the necessary modelling depth is preferable. Less detailed models can be selected for global properties such as stiffness, displacement and deformation. More detailed models are needed when information about local effects, such as damage or force application points, is required. The central requirements for the Digital Twin of the structure in operation can be summarized as follows. The DT needs to:

• Provide a synchronization mechanism, in the form of continues re-calibration, between real components and the model;
• Automate data acquisition, processing and evaluation of an SHM system of the structure;
• Merge and store data from multiple data sources including the SHM system, environmental influences and operational data;
• Provide hierarchical coupling of suitable structural mechanical models (implicit and explicit);
• Support feedback loops to enable bi-directional coupling for individual evaluation of the structure concerning inspections like maintenance on demand or RUL [22].

Finally, it should be noted that all the points discussed here relate to the Digital Twin of the structure and to the perspective of structural mechanics. If the Digital Twin of the structure is extended to a holistic system, further requirements arise, for example, with regard to compatible interfaces or the networking of all recorded data. We identified two main steps in the service life of Digital Twins: the design process of the structure up to manufacturing and entry into service and the continuous monitoring of one or more structures during the operating phase. In the following section, we will discuss the merging of both phases.

3.3. Merging the Design and Operation Phases

First, we look at the data flow in the two phases. During the design phase, the real component usually does not yet exist. It is initially defined by its requirements, recorded in the specification sheet, and the anticipated operating environment. This information is broken down into processable data, see Table 2. The process of creating a Digital Twin involves following a structured digital design process until the final design is reached. Once the design is complete, the information is transferred to one or more Real Twins during manufacturing and calibration. Since the Real Twin does not exist until manufacturing, the previous data exchange is sequential, supported by iteration loops, see the left side of Figure 5. Once the Real Twin is created, possibilities for further iteration steps through continuous enhancements for future design generations arise.

In contrast, during the operational phase, Real and Digital Twins exist in parallel. The data exchange is therefore characterized bi-directionally from the beginning, see the right side of Figure 5. Due to the necessary monitoring systems mentioned above (load monitoring and SHM), the Real Twin permanently transmits load data, structural conditions and environmental conditions, e.g., temperature, to the Digital Twin. The Digital Twin, in turn, can provide the individual load history, the individual product life, and, if necessary, the RUL for the Real Twin. In addition to passive feedback, active feedback in the form of load-adaptive control, etc., is also conceivable.

In addition to the data flow, the variety of entities also changes within the design and operation phase, see Figure 6. The design phase initially starts with many variants for potential solutions (conception phase). The design phase aims to consolidate these concepts through a preliminary design based on the requirements and to optimize a suitable configuration for its application. In this process, the allowable variants are further reduced until a single final design is fixed, validated and manufactured. At this moment, the Real Twin is created. Due to potential scatter during manufacturing, the potential variants have already increased again at this point. In this consideration, each manufactured Real Twin is equipped with a Digital Twin with its entry into service. In the following, the Digital Twin follows the individual product life of the structure in the operational phase. Here, the variety of entities, in the form of different product lives, fatigue levels and damage extents, will increase again. The Digital Twin thus has the requirements to record and evaluate individual service lives and to minimize the uncertainties in the operational phase. Interconnections in data exchange between the individual structures could contribute to deriving statistical evaluations.

In the next section, the developed requirements are transferred into the characteristics of the taxonomy for Digital Twins according to van der Valk et al. [6]. We evaluate the characteristics for both cases separately based on the identified division of the design and operational phases.

4. Classification of Structural Mechanics in Digital Twin Taxonomy

The collected requirements are now assigned to the taxonomy according to van der Valk et al. [6], see Table 1. In analogy with van der Valk et al. [6], the collected requirements are classified as mandatory, mutually exclusive, not relevant, optional or not discussed characteristics. The previous sections derived the fundamental differences between a Digital Twin in the design and operational phases. Therefore, we will also perform the classification separately according to the use cases. A detailed discussion will follow in the subsequent sections.

4.1. Data Collection

The meta-dimension data collection summarizes data acquisition, data sources, data synchronization and data inputs. Within the design phase, we need different information and data sets over time, as shown in Table 2. Providing the data can be automated but will probably have to be executed semi-manually in the case of qualitative inputs. We assign semi-manual as mandatory to the data acquisition, and is allowed to be fully automated. In operation, automated data collection via sensors is almost exclusively practical since changes in the operational mode must be permanently recorded to keep the Digital Twin up to date [21]. In addition, automated data collection is a requirement for taking over monitoring and predictive maintenance in operation with the Digital Twin. Therefore, we define automated data acquisition as mandatory during the operational phase.

As a data source, structural data (i.e., deformation, strain, stress) are particularly important, and are collected in conjunction with operational and environmental data. Therefore, multiple data sources will be needed in the design and operation phases. In particular, during the operation phase, it is mandatory to have at least one data source that allows monitoring of the structural state in operation. Multiple sources are thus defined as mandatory for both phases.

For synchronization, we follow the definitions of the Digital Twin by Grieves [2] and Fuller et al. [23], where the focus is on bi-directional coupling. We want to apply this to the Digital Twin of the structure as well. We thus define “with synchronization” as mandatory. Nevertheless, this requirement must be adapted in the design phase, as there is often no counterpart in the beginning. Therefore, we choose “without synchronization” as an optional character in the design phase.

Data input can consist of raw and pre-processed data. Sensor data, and thus the most significant input for structural data in operation, can be understood as raw data, and are processed in subsequent steps within the Digital Twin. The processing of raw data is therefore defined as mandatory. The input through pre-processed data, e.g., through software tools, is initially of secondary importance for structural components but can be considered as optional. On the other hand, during the design process, we work with pre-processed data, e.g., from databases, simulation programs or qualitative input from engineers. In this context, the pre-processed data input is mandatory and “raw data” are optional.

4.2. Data Handling and Distribution

The meta-dimension data handling and distribution refers to the process of collecting, organizing, storing and manipulating data to ensure security and effective utilization of the Digital Twin. Van der Valk et al. [6] refer to Data Governance, Interoperability, Interfaces, Data Links and Purpose. The first three should not be discussed explicitly in the context of the structure. Superordinate standards are necessary to unify data security, management and interfaces [25]. The Digital Twin of the structure would integrate into these higher-level standards in any case.

Analogously to the discussion about synchronization for the data link, bi-directional coupling is essential for structural monitoring in the operating phase. This defines the bi-directional data link as mandatory. Following the same argument for synchronization in the design phase, one-directional data link coupling is required here. Bi-directional linking can optionally be added to existing Real Twins.

Regarding the purpose, the possible applications of the Digital Twin are varied. In terms of structure, three main applications can be classified by section:

• Design and optimization of (lightweight) structures.
• Monitoring of structural fatigue and damage for Predictive Maintenance Strategies.
• Coupling of intervening control units to actively influence the structure utilization during operation.

All tasks have in common that they provide feedback back to the real structure. Thus, the data processing and repository is defined as mandatory with respect to the mentioned tasks. Transfer can be added optionally.

4.3. Conceptional Scope

The meta-dimension conceptual scope covers aspects of the conceptual implementation of the Digital Twins in terms of accuracy, time of creation and conceptual elements. The latter is not considered further in analogy to van der Valk et al. [6]. For the accuracy of the Digital Twin, assumed here with regard to modelling, two options arise:

• The Digital Twin of the structure is an explicit, detailed and identical representation of a structural component.
• The Digital Twin of the structure is a sufficiently accurate implicit and partial representation of the overall system.

Both options present challenges for our system. In the first case, the complexity of the overall model based on the high resolution of all phenomena needs to be revised regarding the storage and computational effort and its real-time capability. In the second case, the central challenge is to ensure sufficient accuracy and consistency of the necessary sub-models. Generally speaking, the chosen detail level contradicts a model’s abstraction. The modelling effort will increase if a virtual instance is represented in detail, i.e., more explicitly. As a rule, numerical models are more detailed models. If the model is abstracted, the behavior of the structure is captured by implicit description, for example, in the form of analytical models. It is important to note that less detailed modelling does not necessarily cause a decrease in accuracy as long as the assumptions made for model reduction are not violated. For example, an analytical model can capture the deformation of a beam or beam-like structure as accurately as an explicit high-resolution finite element (FE) simulation. The choice of a specific model is highly dependent on the application and objectives and is not considered in more detail here. Generally, the guiding principle is “as simple as possible, as complicated as necessary.” Based on this argument, we make the following statement: independent of the design or operational application, the use of partial models that represent the superordinate global behavior of the structure, e.g., deformation, is mandatory. An identical representation by more explicit models may be required, especially in the design process, and is classified as optional.

Lastly, we look at the time of creation. A Digital Twin in the design process must be usable before creating the physical component. This includes a “digital-first” creation in the design process. Further developing an existing component in a newly established process with a Digital Twin can also make physical first an option. Vice versa, the same argument can be used for the operational phase. In operation, a physical component is adapted to a prepared digital model via calibration and thus initiates the Digital Twin. It is also possible that a Digital Twin already exists in the operational phase and that older components are subsequently integrated, which makes digital first possible. A summary of all the assigned characteristics can be found in

Table 3. Overview of mandatory and optional characteristics for the design and operation phases.

	Design Phase	Operation Phase
mandatory	semi-manual data acquisition	automated data acquisition
	multiple data sources	multiple data sources
	without synchronization	with synchronization
	pre-processed data input	raw data input
	one-directional data link	bi-directional data link
	processing and repository purpose	processing and repository purpose
	partial and identical accuracy	partial accuracy
	digital first	physical first
optional	automated data acquisition
	with synchronization
	raw data input	pre-processed data input
	bi-directional data link
	transfer purpose	transfer purpose
		identical accuracy
	physical first	digital first
not discussed	Data Governance
	Interoperability
	Interface

.

5. Discussion: The Two Archetypes of Structural Digital Twins

In Section 4.1, Section 4.2 and Section 4.3, we discussed and selected appropriate characteristics for the different meta-dimensions of the taxonomy for the design and operational phases. The two phases have different requirements depending on their objectives. The comparison can be found in Table 3. Figure 7 summarizes the most important and mandatory characteristics of both archetypes. Overall, we name two archetypes for the use case of structural mechanics:

• A structure-designing Digital Twin for the design and concept phase.
• A structure-monitoring Digital Twin for the operational phase.

Both areas of application bring requirements to their Digital Twin that are, in some cases, fundamentally opposed to each other. This can be concluded by the data flow between the real and the digital component and the variant management in both phases. Both phases then form an archetype of a Digital Twin, which coincides in some parts. In implementing the structural Digital Twin, it is essential to link both types during the entry into service. Therefore, the calibration process is essential in holistically integrating the Digital Twin into the product life cycle.

The structure-designing Digital Twin for the design and concept phase emphasizes a digital-first and non-synchronized virtual instance with a mostly one-directional data link. Throughout the conception, preliminary design and design phases, the Digital Twin facilitates the active consolidation of variants through a formalized hierarchical modelling approach, aligning with the concept of Model-Based Systems Engineering (MBSE). The modelling of these structures can result in partially or globally identical models based on the requirements of the respective design steps. As the physical instance of the Digital Twin emerges during the manufacturing phase, it can be connected to its corresponding virtual instance through calibration with a structure-monitoring Digital Twin during the operational phase. The structure-monitoring Digital Twin, characterized by a physical-first approach and a synchronized, bi-directional data flow between real and virtual instances, is crucial in capturing individual product lives through operational customization, reducing uncertainties and undertaking predictive maintenance and control tasks.

Despite both archetypes’ distinct goals and features, they share common traits such as data processing interfaces and hierarchical modelling. Reusing models and data interfaces becomes valuable, emphasizing the importance of aligning chosen models with the tasks of the new operational phase. For example, calibrated, reduced models from the preliminary design phase can be utilized for real-time evaluation of sensor data during operation due to their high computational efficiency. It is essential to link both archetypes during the entry into service. Therefore, the calibration process is essential in holistically integrating the Digital Twin into the product life cycle. Addressing the identified gap, this work establishes an overarching framework and opportunity for the holistic development of Digital Twins, characterized by high efficiency and reusability. The proposed approach provides a comprehensive solution and highlights the potential for advancing the field of Digital Twins with practical applications in various product life cycle stages.

The limitations of the present research should be acknowledged to provide a comprehensive understanding of its scope and implications. Firstly, the focus of this work is explicitly on the structure, recognizing that structures rarely exist for their own sake. Admitting that interfaces with other system components require ongoing consideration is crucial. Secondly, the developed framework serves as a foundation for the design process, demanding a reconsideration of existing design methodologies and their integration with established processes. Overcoming the challenge of unifying various pre-existing isolated solutions is a significant hurdle, and it is important to note that the current framework still needs to account for diverse stakeholders in its present state.

6. Conclusions

In this paper, we characterized Digital Twins for applications in structural mechanics and developed a framework. The key contributions of this paper are:

• Collecting and clustering design and operational requirements for the Digital Twins of structures.
• Deriving two central archetypes, which have unique characteristics due to their respective life cycle phases, but can be linked by calibration after manufacturing:
  • A structure-designing Digital Twin for the design and concept phase.
  • A structure-monitoring Digital Twin for the operational phase.
• Reducing the complexity of the conceptualization of Digital Twins by providing a framework and considering the Digital Twin of a structure as a holistic system over the product life cycle.

Based on the results of this paper, we propose the following research activities for future developments:

• Holistic development of structural Digital Twins: investigate how a holistic perspective can enhance the overall implementation of Digital Twins in various applications.
• Formalization of the design process: examine the potential for formalizing the design process, incorporating methodologies such as Model-Based Systems Engineering (MBSE), and assess how a formalized approach can contribute to an increased efficiency in the development of Digital Twins.
• Reusability of design process models: investigate the reusability of design process models in the context of SHM data analysis for the seamless and effective coupling of SHM with Digital Twins.

The authors are confident that the findings presented in this paper serve as a robust foundation, and we believe that the insights gained pave the way for further advancements in the holistic development of Digital Twins in structural mechanics.