How to Leverage Digital Twin for System Design?

Jean-S

ebastien Sottet

1 a

, Pierre Brimont

1 b

, Cedric Pruski

1 c

and Faima Abbasi

1,2 d

Luxembourg Institute of Science and Technology, Esch-sur-Alzette, Luxembourg

University of Luxembourg, Luxembourg

{ﬁrstname.lastname}@list.lu

Keywords:

Model Driven Engineering, Digital Twins, System Design and Operation.

Abstract:

Digital Twins (DT) are deeply rooted in digital simulation environments. Today, they are still considered data-

driven constructs aimed at supporting simulation, optimization, prediction on a physical system. However,

data alone may not completely describe a system. This necessitates additional knowledge, encapsulated within

models, which forms the foundation of the Model-Driven Digital Twins (MDDT) paradigm. At the start of a

DT life-cycle, or when dealing with a system under construction, models becomes the primary artifact enabling

the DT due to the lack of available data. This paper explores the advantages of simultaneously engaging in

model-driven system design while preparing its corresponding DT. Using a real-world case study focused on

developing a hydrogen valley, we demonstrate the substantial beneﬁts of integrating models at the earliest

stages of the DT’s design and implementation process. This covers preparing data collection and sensors, and

incorporating human knowledge throughout the system lifecycle, enhancing replicability.

1 INTRODUCTION

The term Digital Twin (DT) ﬁrst emerged from the

manufacturing industry in the early 2000 as a digi-

tal replicate (i.e., a twin) of a production line or a

product. If the notions behind Digital Twin are an-

chored in the early digital simulation environments,

it has only been recently formalized by the original

claimed authors of the DT deﬁnition (Grieves and

Vickers, 2017). DT aims at supporting any simula-

tion (Boschert and Rosen, 2016; Zhang et al., 2022) or

prospective scenario, such as predictive maintenance

(Liu et al., 2018; Feng et al., 2023), in a digital world.

According to (Grieves and Vickers, 2017), a DT is

composed of three major elements: (i) a physical en-

tity of the real world, (ii) its counterpart in the vir-

tual world (the twin) and (iii) a bidirectional data ex-

change connecting those two worlds. In practice, it is

hard to achieve this pure bidirectional exchange, and

most of the advanced works only consider the real-

ization of a digital shadow. A digital shadow (Becker

et al., 2021) is a digital replica of the physical sys-

tem with few or even no possible feedback actions

on the physical system. Ideally, DTs aim at being

https://orcid.org/0000-0002-3071-6371

https://orcid.org/0000-0002-0730-7190

https://orcid.org/0000-0002-2103-0431

https://orcid.org/0009-0001-7484-9256

the exact replica of the physical entity: each action

on the physical system is reproduced on the DT. In

practice, DTs serve as close approximations of real-

ity (Abdoune et al., 2021), as they are often limited

by an incomplete understanding of the system and its

context, unforeseen changes, or the absence of high-

quality data, among other factors.

Digital Twins are often perceived as entities built

exclusively from data, predominantly sourced from

sensors. This data, consisting of various measure-

ments taken from the physical system, is aggre-

gated to form the DT, as discussed in works such as

(Friederich et al., 2022). Consequently, most exist-

ing technological infrastructures, including platforms

like FiWare (Foundation, ) and Azur DT (Microsoft,

2022), are designed with a strong emphasis on sensors

and data management. Those are complemented with

machine-learning models for representing the behav-

ior of the system itself, nurtured from the aforemen-

tioned data.

However, besides data, models describing the sys-

tem conveys signiﬁcant knowledge that is often ne-

glected (Kirchhof et al., 2020; Bibow et al., 2020;

Sottet and Pruski, 2023; Sottet et al., 2022).

These models are particularly crucial during the

early phases of designing a digital twin because:

• They offer critical system information when data

is unavailable, insufﬁcient, or of poor quality,

Sottet, J.-S., Brimont, P., Pruski, C. and Abbasi, F.

How to Leverage Digital Twin for System Design?.

DOI: 10.5220/0013359700003896

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 13th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2025), pages 305-312

ISBN: 978-989-758-729-0; ISSN: 2184-4348

305

serving as a foundation for initial design decisions

and simulations.

• They assist in deﬁning the boundaries, objectives,

and functions of the digital twin, ensuring align-

ment with the intended real-world counterpart.

• They provide a structured framework for organiz-

ing and planning the data collection process, iden-

tifying key parameters and sources that need to be

monitored.

• They facilitate stakeholder collaboration by al-

lowing experts to contribute their knowledge and

perspectives, fostering consensus and reducing

misunderstandings through shared viewpoints.

• They enable early prototyping and scenario test-

ing, allowing designers to explore potential con-

ﬁgurations, identify risks, and evaluate feasibility

before committing resources to implementation.

• They act as a communication tool, translating

complex system dynamics into comprehensible

representations for diverse teams, including tech-

nical and non-technical stakeholders.

• They help anticipate future challenges by integrat-

ing predictive elements into the design, allowing

for a smoother transition to dynamic and adaptive

digital twin systems.

In this paper, we argue that Model-Driven Digital

Twins (MDDTs) can effectively support the system

throughout its entire lifecycle, including the early de-

sign phases where traditional data-driven digital twins

fall short due to the unavailability of data at the de-

sign stage (Friederich et al., 2022). The selected case,

consisting in the development of a hydrogen valley in

Luxembourg

, presents a compelling example: since

the system is not yet developed, we cannot rely on

existing data. Taking this into account, we hypoth-

esize that co-designing the system and its DT, with

alignment across the entire lifecycle of both the phys-

ical system and its twin starting from the earliest de-

sign phases, leads to enhanced consistency, efﬁciency,

and long-term adaptability in Digital Twin implemen-

tations. We aim at covering a subset of the differ-

ent system concerns, encompassing both technolog-

ical core and environmental, economic, and human

aspects. We consider the current system as an open

world (system borders in evolution) and not yet oper-

ating in runtime mode.

We further propose that this model-driven co-

design approach not only ensures alignment between

the system and its Digital Twin but also creates op-

portunities for seamlessly transferring and replicating

LuxHyVal see: https://www.luxhyval.eu/

the methodology across diverse applications and do-

mains.

We propose to develop and illustrate our hypothe-

sis through the creation of a new system and its digital

twin: towards a hydrogen value chain in Luxembourg.

The paper is organized as follows: Section 2 intro-

duced our illustrative case study based on a large ex-

ploratory project of hydrogen value chain. Section 3

proposes an approach to co-design the system and the

twin in our exploratory context. Section 4 discusses

the support of MDDT during the system lifecycle (ex-

ploitation, evolution, transfer).

2 ILLUSTRATIVE CASE STUDY:

HYDROGEN VALUE CHAIN

The complete production and exploitation of hydro-

gen is a complex task pertaining to many domains:

industry, mobility, housing, etc. The relevance and

sustainability of hydrogen as a source of energy is

currently under study and requires understanding the

overall impact (from initial energy provision to mar-

ket sells).

Figure 1: Hydrogen value chain.

The objective of LuxHyVal (see Figure 1) is to

evaluate a complete value chain of hydrogen from

production to consummation (motivated by the reduc-

tion of CO

production). The value chain encom-

passes the following aspects:

• The hydrogen produced will be used both for mo-

bility purposes (e.g. hydrogen fuelling stations)

and as an energy source for industry.

• Existing, or short to medium term planned infras-

tructure green energy production (Windmills and

solar panels, on the left-hand side of Figure 1), H

pipelines or transportation network.

• Reusing generated heat locally, for, e.g., residen-

tial heating or industrial use.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

306

To evaluate the optimal implementation of such a

value chain, a DT approach is proposed. This DT en-

ables the analysis of various design alternatives and

what-if scenarios, providing valuable insights. Fur-

thermore, the DT can be leveraged for scaling up the

solution and replicating the hydrogen valley concept

across other sites.

The novelty of our approach is to consider the

DT from the start of the design of the system and its

value chain. When the system and value chain are

not (fully) established, and no data is currently avail-

able. Therefore, it is necessary to make assumptions

about how the value chain will operate and the poten-

tial scenarios that may arise. The co-design of the sys-

tem (system + value chain) and the DT, will rely more

on expertise and knowledge about the expected oper-

ations than on real-time data collection. This involves

various domain experts (e.g., policymakers, mobil-

ity specialists, energy producers, public transporta-

tion managers, etc.) not only in the system design

phase itself but also simultaneously in the design of its

Digital Twin. This co-design process can be seen as

a virtuous cycle: each stakeholder will be committed

to the DT and become deeply involved in its develop-

ment, enhancing its accuracy and, consequently, the

quality of the services it will provide. This approach

requires expertise from various domains, notably en-

compassing models from high-level socio-economic

view (e.g, economical viability of the value chain) to

very technical issue solving (e.g., how to exploit the

green energy production peaks).

One approach is to implement a robust federation

of models (Golra et al., 2016), ensuring that the differ-

ent models are properly interconnected. Model feder-

ation provides several key advantages. First, it en-

ables the integration of diverse domain-speciﬁc mod-

els, allowing each to retain its own structure and se-

mantics while contributing to a uniﬁed representation

of the system. This approach reduces the need for

extensive re-engineering or restructuring of individ-

ual models, preserving domain expertise and ensur-

ing scalability. Second, federating models supports

modularity, making it easier to update or replace spe-

ciﬁc components without disrupting the entire system.

Third, a federation of models promotes collaboration

among stakeholders by providing a shared framework

where different disciplines can contribute their mod-

els while maintaining control over their speciﬁc areas.

Co-designing the system and its twin enables op-

timizing the value chain’s operation, planning fu-

ture investments, and enhancing both professional

and public understanding of its beneﬁts. Ultimately,

a similar approach could be used for preparing the

transfer of local experience to larger initiatives and

in different countries.

3 DESIGNING MDDT FOR

EXPLORATORY SYSTEMS

In this section, we describe the envisioned design ap-

proach of an MDDT in our speciﬁc context. We pro-

pose a progressive design of system models from re-

quirement up to detailed speciﬁcation and execution

on a given DT platform. This is represented in Fig-

ure 2, by ﬁrst establishing requirement models, then

deriving an architecture that is progressively reﬁned

(and made executable) to the full system architec-

ture reunifying non-functional and functional require-

ments.

Those design models will be the core of the

MDDT. Our stance is to blur the distinction between

the DT and design models; In line with (Wagg et al.,

2020), the primary goal is to leverage these models to

establish an operational Digital Twin from the outset,

even when minimal or no data is available. The mod-

els in the MDDT can be used at the run-time (Borde-

leau et al., 2020) both for simulation (including early

simulation during the design phase) and monitoring.

The other goal is to ensure that the design models

retain comprehensive information about the system

once it is operational. It also preserves the design ra-

tionale within the MDDT and prevents unwanted be-

havior. Due to this strong interconnection between

the system and the twin through design models, one

additional step (see Figure 2 DT support infrastruc-

ture) consists in designing the support infrastructure

for data collection connected to the DT.

3.1 Early System Design: Identifying

the Stakeholders and High Level

Architectural View

In the context of the Hydrogen valley, building the

corresponding DT starts by identifying all the key

players involved and the limits of the considered sys-

tem. In our case, for example, we are not consider-

ing the private hydrogen cars due to very low mar-

ket penetration. Our approach consists in providing

a high level architectural views including the actors

and their roles, the value chain (value modelling), the

goal and principles and high level (business) services.

Subsequently, we also consider the main services or

technical components to be developed (or existing one

to be adapted, like public transportation migration to

hydrogen). This ﬁrst architectural description is a

composition of different viewpoints inspired by En-

How to Leverage Digital Twin for System Design?

307

terprise Architecture (e.g., (Greefhorst et al., 2011))

on one side and Manufacturing / System Architec-

ture (e.g., (Benkamoun et al., 2014)) on the other

side. The context in which the system is developed,

notably all the related elements, must be considered

as well. Ideally, the context, should be identiﬁed to

provide insights into how the system could operate

in practice within its environment. As no data can

be inferred from a non-operational system, relying on

model-driven approaches is paramount.

3.2 Executable Model Architecture

Exploring and assessing the hydrogen value chain is

one of the core question of hydrogen implementation.

Ideally, we should evaluate the potential development

of hydrogen before the system is put into production.

This preliminary phase must address numerous uncer-

tainties, as there is limited exploitable data to conﬁrm

that a green hydrogen power plant could effectively

integrate into our speciﬁc context. As a result, we

adopt a design approach that is progressively reﬁned

through models that can be executed and/or simulate

the system’s behavior early in the design phase (Dah-

mann et al., 2017). This approach necessitates under-

standing external context elements that could impact

the system, such as meteorology, market demand, ur-

ban development, etc. Additionally, we must manage

design-time uncertainty (Famelis and Chechik, 2019)

by making assumptions about system content and be-

havior, using partial models to handle these uncertain-

ties (Bandyszak et al., 2021). In our case study, we

can integrate the early design of the hydrogen produc-

tion system, incorporating estimations with error mar-

gins, with projected future demand for public trans-

portation to calibrate the plant size and required input

energy. Additionally, by providing information about

typical weather patterns for speciﬁc times of the year,

we can ensure that green energy production aligns

with demand, optimizing the system’s efﬁciency and

reliability.

At this stage, we only have models representing

the system, but we can simulate scenarios close to

“what if” analyses typically performed by a digital

twin. The goal of this proto-digital twin (i.e., the

system is not yet in fully running) is to experiment

and quickly identify problematic designs (“fail fast”)

while exploring alternative designs before the system

is implemented. This proactive approach allows us to

reﬁne and optimize the system’s design, reducing the

risk of costly adjustments after deployment.

3.3 System Architecture and

Deployment

In the traditional modelling approach (Roques, 2016),

the last layer consists in preparing the deployment

of the system on its targeted platform (see Fig-

ure 2 Full System Architecture). It integrates both

non-functional (hardware/software support) and func-

tional requirements, offering a comprehensive and de-

tailed architecture. This includes the intricate design

of each system component.

3.4 Preparing Support for Digital

Twining

Beyond this traditional design approach, we can al-

ready prepare the Digital Twin. The data to be col-

lected, particularly the data needed to enable the DT

for its intended purposes (e.g., predictive mainte-

nance, value optimization, etc.), can be directly as-

sociated with speciﬁc model components. Similarly,

the operations to be performed back on the system

(e.g., actuators) can be directly connected to model

elements (see lower layer of Figure 2). In terms of

implementation of such a support, we can rely on the

MontiThing approach (Kirchhof et al., 2021) that an-

notates the architectural models with the data to be

collected by IoT sensors and action to be performed

thanks to actuators. We can extend this approach to

non-IoT data sources (any system log, external obser-

vation, databases for contextual data, etc.).

Figure 2: Design layers of Model-Driven Digital Twin.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

308

4 MDDT DURING SYSTEM

LIFECYCLE

In this section, we describe how the MDDT and the

system are co-evolving together beyond the design

phase. The overall lifecycle is given in Figure 3. It

shows the successive steps starting from the design

phase (see Section 3) to the operationalization and en-

hancement of the system. We did not mention the de-

commissioning and recycling of the system, which is

currently out of the scope of our study. The typical

process is organized as follows: the two ﬁrst step Re-

quire and Model in Figure 3 corresponds to the ﬁrst

modelling layer of Figure 2. The Execute phase, uses

the executable or simulated models. The two middle

layers in Figure 2 are used in order to explore design

choices and evaluate the system before it is in produc-

tion. A system and its DT support are deployed at the

beginning of the Align step of Figure 3. This step al-

lows for a progressive alignment of the MDDT to the

system, keeping it up to date according to integration

of operational data. Finally, the Exploit phase takes

place when the MDDT reaches an acceptable level of

ﬁdelity to the system in operation: this level can be re-

lated to a margin of error in the frame of the sensor’s

known errors margin.

When it reached this level of maturity, the MDDT

can deliver its different services: monitoring, predic-

tion, enhancement of the system, etc. After that, it is

possible to enter a new cycle, by extending the system

(Extend phase in Figure 3) or to Export the system in

another context (e.g., another country with other elec-

tricity production proﬁle). In our approach, the exten-

sion is systemically made under a modelling approach

(i.e., Model phase). In the following subsections, we

will focus on the phase that occurs after the design:

DT alignment and exploitation/operationalization, ex-

tension and transferability.

4.1 Alignment and Exploitation

Once we have reached a ﬁrst deployment of the sys-

tem, we can ofﬁcially talk about Digital twin: but the

design models of the previous phases should already

behave as close as possible to a real DT. In practice, it

will be necessary to refactor the DT models (keeping

in mind that the system may only be partially opera-

tional), some model ﬂexibility (Sottet and Biri, 2016)

will be necessary to ensure that both the DT and the

physical system could operate together at any time,

even if they are not fully aligned. The Align phase

will consist in a progressive convergence of the twin

and the system based on the feedback from sensed

data. It will consist in analyzing the drifts (David

and Bork, 2023) that could occur between system and

data. The drift can show some valid discrepancy (i.e.,

the MDDT is not aligned with the system) or invalid

due to a sensor defect (Abbasi et al., 2024).

In the Exploit phase, the MDDT could monitor

the system according to data collection support con-

nected to its models. The MDDT relies largely on

models at run time, the models being the represen-

tation of the run-time events, keeping an image of

the state of the system. The complete usefulness of

MDDT as a decision-support tool could occur once

this stage is reached: notably providing realistic simu-

lation of potential future event (what if scenario), pre-

diction of error, optimization of the system, etc.

Ultimately, this progressive alignment all along

the exploitation will hopefully enhance the accuracy

of the MDDT models. but could also foster for a hy-

brid approach of model-driven and data-driven, e.g.,

by replacing a function by a learned model (Sottet

et al., 2022).

4.2 Extending the System

Once the system and the MDDT are aligned, after one

or more iteration(s) of the previous cycle, the system

can be expanded (represented in Figure 3 with pro-

gressive extensions of considered system in the cen-

ter of the cycles). In our example, we ﬁrst design

the Hydrogen production (without considering green

energy) and try to assess the quantity for the direct

consumers (public transportation, factories) as well

as the potential return on investment. This ﬁrst cy-

cle is representative of the initial design of a MDDT

along its system. As represented in blue in Figure 3,

the two ﬁrst steps are purely models (see Section 3)

then the systems and the MDDT are co-existing and

co-evolving in the green part.

We can extend the initial hydrogen producer-

consumer, in a second cycle (middle of Figure 3),

with the indirect beneﬁciary of the Hydrogen produc-

tion (public heating network and recoverable O

pro-

duction); and similarly evaluate the global value and

return on investment. This cycle is completely green,

meaning that from that point on, MDDT and the sys-

tem are co-existing. Nevertheless, during the Model

and Execute phases, the MDDT works in a hybrid

mode: one part is aligned with the current system and

the other part is under study (similar to design phase).

We then have to rely on the models to assess if the

system is sustainable (i.e., from business to technical

perspectives) and for its implementation.

Finally, as illustrated in Figure 3, the ﬁnal visible

cycle involves integrating green energy production to

evaluate whether the demand can be met with the

How to Leverage Digital Twin for System Design?

309

current energy output. This step also includes plan-

ning for future installations of photovoltaic ﬁelds and

windmills to ensure sustainable energy supply. This

last case illustrates a different hybrid approach, as the

country already has existing photovoltaic panels and

windmills. Here, since the extension infrastructure is

already in place, the objective is to derive and inte-

grate models of the existing green energy production

system. The way the system is extended, is indeed a

co-evolution between the system and the MDDT, like

in the Mertens et al. approach (Mertens and Denil,

2023): we ensure a continuum between design and

operation of the system.

4.3 MDDT for System Transferability

The LuxHyVal tends to be an experimental and feasi-

bility prototype that aims at being transferred to dif-

ferent countries. Modelling the context under which

our system behaves is key. In the project, it is im-

portant to have some entry points in external fac-

tors (and related data sources) that inﬂuences the Hy-

drogen marker like e.g., transportation need/demand,

public subventions, size of industry that could work

with hydrogen, etc. Such contextual models should

appear in the early modelling phase. The internal el-

ements should also be adapted to the target country

(e.g., availability of green energy production). The

context model of the new country (e.g., local energy

production) will be used to project the prototype in a

different set-up. For instance, the market penetration

of Hydrogen will be less if the country has no plan to

facilitate the conversation of transportation into hy-

drogen. Finally, the proposed MDDT can be used as

a decision-making system at a high level of manage-

ment: country deciders, policymakers, etc.

As summary, our idea is to be able to use the

MDDT as the simulation environment to assess under

which conditions the overall system could be trans-

ferred in a different context. To perform the trans-

fer we can rely on the same approach, thanks to ex-

ecutable models, ideally reﬁned after a ﬁrst cycle of

implementation.

5 CONCLUSION

We have proposed an approach to design and oper-

ationalize new systems relying on model-based ap-

proach to build both proto-digital twin (i.e., models

of the system under design) and (real) digital twins.

The goal of the proto-digital twin is to assist in the de-

sign of a not yet established system through its Digital

Twin, even when the system is not completely estab-

lished. It helps to design prospective cases, notably in

our situation where the full value chain is not known

a priori. It also helps to identify new concerns of in-

terest that have indirect impact on the system. This

approach facilitates the involvement of stakeholders,

enabling the early capture of their knowledge that can

be seamlessly integrated into the proto-digital twin.

The proposed MDDT approach is blurring the distinc-

tion between design-time and run-time, on which the

different stakeholder can play with like a real DT. The

proposed approach mainly helps to:

• provide feedback on the system feasibility (i.e.,

value chain) as early as possible,

• prepare the data collection to directly feed the

MDDT

• ensure the co-evolution and consistency of

MDDT’s models and the system.

• reduce the usual initial alignment effort between

the system and the twin prior to the development

of decision-support functions.

• support extensions of the system scope with a hy-

brid approach: a model representing an actual part

of the system associated to a pure modeled part

(i.e., proto-digital twin) corresponding to the ex-

tension.

• rely on context models to prepare the transfer of a

similar system into a different context (i.e., a dif-

ferent country).

• operate the transfer based on a similar approach

as MDDT extension.

This approach is a preliminary work, proposing a

methodology to support our case study. Because of

this, the next step of our work will focus on pro-

viding the landscape of models and languages to be

used (e.g., value chain modelling, SysML, etc.). This

will also comprise a deeper search on the models used

to represent the context (i.e., the external inﬂuencing

factors), notably understanding where to put the limit

of such open-world DT. Then, we will design or se-

lect an execution language to operate the models. This

will ensure that we can simulate, even at higher level

of abstraction, the behavior of the overall hydrogen

value chain. We will also provide a way to control the

alignment between the MDDT and the system: pro-

viding analysis of the drift (Abbasi et al., 2024). It is

important to understand if the system is in bad health

(e.g., sensors malfunctions) or if the MDDT’s models

are no longer reﬂecting the system. Our ultimate goal

is to be able to support the co-existence of the sys-

tem and its design rational all along its lifecycle, sup-

ported by the operational notion of MDDT presented

in this article.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

310

Figure 3: Design and operation cycles of MDDT.

ACKNOWLEDGEMENTS

This research was partially supported by the EU Lux-

HyVal project (DOI10.3030/101111984) and by the

Luxembourg National Research Fund (FNR), project

MDDT-SD grant number C22/IS/17153694.

REFERENCES

Abbasi, F., Brimont, P., Pruski, C., and Sottet, J.-S. (2024).

Understanding semantic drift in model driven digital

twins. In Proceedings of the ACM/IEEE 27th Interna-

tional Conference on Model Driven Engineering Lan-

guages and Systems, pages 419–430.

Abdoune, F., Cardin, O., Nouiri, M., and Castagna, P.

(2021). About perfection of digital twin models.

In International Workshop on Service Orientation in

Holonic and Multi-Agent Manufacturing, pages 91–

101. Springer.

Bandyszak, T., J

ockel, L., Kl

as, M., T

orsleff, S., Weyer, T.,

and Wirtz, B. (2021). Handling uncertainty in collab-

orative embedded systems engineering. Model-Based

Engineering of Collaborative Embedded Systems: Ex-

tensions of the SPES Methodology, pages 147–170.

Becker, F., Bibow, P., Dalibor, M., Gannouni, A., Hahn, V.,

Hopmann, C., Jarke, M., Koren, I., Kr

oger, M., Lipp,

J., et al. (2021). A conceptual model for digital shad-

ows in industry and its application. In International

Conference on Conceptual Modeling, pages 271–281.

Springer.

Benkamoun, N., ElMaraghy, W., Huyet, A.-L., and Kouiss,

K. (2014). Architecture framework for manufacturing

system design. Procedia CIRP, 17:88–93.

Bibow, P., Dalibor, M., Hopmann, C., Mainz, B., Rumpe,

B., Schmalzing, D., Schmitz, M., and Wortmann, A.

(2020). Model-driven development of a digital twin

for injection molding. In International Conference

on Advanced Information Systems Engineering, pages

85–100. Springer.

Bordeleau, F., Combemale, B., Eramo, R., Van Den Brand,

M., and Wimmer, M. (2020). Towards model-driven

digital twin engineering: Current opportunities and

future challenges. In Systems Modelling and Manage-

ment: First International Conference, ICSMM 2020,

Bergen, Norway, June 25–26, 2020, Proceedings 1,

pages 43–54. Springer.

Boschert, S. and Rosen, R. (2016). Digital twin—the sim-

ulation aspect. In Mechatronic futures, pages 59–74.

Springer.

Dahmann, J., Markina-Khusid, A., Doren, A., Wheeler, T.,

Cotter, M., and Kelley, M. (2017). Sysml executable

systems of system architecture deﬁnition: A working

example. In 2017 Annual IEEE International Systems

Conference (SysCon), pages 1–6. IEEE.

David, I. and Bork, D. (2023). Towards a taxonomy of

digital twin evolution for technical sustainability. In

2023 ACM/IEEE International Conference on Model

Driven Engineering Languages and Systems Compan-

ion (MODELS-C), pages 934–938. IEEE.

Famelis, M. and Chechik, M. (2019). Managing design-

time uncertainty. Software & Systems Modeling,

18:1249–1284.

Feng, K., Ji, J., Zhang, Y., Ni, Q., Liu, Z., and Beer, M.

(2023). Digital twin-driven intelligent assessment of

gear surface degradation. Mechanical Systems and

Signal Processing, 186:109896.

Foundation, F. Fiware platform.

Friederich, J., Francis, D. P., Lazarova-Molnar, S., and Mo-

hamed, N. (2022). A framework for data-driven digi-

How to Leverage Digital Twin for System Design?

311

tal twins of smart manufacturing systems. Computers

in Industry, 136:103586.

Golra, F. R., Beugnard, A., Dagnat, F., Guerin, S., and Guy-

chard, C. (2016). Addressing modularity for hetero-

geneous multi-model systems using model federation.

In Companion Proceedings of the 15th International

Conference on Modularity, pages 206–211.

Greefhorst, D., Proper, E., Greefhorst, D., and Proper, E.

(2011). The role of enterprise architecture. Springer.

Grieves, M. and Vickers, J. (2017). Digital twin: Mitigat-

ing unpredictable, undesirable emergent behavior in

complex systems. In Transdisciplinary perspectives

on complex systems, pages 85–113. Springer.

Kirchhof, J. C., Malcher, L., and Rumpe, B. (2021). Un-

derstanding and improving model-driven iot systems

through accompanying digital twins. In Proceedings

of the 20th ACM SIGPLAN International Conference

on Generative Programming: Concepts and Experi-

ences, pages 197–209.

Kirchhof, J. C., Michael, J., Rumpe, B., Varga, S., and

Wortmann, A. (2020). Model-driven digital twin

construction: synthesizing the integration of cyber-

physical systems with their information systems. In

Proceedings of the 23rd ACM/IEEE International

Conference on Model Driven Engineering Languages

and Systems, pages 90–101.

Liu, Z., Meyendorf, N., and Mrad, N. (2018). The role

of data fusion in predictive maintenance using digital

twin. In AIP Conference Proceedings, volume 1949,

page 020023. AIP Publishing LLC.

Mertens, J. and Denil, J. (2023). Digital-twin co-evolution

using continuous validation. In Proceedings of the

ACM/IEEE 14th International Conference on Cyber-

Physical Systems (with CPS-IoT Week 2023), pages

266–267.

Microsoft (2022). Azur digital twin.

Roques, P. (2016). Mbse with the arcadia method and the

capella tool. In 8th European Congress on Embedded

Real Time Software and Systems (ERTS 2016).

Sottet, J.-S. and Biri, N. (2016). Jsmf: a ﬂexible javascript

modelling framework. In Workshop on Flexible Model

Driven Eng.(FlexMDE).

Sottet, J.-S., Brimont, P., Feltus, C., G

ateau, B., and

Merche, J. F. (2022). Towards a lightweight model-

driven smart-city digital twin. In Proceedings of the

10th Conference on Model-Driven Engineering and

Software Development.

Sottet, J.-S. and Pruski, C. (2023). Data and model harmo-

nization research challenges in a nation wide digital

twin. Systems, 11(2):99.

Wagg, D., Worden, K., Barthorpe, R., and Gardner, P.

(2020). A digital twins: State-of-the-art future direc-

tions for modelling and simulation in engineering dy-

namics application. . ASCE - ASME Journal of Risk

and Uncertainty in Engineering Systems.

Zhang, Y., Feng, K., Ji, J., Yu, K., Ren, Z., and Liu, Z.

(2022). Dynamic model-assisted bearing remaining

useful life prediction using the cross-domain trans-

former network. IEEE/ASME Transactions on Mecha-

tronics.

MODELSWARD 2025 - 13th International Conference on Model-Based Software and Systems Engineering

312