Characterizing the Digital Twin 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 Lifecycle 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. In order to account for this problem, meta-studies were carried out [3], characteristics were clustered [4], or taxonomies [5] were developed from which certain archetypes can be derived. With these generalizations, a framework of characteristics is now available, which can be shaped by various application fields and industries.

One such application field is structural mechanics. While manufacturing [6], simulation [7], human health [8] or infrastructure [9] are frequently mentioned fields of application for the Digital Twin, structural mechanics appears less often. Nevertheless, it takes place, for example, for marine and off-shore [10] or aircraft structures [11]. Aircraft structures, in particular, were a central starting point for the Digital Twin paradigm [12,13]. Specifically, the interface to the monitoring and predictive maintenance idea was already taken up at this point [14].

The product lifecycle of structures with its formalized design processes, see Wiedemann [15] or VDI 2221 [16], and the increasing switch to innovative monitoring or Structural Health Monitoring (SHM) offer the potential for further developing the Digital Twin in this field. This paper aims to determine this task for the Digital Twin of structural components. Through the methodical structuring of requirements, we intend to characterize and classify them in an existing taxonomy by van der Valk et al. [5]. In particular, we focus on the distinction between the design and operational phases and the associated challenge of realizing a holistic Digital Twin.

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 in the state of the art. Based on the state of the art, two key tasks emerge that are discussed in the further course of the paper: We derive requirements for the Digital Twin in the design (Section 3.1) and the operational phase (Section 3.2) of structures. These requirements are then merged (Section 3.3) following the taxonomy of van der Valk et al. [5]; see Section 4. We conclude the paper with a summary of the results and point out connecting factors for future research activities in the context of Digital Twin for structures. In order to understand the diversity of variants and organizational possibilities, an overview of existing definitions and taxonomies will be given next.

2. State of the Art

At the beginning, we present different definitions of the 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 the Digital Twin, see Section 2.2.

2.1. Digital Twin Definitions and Categories

As mentioned earlier, the concept of the Digital Twin goes back to a presentation in 2002 held by Michael Grieves at the University of Michigan. The presentation slides, shown in the context of establishing a center for Product Life cycle Management (PLM), initially called the concept "Conceptual Ideal for PLM". Although the concept was not named Digital Twin at that time, it already contained the three central building blocks to define the Digital Twin: A physical instance, a virtual instance, and 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 following definitions for Digital Twins [17,18]. Fuller et al. [17] distinguish the terms “Digital Model” and “Digital Shadow” from the term Digital Twin based on the degree of coupling. The model describes a digital version of a planned or existing component, which coexists without coupling to an existing concrete component. If the information flows from the component to the established model, the model will become a digital shadow. However, the Digital Shadow does not provide a 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 since the effect of the decision regarding the real components is always observed.

In addition to the coupling level, other aspects and perspectives have also shaped the definition of the Digital Twin. In the context of simulation technology [7] and Internet of Things [19] applications, the focus is particularly on interconnected, holistic modeling. Glaessgen and Stargel [12] 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 [20,21,22] also share the idea of Digital Twins as holistic simulation models that reveal all functional properties of a physical system. Roßmann and Schluse [23] 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 overpowered for many applications due to their complexity.

Another industry that shapes the definitions for the Digital Twin is production engineering and manufacturing [6]. Here, the focus lies in particular on the accuracy of mapping a specific process, enabling all information to be recorded and displayed at any time [24,25]. 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" [24]. 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 thus 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 is required. This was done by various reviews [3,4,26]. Jones et al. [3] reviewed 92 publications to derive 13 characteristics of the concept of Digital Twin. Enders and Hoßbach [27] analyse 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 (CPS), Josifovska et al. [28] develop a reference framework and specify main building blocks of a Digital Twin in terms of structure and interrelations. All these approaches allow categorizing and structuring of the most diverse Digital Twin approaches and applications. Van der Valk et al. [5] generalize this approach further. Their aim is the derivation of an independent taxonomy as presented in Table 1. Based on this taxonomy, five archetypes of Digital Twins are presented, supported by literature reviews and interviews with various industry experts.

In the shown state of the art, several definitions of the Digital Twin were presented and compared. Although the definitions 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. [5]. Based on such fundamentals, application-specific generic archetypes can now be formed, which exhibit relevant characteristics. This will be done in the further course for the use case of structural mechanics and lightweight construction. Due to the very detailed preliminary work in developing a generalized taxonomy for Digital Twins by van der Valk et al. [5] this paper aims to classify the Digital Twin for structures based on this selected taxonomy.

2.2. Structural design process

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

2.2.1. Definition of a structure according to Wiedemann

Wiedemann [15] 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 thinking 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 [15] 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, that of a truss of 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[16], 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 target 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 [16] 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. Connection to software development tools such as the UML language is made at various points, as a necessary step to formalize the design process of the structure.

2.2.3. Summary for structural design process

Wiedemann [15] bases his 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 center of the design process. Consequently, the process is subjected to the logic of the construction methodology. The points mentioned contradict 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 [16] 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 to provide 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 the structure’s Digital Twin, we orient us broadly on the general product life cycle (PLC) and divide our analysis into the design, the manufacturing and the operational phase of a structure, see Figure 2. 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 in the design phase

To describe the levels of a structural system, first the following definitions are introduced: A “subsystem” 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 of 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 [16] to the structural design process. For this purpose, three development phases are defined: In the Conception phase, 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 shape-optimized and dimensioned. In the next step, we propose the following sequence of activities according to VDI 2221 [16] 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 shows the information, the associated data sets defined in the individual phases, and the resulting requirements for a Digital Twin within such a structure design process. 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 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.
• Modeling approaches with increasing levels of detail depending on the design phase organized in hierarchical modeling
• 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 structure 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 in the operational phase

The design phase described here ends in 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 of multiple instances, see Figure 3. The design phase quantifies all structure properties with definite target values. They represent our expected design values after manufacturing the structure (${\mu }_{Design}$). However, in manufacturing these properties scatter around this expected design value. The properties of the real instance thus may not correspond to the virtual instance, the Digital Twin from the design phase, but 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 [29].

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

Figure 4 visualizes the potential degradation of a structural property, e.g. stiffness $EI$, based on the shift of the expected value ${\mu }_{1,0}$ from the original calibration to worse values at later time points (${\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, independent of the degradation, the uncertainty in predicting the actual properties increases, due to an increase of made assumptions, e.g. regarding the experienced loads. This higher uncertainty regarding the actual structural state means that the connection between the real and the Digital Twins will decrease more and more 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 [29]. 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 modeling depth is always a good idea. 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, are required. If we summarize the points mentioned above, the central requirements for the Digital Twin of the structure in operation will result in the following:

• Providing a synchronization mechanism, in form of continues re-calibration, between real component and model
• Automated data acquisition, processing and evaluation of an SHM system of the structure
• Data merging and storage from multiple data sources including the SHM system, environmental influences, and operational data
• Provision and hierarchical coupling of suitable structural mechanical models (implicit and explicit)
• Feedback loop to enabling bi-directional coupling: For individual evaluation of the structure concerning inspections like maintenance on demand or Remaining Useful Life (RUL) [30]

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 into a holistic system, further requirements arise, for example with regard to compatible interfaces or the networking of all recorded data.

3.3. Merging design and operation phase

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 in the operating phase. In this section, we will discuss the merging of both phases.

First, we look at the data flow in the two phases. In the design phase, the real twin usually does not yet exist. It is initially defined by its requirements, recorded in the specification sheet, and the anticipated operating environment. These information are 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 are 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 Figure 5 left side. Once the real twin is created, possibilities for further iteration steps through continuous enhancements for future design generation arise.

In contrast, in the operational phase, real and Digital Twins exist in parallel. The data exchange is therefore characterized bidirectionally from the beginning, see Figure 5 right side. Due to the necessary monitoring systems mentioned above (load monitoring & 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 change 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 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 put into manufacturing. At this moment, the real twin is created. Due to potential scatter in the manufacturing, the potential variants at this point have already increased again. In this consideration, each manufactured real twin is equipped with a Digital Twin with its entry into service. In the following, the Digital Twin accompanies the individual product life of the structure in the operational phase. Here, the variety of entities, in the form of different product life, fatigue and damages will increase again. The Digital Twin thus has the requirements to record and evaluate individual service life and to minimize the uncertainties in the operational phase. Interconnection 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. [5]. We evaluate the characteristics for both cases separately based on the identified division of design and operational phase.

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. [5]; see Table 1. In analogy to van der Valk et al. [5] the characteristics are classified as mandatory, mutually exclusive, not relevant, optional or not discussed. The previous sections derived the fundamental differences between a Digital Twin in the design and operational phase. Therefore, we will also make the classification separately according to the use cases. A detailed discussion will follow in the next sections.

4.1. Data Collection

The meta-dimension Data Collection summarizes data acquisition, data source, synchronization, and data input. 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 done semi-manually in the case of qualitative input. We assign semi-manual as mandatory to the data acquisition, which optionally allows 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 [29]. In addition, this 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) becomes particularly important, which is collected in conjunction with operational and environmental data. Therefore, multiple data sources will be needed in the design and operation phases. Particularly, in the operation phase, it is mandatory to have at least one data source that allows monitoring of the structural state in operation. Multiple Sources is thus defined as mandatory and for both phases.

For synchronization, we follow the definitions of the Digital Twin by Grieves [2] and Fuller et al. [17], whereas 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 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, which is 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 optionally. On the other hand, in 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 optional.

4.2. Data Handling and Distribution

The meta-dimension Data Handling and Distribution summarizes all the characteristics for data linking of the Digital Twin. Van der Valk et al. [5] name Data Governance, Interoperability, Interface, Data Link, and Purpose. The first three mentioned should not be discussed explicitly in the context of the structure. Superordinate standards are necessary to unify data security, management, and interfaces [19]. The Digital Twin of the structure would integrate into those higher-level standards in any case.

Analogous as discussed in 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 argumentation of synchronization for the design phase, a one-directional data link coupling is required here. Bi-directional linking can optionally be added to existing real twins.

Regarding the purpose, possible applications of the Digital Twin are versatile. 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 is optional to be added.

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.[5]. For the accuracy of the Digital Twin, assumed here with regard to modeling, 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 submodels. Generally speaking, the chosen detail level contradicts a model’s abstraction. The modeling effort will increase if a virtual instance is represented in detail, i.e., more explicitly. As a rule, more detailed models are numerical 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 modeling does not have to mean that accuracy decreases 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. Based on this argumentation, we make the following statements: Independent of the design or operational application, the use of partial models that represent the superordinate global behavior of the structure, e.g., deformation, are 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 digital-first 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 argumentation 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 a digital-first possible. An overview of all the assigned characteristics can be found in Table 3.

5. Discussion: The two archetypes of Structural Digital Twins

In Section 4.1 to Section 4.3, we discussed and selected the appropriate characteristics for the different meta-dimensions of the taxonomy for the design and operational phases. The two phases have different requirements depending on the dimensions. The comparison can be found in Table 3. Figure 7 summarizes the most important, mandatory characteristics of both archetypes. Overall, we use the argumentation to 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 in 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.

6. Conclusions

In this paper, we characterize the Digital Twin for application in structural mechanics. Based on the presented state of the art for the definition and existing classification possibilities for Digital Twins, we chose the taxonomy by van der Valk et al. [5]. We weighted the characteristics from the perspective of structures. We focused on the design and the operational phase of structures for collecting the requirements. This way, two archetypes of Digital Twins for structures could be defined. These archetypes now provide a framework for implementing the Digital Twin for structural applications.

A formalized description of structures that allow a digital design needs to be implemented in the design process. Here there are many interfaces to the well known Model-Based Systems Engineering. Implementing the Digital Twin in operation or the application of smart sensing systems, there is great potential for further development of various SHM approaches concerning the collected requirements for Digital Twin, including the provision of suitable modeling approaches for the structure in the ongoing process.