1. Introduction
Digital Twins (DTs) offer transformative potential by providing valuable data and insights throughout the entire product lifecycle, enhancing transparency and collaboration among stakeholders. This information can, for example, enhance product development and design. However, engineers face significant challenges in their development, implementation, and utilization. One primary issue lies in the lack of structured, systematic methodologies for DT design, stemming from a heterogeneous understanding of DTs and their development both across industry and research. This heterogeneity is further amplified by the wide variety of DT applications, which differ in their functions, capabilities, contexts and, consequently, their complexity. As a result, the models, data, and twinning mechanisms incorporated in DTs vary widely depending on the specific application. Due to this variability, engineers often struggle with determining the appropriate depth of integration between DT components.
To support engineers in designing and developing DTs effectively, a systematic description characterizing DTs based on their twinning complexity is essential. This can serve as a foundation for general, universal DT design methodologies, independent of specific use cases. By categorizing a DT into a distinct level of twinning complexity, engineers can better estimate the required development scope for DT implementation and select appropriate strategies tailored to specific product and DT needs. Without such a categorization, engineers risk either under-engineering or over-engineering their DT implementations, leading to inefficiencies in cost, performance, or scalability.
This paper proposes a systematic description of six twinning levels, ranging from simple data exchange using generic models to more complex forms targeting optimization of models and DT operation. It combines engineering and mathematical descriptions to characterize DTs by their models, data, and their twinning. The mathematical perspective provides an abstract and versatile description independent of application scenarios, while the engineering perspective provides a technical, functional view useful for integration into DT development processes. By bridging both perspectives, this approach enhances not only theoretical understanding but also practical applicability. It enhances the understanding of DTs by providing a clearer comprehension of DT twinning mechanisms and offering guidance for selecting appropriate twinning levels to meet specific requirements of the product, DT, and use case during DT development.
2. State of the art
The development and deployment of DTs is a multifaceted process that integrates diverse technologies and methodologies. DTs are digital representations of products or product-service systems comprising a Digital Master (DM) (or Digital Prototype (DP) and a Digital Shadow (DS). The DM consists of product description models; the DS encompasses data collected throughout the product’s life cycle. The DP relates to simulation models that are used to represent additional aspects of the system as well as its interactions with additional external systems or environments, for example, additional load cases or product and system functions. To create a DT, the DS must be linked to the DM/DP (Stark & Damerau, Reference Stark, Damerau, Chatti and Tolio2019; Stark et al., Reference Stark, Kind and Neumeyer2017; Stark, et al., Reference Stark, Thoben, Gerhard, Hick, Kirchner, Anderl and Göckel2020), enabling dynamic information flow via the twinning engine (Reference StarkStark, 2022). However, existing research lacks a systematic approach to differentiate between these twinning mechanisms, making it challenging to establish clear development pathways for various DT applications.
The implementation and utilization of DTs have become prominent research areas. There exist abstract methodologies applicable to various use cases. However, such methodologies often lack detailed guidance on how to execute each step, thereby providing limited methodological guidance for practical application. They also frequently lack granularity in other aspects such as the differentiation between models and data, and their connections (Ariansyah, et al., Reference Ariansyah, del Amo, Erkoyuncu, Agha, Bulka, De La Puante and Penver2020; Psarommatis & May, Reference Psarommatis and May2023; Tao, et al., Reference Tao, Sui, Liu, Qi, Zhang, Song and Nee2019). Furthermore, relevant standards and guidelines such as DIN EN ISO 11354 (International Organization for Standardization, 2011) and VDI/VDE 2206 (Verein Deutscher Ingenieure, 2021) are broad in scope and, despite their potential to ensure consistency and interoperability, do not adequately address the unique challenges of developing and deploying DTs across diverse industrial sectors. In addition, more targeted approaches to DT development exist. For example, Oulefki et al. Reference Oulefki, Amira, Kurugollu and Alshoweky(2023) present a structured development process that refers to specific tools and models tailored for creating DTs of buildings. Another example of such targeted approaches was developed by Florescu Reference Florescu(2024), which describes the development of a DT of a specific experimental Flexible Manufacturing System. While useful for their respective niche, the frameworks’ applicability to broader industrial use cases is limited. Frameworks and models that systematize the characteristics of DTs have the potential to effectively bridge the gap between abstract methodologies and use case-specific approaches. A variety of such frameworks and models exist (Reference Kim, Yoo, Lee, Kim and HanKim et al., 2020). Stark et al. Reference Stark, Damerau, Chatti and Tolio(2019) present a model of eight dimensions of DTs which was later extended by Stark and Schulte Reference Stark and Schulte(2021). This model accounts for critical factors such as update frequency and simulation capability. Furthermore, Stark et al. Reference Stark, Damerau, Chatti and Tolio(2019) identified a set of six critical design elements. Another notable approach to systematize characteristics of DTs is the periodic table on DT capabilities, which includes 61 capabilities that can be allocated to data services, integration, intelligence, UX, management, and trustworthiness (Digital Twin Consortium, n.d.). Furthermore, DT capabilities are often classified by the intelligence of the system, including the levels “describe”, “predict”, “prescribe”, and “actualize” (Reference Walton, Ciarallo and ChampagneWalton et al., 2024).
Additionally, approaches to mathematically describe DTs exist. A notable example is presented by Kapteyn et al. Reference Kapteyn, Pretorius and Willcox(2021) with subsequent publications building on this approach (Reference Kapteyn and Willcoxe.g., Kapteyn & Willcox, 2022). The authors introduce an abstraction of DTs, and their physical assets based on key quantities, utilizing probabilistic graphical models to enable scalability and updating. However, limitations of the presented abstraction include ensuring the generalizability of the model across diverse applications.
Despite these advancements, the field remains fragmented with limited consensus on methodologies that address the diverse requirements of DTs across industries. This lack of a standardized approach hinders consistency and scalability across different DT implementations, leading to challenges in their efficient development and deployment. This highlights the need for more comprehensive frameworks that integrate theoretical insights with practical considerations, facilitating scalable and efficient DT development and deployment while optimizing design trade-offs between benefits and costs for specific use cases. Therefore, we propose a systematic description of twinning levels between key DT components to support effective DT development and deployment. This framework considers the varying intelligence and capabilities of DTs, from basic data visualization to advanced systems capable of optimization. By clearly differentiating twinning levels, it offers a practical guide for tailoring DT implementations to specific application needs and requirements. This approach is particularly relevant in the early stages of the V-model (Verein Deutscher Ingenieure, 2021), where requirements and system architecture are planned.
3. Systematic description of twinning levels
The components of a DT - namely the DM, the DS, and their twinning - can vary in complexity and analytical capabilities. To address the requirements of a specific use case with the DT design, it is essential to identify the appropriate level of interaction between the DS and DM and thus the complexity of the twinning during DT development. “Twinning” refers to the degree and nature of the interaction between the DM/DP and DS. We propose the differentiation of six twinning levels between the DM/DP and the DS, supporting a structured and scalable approach to DT design and implementation. Depending on the level, a differentiation between a generic or instance specific DM/DP is made. Different DSs are defined depending on whether the data is unprocessed, processed, or generated synthetically. This paper focuses on individual DTs; the concept of interconnected or aggregated DTs (e.g., for product classes), however, is not addressed in the current scope. For the description of these twinning levels, the following assumptions are made:
1. Each component of the DM and DP can be represented by a function.
2. Each function is characterized by variables, parameters, and constants.
3. The functions of the DP do not necessarily coincide, intersect, or relate to the functions, properties, and characteristics contained in the DM. The DP typically depends on less or specifically derived parameters as some of the functions, properties, and characteristics have been substituted by knowledge extracted from the generic load cases associated to a DM. Some functions, properties, and characteristics need specialization or precision due to the simulation model associated to the DP.
4. Both the DM and the DS can exist in either an uninstantiated or instantiated form.
The twinning levels can be grouped into (i) monitoring of behavior (level 0 and 1), (ii) planned adaptation of behavior (level 2 and 3), and (iii) independent optimization of behavior (level 4 and 5) in order to take into account, the increasing complexity of the connection between the DM/DP and DS. In the following, each twinning level is described from both an engineering and a mathematical perspective. Additionally, a practical example of a DT of a valve is used to further illustrate the individual levels. Each of the following sections describes a level based on its key elements (DM/DP, DS, and twinning).
3.1. Monitoring of behavior
The first two twinning levels characterize DTs that are used to detect, record, or monitor specific product or system behavior. All models are assumed to be static and are not modified over time. Also, they are generic and not specific to an instance. Figure 3 provides an overview of twinning levels 0 and 1.
Level 0 - detached
The detached level can be used to record, analyze, and visualize raw product data without advanced processing or interaction with a DM.
Digital Shadow: At level 0, a DS exists that comprises measured data from the real object, which may be derived from either a single specific object or multiple instances. No data processing or analytics are performed on this data, i.e., the DS remains unprocessed (preDS). Mathematically, the DS is described by a collection of n-tuples of the form (q 1,i , …, q n,i ) for i = 1, …, d.
Digital Master and Digital Prototype: A generic DM (genDM) exists consisting of models pertaining to the product or system. Additionally, a related generic DP (genDP) can exist. The models are initialized from the model repository, which includes all product description models. Mathematically, a genDM/genDP can be considered as a subset of functions fi
:
${\cal Z}_i \to {\cal Y}_i $
from the model repository. They vary from general descriptions by a partial differential equation over computer aided design (CAD), e.g., a function mapping a set of three-dimensional coordinates to a 3D model for visual illustration, and finite element (FE) models to simplified ordinary or algebraic equations as well as data-driven models generated by artificial neural networks/machine learning. These models include parameters and constants that are unknown/unspecified. From an abstract point of view, each model i can be seen as a function fi
:
${\cal Z}_i \to {\cal Y}_i $
, which maps an argument from
${\cal Z}$
to a value from
${\cal Y}_i $
. Here, a generic argument
${\cal Z}_i $
∋ z may itself consist of variables x
j
1
, constants c
j
2
, or (model/operation) parameters p
j
3
, p
M,j
4
,p
O,j
5
, i.e., z = (x
1, …, x
m
1
, c
1, …, c
m
2
, p
1, …, p
m
3
, p
M,1, …, p
M,m
4
, p
O,1, …, p
O,m
5
). The output values can be categorized into explicit measurable and implicit computable values. Figure 1 shows a visual representation of the genDM or genDP comprising functions, parameters, and outputs.
Figure 1. Schema depicting a model repository comprising different models and a preprocessed Digital Shadow in level 0
Twinning: There is no twinning between a DS and a DM/DP at this level. Therefore, no DT exists.
Example: In the example of a valve, the preDS is used for a dashboard displaying timeline data of valve openings and closings. The data consists of data series in the form of tuples (t 1, v 1), …, (td , vd ) where ti ∈ R >0 represents time points and vi ∈ {0,1} describes the valve state (open vs closed).
Level 1 - generic
At the generic level, a DT is created which enables basic simulation, monitoring, and data analysis, providing generalized insights about product behavior, without requiring instance-specific data.
Digital Shadow: At level 1, a preDS exists, same as at level 0. However, at this level, a postprocessed DS (postDS) is also created through processing steps - such as data cleaning, sorting, and clustering - which can represent data from either a single object or multiple objects. Tuples (q 1,i , …, q n,i ) collected at level 0 might be sorted by regrouping the data into tuples of smaller size, e.g., (q 1,i ,q 3,i , …, qn,i ) and (q 2,i , q 4,i , …, q n−1,i ). Alternatively, tuples can be rearranged into vectors (q 1,1 … q 1,d )⊤, …, (q n,1 … qn,d )⊤ or matrices. A first data analysis can be performed, for example by statistical reduction and compression techniques such as singular value decompositions or principal component analysis.
Digital Master and Digital Prototype: The DM and DP at this level are the same as at level 0.
Twinning: Twinning at this level is created between the postDS and genDM or between postDS and genDP, thereby creating a DT. No instance-related twinning is done at this level, meaning not every variable, parameter, or constant in the genDM/genDP has a corresponding equivalent in the postDS. The processed tuples of the postDS (q
1,i
, …, qn,i
) can be linked to the genDM/genDP by individual grouping of each qk,i
into either the set of arguments
${\cal Z}_\ell $
or into the set of values
${\cal Y}_\ell $
.
Example: In the example of a valve, the DT at this level includes the opening and closing timeline linked to a generic FEM model of the valve. A function f:
${\cal Z} \to {\cal Y}$
can be defined as a mapping from discrete time instances (e.g., the points available in the timeline) to the visualization of principal stresses. In other words, the input space is
${\cal Z}$
= {t
1, …, td
} and the output space
${\cal Y}$
is a set of 3D pictures of the valve (e.g., open and closed). Alternatively, a continuous input space can be used, e.g.,
${\cal Z}$
= R
>0, allowing to evaluate the mapping between two data points ti
,t
i+1. This would, however, require some form of interpolation of the values given by f(ti
), f(t
i+1) which also includes a valve that is in the process of opening or closing, respectively. A schema depicting the twinning is illustrated in Figure 2.
Figure 2. Schema representing a generic digital master/prototype and a postprocessed digital shadow as introduced in level 1
Figure 3 visualizes the arrangement of the DT elements at twinning levels 0 and 1.
Figure 3. Overview of twinning levels 0 and 1 describing digital twins used for behavior monitoring
3.2. Planned adaptation of behavior
The twinning levels 2 and 3 aim to describe the twinning structure needed to plan and adapt the behavior of the product or system by introducing an instantiation mechanism and synthetic data generation.
Level 2 - instance
At the instance level, the DT is enhanced with instance-specific data and models, allowing for a more precise representation of the actual product or system, including its unique conditions, loads, and state.
Digital Shadow: The DS at level 2 is identical to level 1 but now incorporates instance-specific information in the preDS and postDS. Instance-specific constants and parameters (e.g., geometries, material constants) extend the existing data tuples contained in the postDS.
Digital Master and Digital Prototype: At this level, the DM is instantiated (instDM) by aligning the parameters and constants of the generic model with the specific product instance; thereby, the instDM consists of a reduced argument set of the DM. An instantiated DP (instDP) can exist. For example, tolerances included in the model are replaced with as-built measurements. Mathematically, the instantiation of the DM/DP replaces remaining generic constants c
j
2
and unknown parameters by instance-specific values. As a result, the set of arguments
${\cal Z}_i $
of the individual functions
${\cal Z}_i $
is reduced to a set of arguments 
comprised of elements of the form 
= (x
1, …, x
m
1
, p
M,1, …, p
M,m
2
, p
O,1, …, p
O,m
3
). A visualization of the differences between a genDM and an instDM or a genDP and an instDP is provided in Figure 4.
Figure 4. Schema representing the differences between a generic digital master/prototype and an instantiated digital master/prototype as introduced in level 2
Twinning: At this level, the postDS and instDM or the postDS and instDP are connected, meaning that each variable, parameter, or constant in the instDM/instDP has an equivalent counterpart in the postDS. The instance-specific models are executed in reaction to the processed data of the postDS, which provides a continuous set of variables for the analysis. This twinning can operate in real-time, at set time intervals, or on an event-based basis, as needed. The extension of the data tuples (q
1,i
, …, qn,i
) from levels 0 and 1 now yields enlarged data tuples
$(\overline {q_{1,l} } , \ldots ,\overline {q_{n,l} } )$
which are consistent with elements (y
1,i
, …, yn,i
) from the argument set
${\cal Y}_i $
. The instance-specific functions fi
: 
allow for simulation in reaction to the data collected in the postDS.
Example: In the example of a valve, the opening and closing timeline are linked to an instantiated CAD and FEM model of the valve as well as to a specific 1D model of the flow inside the valve which are instantiated to match the exact valve, representing the aging component. In this context, the functions fi
: 
can be understood as mappings of the real geometry and materials to the CFD model or the valve openings and closings over time to its outflow (via the solution of the FEM, control, or CFD model).
Level 3 - extended
At the extended level, the DT incorporates synthetic data generation. This data provides deeper insights into the system’s interactions within its context and enables the simulation of scenarios and prediction of behaviors under varying conditions, thereby enhancing proactive decision-making and risk analysis.
Digital Shadow: In addition to the preDS and postDS from level 2, synthetic data sets are generated based on virtual scenarios depicted by instDPs. Simulations based on the instance-specific functions of the instDP fi
:
${{ {{{\cal Z \vskip-2pt\!\widetilde}}_l } \to {\cal Y}_i $
can be used to generate additional data tuples (y
1,i
, …, yn,i
) for possible enrichment of the available tuples
$(\overline {q_{1,l} } , \ldots ,\overline {q_{{\text{n,1}}} } )$
. The sum of all synthetic data sets is referred to as the synthetic DS (synDS). Additionally, comparisons between (y
1,i
, …, yn,i
) and
$(\overline {q_{1,l} } , \ldots ,\overline {q_{n,1} } )$
can be drawn in order to assess the prediction and simulation quality of both the instDP and instDM but also the measurement quality of the data in the postDS.
Digital Master and Digital Prototype: The DM and DP at this level remain the same as in level 2.
Twinning: As in level 2, the postDS and instDM/instDP are interlinked, meaning each variable, parameter, or constant in the instDM/instDP has an equivalent in the postDS.
Example: A synthetic scenario describing possible pressure peaks in the valve system is generated based on variations of the CFD model from the instDP. The synthetic scenario is compared and evaluated based on postDS data, allowing for analysis of projected versus actual pressure values. Mathematically, such a synthetic scenario is generated by varying the variables x
j
1
from the argument set of the instance-specific functions fi
: 
and evaluating the mappings fi
. The resulting values (y
1,i
, …, yn,i
) can be compared with
$(\overline {q_{1,l} } , \ldots ,\overline {q_{n,l} } )$
by means of individual metrics that allow to measure the “closeness” of these data sets, e.g., by computing 
for an appropriate norm ‖·‖.
Figure 5 shows the generation of a synthetic scenario summarized as the synDS based on the variation of a CFD model as well as control behavior model in the instDP.
Figure 5. Shema representing the synthetic digital shadow and its generation based on a variation of an instantiated digital prototype
A visual representation summarizing the interdependencies of the newly introduced DT elements in the form of instDM, instDP, and synDS at twinning levels 3 and 4 is provided in Figure 6.
Figure 6. Overview of twinning levels 2 and 3 describing digital twins used for planned behavior adaptation
3.3. Optimization of behavior
The twinning levels 4 and 5 include the active optimization of models and operation of the DT to enable increasingly automatic, even autonomous, properties.
Level 4 - model-optimized
At the model-optimized level, the DT evolves by optimizing model parameters, continuously enhancing simulation accuracy and currency, and predictive capabilities of the DT based on dynamic data from the real-world. The update frequency adjusts to system degradation or changes in operational conditions.
Digital Shadow: The DS at this level remains the same as in level 3.
Digital Master and Digital Prototype: At level 4, the instDM/instDP is optimized by adapting model parameters. The optimization problem requires a suitable cost functional
${\cal J}_{{\text{misfit}}} $
, which generally depends on the set of model parameters pM, j
and comprises individual simulation versus measurement data misfit terms which should be minimized. A typical optimization problem could be of the form:
where
${\cal P}_{{\text{ad}}} $
denotes a set of admissible parameters, considering that not all parameter values may be realizable in practice (e.g. due to physical constraints such as maximal geometries, pressure bounds, energy limitations). The goal of this minimization is to find model parameters which reduce deviations between the instDM/instDP on the one side and the postDS on the other side.
Twinning: At this level, the postDS and instDM or the postDS and instDP are interlinked, same as in level 3; however, this twinning is continuously refined by the aforementioned model parameter optimization. In particular, the model parameters pM,j are now implicitly linked to the postDS via the optimization problem.
Example: Over time, model parameters (such as the number of CFD elements, material properties, and friction coefficients) are continuously adapted to better align with the real valve characteristics recorded in the preDS. This ensures that the models accurately reflect the valve’s current performance and wear state, supporting predictive maintenance. A neuronal network used to predict the future wear and tear of the valve could be retrained using DS data to better match the real valve.
Level 5 - operation-optimized
At the operation-optimized level, the DT is optimized to reflect the system’s changing behavior (as in level 4), as well as proactively optimized to enhance system operations. The aim is to maximize overall DT objectives, such as minimizing costs, maximizing profit, and extending longevity through continuous operational adjustments. The optimized operation parameters correspond directly or indirectly to sets of actuator, control, or state values that influence system behavior.
Digital Shadow: The DS at this level remains the same as in level 3 and level 4.
Digital Master and Digital Prototype: For the (changeable) operation parameters pO,j
of the instDM/instDP, a second (or multiple further) cost functional
${\cal J}_{{\text{DTgoal}}} $
is defined. Typically,
${\cal J}_{{\text{DTgoal}}} $
comprises of different, generally concurrent, sub cost functionals which themselves model costs, profit, or product longevity. For example, one may consider a minimization of a functional
${\cal J}_{{\text{DTgoal}}} = {\cal J}_{{\text{costs}}} - {\cal J}_{{\text{profit}}} - {\cal J}_{{\text{longevity}}} $
. Since the optimization of the operation parameters pO,j
will generally result in a change of the model functions contained in the instDM/instDP, it is crucial that this will not cause undesirable diminishment of their prediction and simulation capabilities. Hence, these operation parameter optimizations should typically either go hand in hand with a subsequent model parameter adaptation/audit or directly be conducted via a suitable bilevel optimization problem of the abstract form
where the first minimization ensures optimization of the overall DT objects, while the second minimization guarantees the DT to still accurately reflect the underlying measurements and processes.
Twinning: At this level, the twinning between the postDS and instDM/instDP is tailored through both model parameter optimization and operation parameter optimization. Figure 7 shows a visual representation.
Figure 7. Schema depicting the relationship between digital twin goal optimization and model parameter optimization as introduced in level 5
Example: The model parameters, such as numbers of elements, are continuously adapted to match the real valve characteristics. In addition, the behavior of the valve is continuously updated during operation to maximize the remaining lifespan.
Figure 8 summarizes all DT elements and their arrangement into the proposed six twinning levels.
Figure 8. Summary of all Digital Twin elements of the six twinning levels
4. Discussion and Outlook
The presented systematic description of twinning levels helps to address the challenges outlined in the state of the art, including the lack of detailed methodological guidance and the limited applicability of existing development processes to diverse contexts. The description provides guidance for the understanding and development of DTs at varying levels of complexity and integration, thereby making it easier to tailor DT implementations to specific needs. Additionally, the described twinning levels provide a scalable and adaptable framework that accommodates the unique requirements of different industries, ensuring that the model is both comprehensive and versatile.
The proposed characterization of twinning levels is based on the assumption that any and all models can be represented as a function mapping specific parameter sets to output values. While this enables the consideration of both deterministic and probabilistic functions, not all models might fit this criterion. Especially engineering models that are often defined for a specific use case during the development process of products or systems might not be suited to be reused, repurposed, or even executed in the context of a DT. Metamodels putting into relations different, possibly unquantifiable or inexecutable aspects of a product or system (such as requirements or technical drawings) might not fit the proposed framework but could still generate great insights in the context of DTs at levels 0 and 1, aiming to generate insights about unknown correlations. Estimating the usefulness, aptitude, and compatibility of models and data remains particularly challenging and is highly dependent on the specific application.
Another limitation of the presented systematic description is that mechanisms for aggregating multiple DTs into cohesive systems are not yet included. Aggregating the data in the form of multiple DSs generated by multiple different instances of one identical product or system could lead to deeper insights but would require additional aggregation, analysis, and twinning mechanisms. In addition, data sharing across different DTs of different systems might also require further investigation. In complex environments (such as manufacturing plants) multiple DTs must interact and synchronize. While the current framework provides a solid foundation for individual DTs, extending it to environments with interconnected DTs could unlock new opportunities. Future research should address data harmonization, state synchronization, and interdependency management to enable seamless integration of multiple DTs. Therefore, applying the systematic description to DT networks is a promising direction. Interconnected DTs introduce challenges like ensuring interoperability, managing communication latency, and coordinating decisions across distributed nodes. Addressing these will enhance the scalability and applicability of DTs to large-scale ecosystems like smart cities or industrial networks. By addressing these areas, the framework can help to support complex real-world applications, advancing its theoretical foundation and practical utility across diverse industries.
5. Summary
This paper presents a systematic description of six twinning levels. The differentiation of twinning levels based on the complexity of the connected DM/DP and DS and thus their linkage enhances the understanding of DTs. Therefore, this approach provides guidance for DT development at varying levels of complexity and integration of the DM/DP and DS and thereby effectively bridges the gap between abstract methodologies and practical application. It provides a structured way to approach DT design, ensuring engineers can make informed decisions at each step of development. However, the underlying assumptions introduce certain limitations. Future research should focus on refining aggregation mechanisms for multiple DTs and extending the framework to DT networks. These advancements will further enhance the systematic description’s utility in complex and dynamic application domains.
Open access
