Towards a Lightweight Model-driven Smart-city Digital Twin

Jean-S

ebastien Sottet, Pierre Brimont, Christophe Feltus, Benjamin Gateau and Jean-Francois Merche

Luxembourg Institute of Science and Technology (LIST), 5 Avenue des Hauts Fourneaux, Esch-Alzette, Luxembourg

Keywords:

Digital Twin, System Model Prototype, Executable Models, Flexible Modelling.

Abstract:

In this article we consider the use of digital twin for representing open physical system, notably smart-cities.

In this context everything is not necessarily deﬁned or sensed; as a result a pure data-driven approach is not

possible and should be completed by expert knowledge, hence through models. We propose an approach to

design a model-driven digital twins MDDT that supports this context. It allows to 1/ quickly prototype digital

twins, 2/ integrate various information from different kind of sources (diverse expertise, data, etc.) 3/ support

evolution and enhancement all along the system’s life-cycle.

1 INTRODUCTION

Amongst the many existing deﬁnitions of Digital twin

(Barricelli et al., 2019) (DT) we propose to adopt this

one: digital twin is “a digital replica of a physical sys-

tem”. The DT should behave similarly to the physical

system if a similar event occurs to it. Conversely, ac-

tion on the DT could have an impact on the physical

system if it is designed as such

Existing commercial approaches are proposing

data-based DT and are focusing on data collection,

for instance the generic platform Microsoft Azur

. Mainly dedicated to smart-city cases, it focuses

on heterogeneous data collection and harmonization

through a standardized single data model. Some ini-

tiatives try to add semantic (Singh et al., 2020) and ad-

ditional information to the initial pure data-based DT.

The current approaches mainly focuses on building

DT from data obtained from the physical system only.

As a result they are heavy weight and relying on com-

plex infrastructure for data collection (e.g., Fiware

)

and advances Machine Learning (ML) (Chakraborty

and Adhikari, 2021) plus Data Analytics to build a

digital twin; additional technologies are to be used to

complete the view, like large 3D representations (see

Unreal Engine for 3D digital twins

). However this

view may remain only partial as all the knowledge

In smart-city cases the automated loop back from digi-

tal twin to the physical system is not always possible

https://azure.microsoft.com/en-us/services/digital-

twins/

https://www.ﬁware.org/

https://www.unrealengine.com/en-US/digital-twins

about the physical system is not necessarily available

through data/sensors.

From our perspective, we think that digital twins

are rather hybrid entities (alike ideas expressed in

(Lektauers et al., 2021)) composed by either human

knowledge (technical blue prints, equations, etc.) or

data information and machine inferred models, all

being part of the deﬁnition of Model-driven Digital

Twin (MDDT). The need of having more than only

data-based approaches for digital twins construction

is emphasized when twining beyond the classical in-

dustrial use-case (Raj and Surianarayanan, 2020) sys-

tems :

• which are more open like Smart Cities (Ketzler

et al., 2020),

• which include a lot of assumptions of their bor-

ders (and behavior) with other systems,

• with part of the information which cannot be

given by data collection (e.g., no sensors for this

kind of data).

This is where models, as human construction for rep-

resenting the reality, come into play.

Moreover, under this open system assumption, an

approach would be to build incrementally a DT re-

lying on model-driven engineering. In this approach

we take an excerpt or a speciﬁc aspect of the phys-

ical system and ﬁrst build a partial MDDT

. Then

we extend it all along the discovery of the system

facets, whilst improving the twin with the physical

Other deﬁnition of partial digital twin can be given like

digital shadow or digital models as partial construction of

the reality or abstraction of the reality (Ladj et al., 2021)

320

Sottet, J., Brimont, P., Feltus, C., Gateau, B. and Merche, J.

Towards a Lightweight Model-driven Smart-city Digital Twin.

DOI: 10.5220/0010906100003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 320-327

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

system feedback (e.g., data). The excerpt can be a

complex sub-system, like the electricity consumption

of a quarter of a given city. It acts as a lens, helping to

start with a concrete aspect of the physical system; it

can be for instance later extended with the local elec-

trical production of the quarter allowing to gradually

build a more complete MDDT. This extension can be

realised by combining different MDDT coming from

other perspectives, thus calling for a federation of DT,

close to the initial vision followed by Cambridge Uni-

versity’s Center for the Digital Built Britain

. In this

article, we promote the use of lightweight modeling

support that would ease the development of such dig-

ital twins. Under such modelling support, parts of

the model should also be easily replaced or extended

when a more precise element is available: e.g., a re-

ﬁnement of the system behavior by analyzing actual

data.

This paper is organised as follow: we ﬁrst con-

front the MDE approach used with traditional Data

Driven solutions to identify speciﬁc requirements for

a lightweight Model processing platform, calibrated

for smart-city open worlds. Then we expose those

requirements through our approach to design a ﬂexi-

ble MDDT, applied to a proof of concept in the con-

text of smart city, and through snapshots of the cur-

rently developing prototype. We notably highlight

the static and dynamic (action language) modelling

aspects and, more importantly, the life-cycle of a

MDDT, following the reﬁnement on its relations to

physical system: reducing the modeling gap.

2 THE REQUIREMENTS FOR

OPEN MODEL-DRIVEN

DIGITAL TWIN

As exposed in the introduction, we focus on open-

world digital twins, with potentially few sensors

and/or with a lot of human interventions. This is

typically the context of a smart-city; where some of

the information have been ﬁrst designed (e.g., build-

ing information models) and where the knowledge

evolves during its life-cycle. We set the requirements

of a MDDT with the following capabilities:

• Simulation Capabilities: evaluate and store re-

silience of the physical system when extreme con-

ditions occur.

• Monitoring Capabilities: direct connection to

the physical twin: MDDT should be a mirror of

what happens in the reality.

https://www.cdbb.cam.ac.uk/

• Alignment Capabilities: learn from the physical

system in order to be updated and to better ﬁt with

reality: coping with twin-physical system gap.

2.1 Need for Rapid Prototyping Digital

Twins

Digital twin supporting systems can be complex like

the one described in (Kaur et al., 2020): it encom-

passes a lot of domains and technologies like internet

of things, edge and cloud computing architectures, ar-

tiﬁcial intelligence, machine learning, big data analy-

sis, etc. However, for some speciﬁc situations, such a

complex architecture is not always desirable, notably

under the following circumstances:

• When considering a new domain, or at the early

phases of designing a digital twin, it may be nec-

essary to cope with very few data and complete

it with models. In addition, even with a partial

MDDT we should be able to validate the hypoth-

esis we made in it.

• Within an existing digital twin, some aspects are

not connected to sensors: They are done by hu-

man or not yet taken in account because of their

novelty. Thus, no pre-existing and complete

model of this physical part can be deﬁned. Con-

sequently, it requires to rapidly design an approx-

imate but realistic model (according to human

knowledge) in order to avoid blind spots when

twining the system (for e.g., simulation or predic-

tion purpose).

• the digital twin is also used as a simulation envi-

ronment where it is important to be able to quickly

test speciﬁc up to extreme scenario and proto-

type innovative ideas for the physical system (e.g.,

”what-if” scenario).

• Finally, we may have to deal with different digi-

tal twins, each completing the other and acting in

a federated way; So we need to take into account

that some are still missing in the twins constella-

tion.

As a result, it is necessary to be able to quickly sketch

models and model manipulations (e.g., model trans-

formation, model processing) to build those digital

twins from a human knowledge. It is also essential to

have ﬂexibility to discover the data and information

coming from the physical system. Finally, it is also

requisite to ensure interoperability with other twins

at the border of the considered one like e.g., (Grace

et al., 2016).

Towards a Lightweight Model-driven Smart-city Digital Twin

321

2.2 Need for Supporting Evolution and

Flexibility

As stated in (Bordeleau et al., 2020), there is a

strong need to interconnect models when dealing with

MDDT. It is also necessary to interconnect those

models with the physical system sensors and even

sometimes to discover the sensors themselves (value,

semantic). Thus, we should rely on a ﬂexible model-

ing framework, enough permissive to relax modelling

language constraints (Salay and Chechik, 2013) to al-

low those interconnections. Moreover, as their physi-

cal counter parts evolve, the underlying models of the

MDTT should also be able to evolve easily. The mod-

els remains open to new event, sensors, modiﬁcation,

alteration of the physical system.

We should also take into account, as any designed

model, that the MDDT may be at a certain point of

time of its lifecycle, partially deﬁned with potentially

uncertainty. This uncertainty is part of the process

of building a twin that mimics more effectively the

reality.

Finally, we consider that, beyond data, the MDDT

content is provided by different human proﬁles: dif-

ferent kind of users, different domain experts, etc.

This is where ﬂexibility also comes into play when

capturing, as models, the knowledge provided by

the experts. Notably, this ﬂexibility is part of natu-

ral modelling approach (Zarwin et al., 2014) and is

important to ease the capture of expert knowledge

through models from a wide range of expertise do-

mains.

2.3 Need for Executable Model and

Action Languages

Some of the models composing a digital twin are

by essence executable (e.g., machine learning mod-

els, scientiﬁc models), others are more static repre-

sentation of the system, like UML models, or in-

cludes static representation of the dynamic, like state-

charts. Deﬁning behavior of the models part is crucial

notably for supporting our prototyping approach of

MDDT. Typically model execution is ensured through

scripting (Peltonen and Selonen, 2001), generic ac-

tion languages (e.g., AlF, FUML (Guermazi et al.,

2015), xUMl,Scrall

etc.), business rules or through

domain-speciﬁc action language (Mayerhofer et al.,

2013).

In order to exploit the MDDT we should be able

to execute it for:

https://github.com/modelint/scrall

• replaying past scenario and thus test and validate

MDDT prototype,

• make simulation to see the physical system re-

silience,

• align itself with actual physical system state (as

for monitoring goal).

Finally, to provide a coherent context and allow for

continuity of execution (notably supporting the evo-

lution), we should relate the executable part (i.e., dy-

namic) with their static counter-parts modeling ele-

ment and we also need to provide backup solutions to

the execution. For instance, an approximation func-

tion of required value for the execution is one of the

possible backup solutions when some of the model

elements are suppressed.

2.4 Need for Considering Data as Model

When we try to make sense of the data, i.e., not to

consider the data as simple binary values, we already

consider the data as an element of the model. To sup-

port this claim, we get inspired by (B

ezivin, 2004):

the execution of a given program is also considered

as a model (in the MDE deﬁnition) if it is conform to

a metamodel. By extension, we can say that the data

handled by this program is also a model (since we can

express a metamodel to which it conforms to). This

idea ﬁnds also an echo in the ﬁeld of the semantic web

with the concept of sensor linked data (Patni et al.,

2010). In addition, when dealing with data and sen-

sors, it is important to consider the evolution through

time (beyond discrete modelling) as the approach de-

scribed in (Moawad et al., 2015).

Some current infrastructures or platforms for digi-

tal twining (e.g., Microsoft Azur DT) are already pro-

viding means to structure and gather IoT data from an

interoperable way (Conde et al., 2021). Furthermore,

like in Fiware, raw data is enhanced with meta-data to

be exchanged by applications, modules, and services

through a central ”context broker”. It is reasonable

to think, by interfacing with such infrastructure, that

a sensor producing data should have a metamodel,

which allows for a seamless integration of the data

into a MDDT. Under a simulation perspective, the

data produced by the MDDT will turn to be directly

expressed in the right metamodel (or data schema) al-

lowing the expert a better understanding of what hap-

pened (in the simulation) as it is also expressed in the

same format as real data. It can then help experts to

compare and assess design alternative in the reality by

simulation on the twin.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

322

Figure 1: Current experimental reloading bus station.

3 MODEL DRIVEN DIGITAL

TWIN IN ACTION

As we have shown in the requirements section (see

Section 2), it is necessary to have a modelling in-

frastructure that has the following functionalities: 1/

sketch easily a ﬁrst MDDT either on its static parts

(the models) or dynamic parts (actions) involving ex-

pert knowledge;// 2/ easily test and validate (e.g., us-

ing a scripting-like approach) the different models of

knowledge available on a digital twin;// 3/ align this

ﬁrst MDDT with the physical system coping with re-

ality gap and potential evolution of the physical sys-

tem properties;// 4/ make this MDDT ﬂexible enough

to connect to the physical system and other potential

twins.// In the following of this section we will ad-

dress the functionalities 1, and partially 2 and 3. The

fourth one is out of the scope of this position paper.

3.1 Case Study

Our case study addresses to electric public transporta-

tion. This is a ﬁrst step into a smart-city-wise prob-

lem that can be extended to all the electricity produc-

tion, trafﬁc management, etc. Thus, we focus on an

electric bus line which aims at optimising its electric-

ity consumption and still offering a good quality of

service. The electricity can be reloaded during the

bus tour at local reloading stations see Figure 1. The

buses should try to keep-up with their schedule with

regards to e.g., potential work, trafﬁc jam, meteoro-

logical conditions, while avoiding emptying their bat-

teries and getting stuck.

In this case-study, a DT should be used to assess

the resilience of such full electric buses on a given

pathway simulating potential trafﬁc jam, works and

drastic change in weather conditions. It can also an-

swer about the best stop to reload using only green

energy, thus depending on weather condition and lo-

cal energy consumption. Finally it can help in assess-

ing if new bus stops or alternative tracks still remain

compliant with the service quality requirements.

Figure 2: Electro-mobility with hybrid bus scenario includ-

ing weather forecast, green electricity production.

3.2 Designing a First MDDT

During our prototyping phase of MDDT, we consider

a ﬁrst abstraction of the physical system, i.e., the bus

electro-mobility case. So, we ﬁrst design a digital

model (among others) that serves as a basis of the

MDDT and that as the ability to evolve as data col-

lection and knowledge about the system progress. In

this ﬁrst step, several sources of information are to be

taken into account:

1. we know (from the bus company experts) the bus

stops, reloading stations and routes.

2. we know from past data and/or the expert knowl-

edge, the potential impact on electricity consump-

tion on each route portion (e.g., high climbing

percentage, dedicated bus portion) between two

stops.

3. we know, from the company designing the bus,

an average consumption of the bus according to

its load (passengers), and the weather (tempera-

tures).

4. we can extrapolate based on expert feedback the

impact of works, trafﬁc jams, etc. on each route

portion.

Within this context, we propose to use JSMF (Sottet

and Biri, 2016), a JavaScript-based modeling frame-

work, that aims at being ﬂexible and make model-

based application prototyping easy. In its current

implementation JSMF partially supports the identi-

ﬁed requirements on Section 2. We aims to rely on

this modeling language to describe the static part of

the model and we illustrate the dynamic part with

JavaScript functions that manipulates JSMF Models.

Those JSMF models are processed by elaborated spe-

ciﬁc languages on top of JavaScript.

Towards a Lightweight Model-driven Smart-city Digital Twin

323

Figure 3: Visual of bus route modelling, including event

like work or trafﬁc jam, reloading stations are special kind

of bus stop.

3.2.1 Static Information

JSMF can be directly used to represent elements 1

and 2 of the previous enumeration: they can be repre-

sented as a graph (see Figure 3) of routes (the edges)

connecting the stops (the nodes). On each route

the impact on the consumption is an attribute factor.

Reloading stations are subclass of bus stops. We ﬁrst

establish a JSMF metamodel to support the deﬁnition

of the buses and the pathway graph. The JSMF allows

to deﬁne a metamodel in multiple (sub)modules and

combines them together in a seamless way.

The bus is deﬁned in Listing 1 as follow: a bus has

an identiﬁer, a line number, a battery level (from 0 to

100) and a number of passengers.

1 v ar Bus = Cl ass . n ew In st a nc e ( ’ Bus ’)

2 B us . s et A t t ri b u t e ( ’ i d en ti fi e r ’ , Str in g

)

3 B us . s et A t t ri b u t e ( ’ l i ne Nu mb e r ’ , Num be r

)

4 B us . s et A t t ri b u t e ( ’ b a tt e ry Le v el ’ , JS M F

. R ang e (0 , 100) ) // Bat te ri e from 0

to 100

5 B us . s et A t t ri b u t e ( ’ p a ss en ge r s ’ , Num be r

)

Listing 1: Bus metamodel deﬁnition.

The metamodel for the stops and routes that forms

a graph is deﬁned in Listing 2. A Stop is deﬁned

by its name and its geographical coordinates (latitude

and longitude). The Route class joins the stops using

the fromStop and toStop relations. In this case study

we only focus on a given line pathway: alternative

route will necessary modify the original routing. The

consumption attribute, deﬁnes the consumption factor

to be applied to the given route according to expert

knowledge with regards to slope and length.

Figure 4: Map User Interface on top of JSMF.

1 v ar Stop = Cl ass . ne wI n st an c e ( ’ Stop ’ )

2 Stop . se tA t t r ib u t e ( ’ n ame ’ , St rin g )

3 Stop . se tA t t r ib u t e ( ’ lat it ud e ’ , St ri n g )

4 Stop . se tA t t r ib u t e ( ’ lo n g it ud e ’ , St r in g

)

6 v ar Route = Class . ne wI n st an c e ( ’ Rou te ’

)

7 Rou te . se t A tt r i b ut e ( ’ co n s um pt i on ’ ,

Num be r )

8 Rou te . se t R ef e r e nc e ( ’ t oS to p ’, Stop , 1,

’ f ro mR ou te ’)

9 Rou te . se t R ef e r e nc e ( ’ fro mS to p ’ , Stop ,

1, ’ toR ou te ’ )

11 v ar Rel oa de r = C las s . n e wI ns t a n ce ( ’

Re lo ad er ’ )

12 Re lo ad er . su p er Cl a ss es = [ Rou te ]

Listing 2: Stops and route deﬁnition.

Then, in order to actually represent (and abstract)

the physical system, a model conforms to this meta-

model has to be instantiated. Here, multiple experts

can come into play. For a better user experience with

the model it is crucial to propose a simple yet efﬁcient

user interface on top of the JSMF model. In smart-

city systems, a geographical representation (poten-

tially including building in 3D) is the best way to

interact with domain experts. It is easy to interface

technologies like leaﬂet

and mapbox

with JSMF.

Through this interface (see Figure 4) the city bus

responsible deﬁnes the bus stops (position, naming)

as well as the actual routes between two stops. On

top of each route, a consumption factor should be set.

In the absence of actual data (e.g., starting a new line,

using new kind of buses, etc.), it can be derived from

the route path characteristic like the slope and length

applying them a consumption factor on the battery

(KwH/kilometers) and a mean consumption given by

the bus constructor. It constitutes a ﬁrst approxima-

https://leaﬂetjs.com/

https://www.mapbox.com/

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

324

Figure 5: Dependencies relation between dynamic (func-

tions) and metamodel elements.

tion for simulations and be update later with actual

data.

An example of an instantiated metamodel is given

in Listing 3, for sake of simplicity we have removed

some of the attributes like the geographical coordi-

nates.

1 v ar b1 = Bus . n e wI n s t an ce ({ id en ti f i e r :

’B1 ’ , l in eN u mb er :11 , b at t e r ie L ev e l

:10 0} )

3 v ar sA = St op . n e wI ns t a n ce ({ n a me : ’A ’ })

4 v ar sB = St op . n e wI ns t a n ce ({ n a me : ’B ’ })

6 v ar ro ut eA = ro ute . ne wI n s t an ce ({

co ns u m p ti on :7 , f ro mS to p :sA ,

toS to p : sB })

Listing 3: Example of the model: bus b1 and the ﬁrst stops

and routes.

3.2.2 Dynamic Information

Once we have deﬁned the static content of the MDDT,

we need to provide, thanks to the diverse domain ex-

pertise, the way to animate our model and potentially

provide simulation. We choose a function approach

on top of our metamodel. The ﬁrst demonstrator aims

at simulating the buses route based on the previous

model and metamodel. We have thus identiﬁed some

of the function required to process or ﬁrst (and partial)

MDDT. As we work in a potentially evolving environ-

ment, at least the dependencies between the dynamic

function and their corresponding metamodel elements

should be modeled. The Figure 5 summarizes the de-

pendencies relations.

The Listing 4 shows a simple JavaScript that ma-

nipulates the Route, Bus and Stop classes: since the

bus is on duty, it follows the predeﬁned path. We

focus peculiarly on the followRoute function, which

computes a new battery level at each followed route,

time (and potentially time lost), and passengers en-

tering and leaving the bus. It relies directly on the

JSMF model with dot notation: going to the next

destination is then simple as given by the model:

b1.isAtStop[0].toRoute[0].toStop[0].

1 fu nc ti on a ni m a t eB us () {

2 whi le ( b1 . is On Du ty () ) {

3 var fol lo we d = fol lo wR o ut e ( b1 )

4 b1 . b a t t er y Le ve l = fol lo we d .

ne w B a t t e ry L ev e l

5 b1 . i sA tS to p = fo ll ow ed .

de st i n a ti on

6 ...

7 }

8 fu nc ti on f ol l ow Ro u t e ( b1 ) {

9 va r rou te = b1 . i sA tS to p [ 0 ]. t oR ou te

[0]

10 res ul t . d e st in a t i on = rout e . t o St op

[0]

11 res ul t . n e wB a tt e ry L ev e l =

co m p u te B at t er y ( b1 . ba tte ry Lev el ,

rou te . con s um pt io n )

12 .. .

Listing 4: Animation/Simulation of the model using a

simple script.

The function that computes the (estimated) new

battery level regarding the route can be given by a tex-

tual DSL that is representing a business rule or by an

average consumption factor applied on the route con-

sumption. At this stage of our prototype implementa-

tion, we have directly written the javascript function

from general information estimated by experts values

from a given formula.

For each segment of length (Le), the slope (Sl), the

weather (We), the average weight (Pe) depending on

the number of people (Pa) in the bus, possible road-

works (Wo) and trafﬁc (Tr) are taken into account.

Each parameter is expressed as a variable, allowing

to approximate the emulated consumption. Knowing

that an electric bus consumes on average 0.165 kW

per kilometer, we deﬁned the following equation:

Co = 0.165 ∗ (

Sl ∗We

+Wo + Tr)

The Slope is a coefﬁcient in the interval ]0, 7 − 1.3[

Sl ∈ R with 0.7 ≤ Sl ≤ 1.3

The Length of the segment is expressed in km ]3−10[

Le ∈ R with 3 ≤ Le ≤ 10

The Weather is a coefﬁcient in the interval ]0 − 1]

We ∈ R with 0 < We ≤ 1

Which gives in pseudo-JavaScript:

We = Math. f loor(Math.random() ∗ 0.49) + 0;5

People is the coefﬁcient of the over-consumption

depending on the total weight (average 70 kgs) of all

the Passengers including the driver [1-60]

Pa ∈ R with 1 ≤ Pa ≤ 60, Pe = 70 ∗ Pa ∗ 1, 01

Towards a Lightweight Model-driven Smart-city Digital Twin

325

Road Works are triggered by and event (Boolean) and

a time length (min) [1,15], weighted by the coefﬁcient

of a stopped engine consumption

∀E 6= 0 and t ∈ Rwith1 ≤ t ≤ 15Wo = E ∗ 1, 02 ∗ t

Which gives in pseudo-JavaScript:

Wo = 1.02 ∗ (Math.round(Math.random()) ∗

Math. f loor(Math.r andom() ∗ 14) + 1

Trafﬁc is triggered by an event (Boolean) and a

length (km) [1, 10], weighted by the coefﬁcient of an

idled engine consumption

∀E 6= 0 and l ∈ R with 1 ≤ l ≤ 10Tr = E ∗ 1.03 ∗ l

Which gives in pseudo JavaScript:

Tr = 1.03 ∗ (Math.round(Math.random()) ∗

Math. f loor(Math.r andom() ∗ 10) + 1

We have very shortly illustrated that there are

many kind of input in modeling such a system. As

stated in (Bucchiarone et al., 2020), it can be very

broad: scientists can provide advanced mathemati-

cal models, domain experts can deliver business rules,

regulatory experts can restrict or scope with laws, etc.

Managing different aspects in such a context requires

a good coordination of models and modelling lan-

guages to ensure a coherent modelling landscape and

common understanding of stakeholders under the DT

challenges (Bjekovic et al., 2012). This is still a com-

plete open challenge that we try to partially alleviate

using a classical approach: a systematic modelling

and dedicated languages / view for experts.

3.3 MDDT Lifecycle

We have thus designed our ﬁrst backbone models on

which we can play with to, e.g., simulate the physical

system. This ﬁrst partial MDDT has more or less con-

sistency with the physical twin. It is assumed, in its

early design time, to be an abstraction of the physical

system. As a result, we can compare the execution

of model with the similar model coming from the ac-

tual bus data (i.e., physical system), expressed in the

same metamodel. From this comparison we can make

evolution of metamodel, model (dynamic and static),

up to a less partial digital twin. It is important to un-

derstand that we can infer reﬁnement (Zolotas et al.,

2019; Sottet and Biri, 2016) of the originally designed

metamodel from collected information in the physical

twin: notably new attributes identiﬁcation.

Consequently, it is crucial to consider the matura-

tion process of the MDDT under two axis: 1/a more

precise view on physical system (e.g., knowing its

border, better comprehension on requirements, etc.)

2/ the information collected on the physical knowl-

edge which helps to improve the initial MDDT.

We can think of the following prototypical exam-

ple situations from our case study:

• the revision of an attribute value: the route factor

consumption attribute of the Route can be updated

from the real physical system update.

• the revision of a dynamic aspect: the introduction

of time.

• the revision of metamodel elements and related

dynamic aspects taking into account the weather

and its impact on battery energy consumption.

• change the computeBattery() function with re-

gards to actual data and machine learning models.

For instance, it can be executed using tensorﬂowjs

(from a Keras model) inside the computeBattery()

function as in Listing 5.

1 con st mode l = a wai t tf .

lo a d L a y e rs M od e l ( ’ l o ca l s t or a ge ://

co n su m pt i o n M o d e l ’)

2 re t ur n mode l . p re d ic t ( route , we at he r ) )

Listing 5: Loading a tensorﬂow model in Javascript.

More generally, we gradually ﬁx the metamod-

els and models of the MDDT for both dynamic and

static aspects. It requires the modelling framework

supporting the MDDT to be ﬂexible enough as one

of both metamodels and models could evolve inde-

pendently. Moreover, the dynamic part may fail to

compute or simulate the model. Reasoning with the

functions dependencies (whatever they are machine

learning or written) is crucial to identify the block-

ing points. When one of this potential blocking point

is identiﬁed (e.g., the model structure has changed,

an attribute is not deﬁned (either in the metamodel or

the model)), we should then reason with uncertainty.

Ideally, this is where approximation function based

on past data can be used to provide, e.g., an absent

attribute value. Similarly, to dynamic functions, ap-

proximation function should be modeled with regards

to the backbone metamodel elements.

Moreover, it is important to warn the stakehold-

ers and expose the modeling alternatives like (Famelis

et al., 2012) when, e.g., a new weather concept is

added, about the impact in terms of model element

and computations. This feedback to stakeholders, de-

cision making process is also an open challenge to

deal with when considering MDDT.

4 CONCLUSIONS

This position paper presented our view on the design

of a Digital Twin in a smart-city context. In such an

open context, the system may not have clear bound-

ary, this is especially true when discovering the area

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

326

or trying to apprehend an issue in the physical sys-

tem. As a result, we propose to complete trendy data-

driven approaches for DT with a ﬂexible and integra-

tive modelling approach.

Through this approach we deﬁned MDDT proto-

types; they are composed by executable models (de-

ﬁned in a static and dynamic ways) that are captured

from a variety of inputs (e.g., different domain exper-

tise, data consolidation, machine learning, etc). Those

executable models allow notably to provide an easy

to use simulation environment. In addition, MDDT

prototypes should be able to evolve, being reinforced,

some part being replace with data-driven ones (e.g.,

machine learning).

Accordingly, there are still a lot of challenges and

future works to be tackled and implemented to fully

support our vision. Let cite amongst other: ensur-

ing the continuity during MDDT evolution, integra-

tion MDDT with a more data-driven approach (e.g.,

FiWare), multi-language and view for stakeholders in-

volvement, and integration with other DT.

REFERENCES

Barricelli, B. R., Casiraghi, E., and Fogli, D. (2019). A

survey on digital twin: deﬁnitions, characteristics, ap-

plications, and design implications. IEEE access,

7:167653–167671.

ezivin, J. (2004). In search of a basic principle for model

driven engineering. Novatica Journal, Special Issue,

5(2):21–24.

Bjekovic, M., Proper, E., and Sottel, J.-S. (2012). Towards a

coherent enterprise modelling landscape. In 5th Conf.

on the Practice of Enterprise Modeling, Rostock, Ger-

many, 2012, pages 1–12. [Sl]: CEUR.

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 Conf. on Systems Modelling and

Management, pages 43–54.

Bucchiarone, A., Cabot, J., Paige, R. F., and Pierantonio, A.

(2020). Grand challenges in model-driven engineer-

ing: an analysis of the state of the research. Software

and Systems Modeling, 19(1):5–13.

Chakraborty, S. and Adhikari, S. (2021). Machine learn-

ing based digital twin for dynamical systems with

multiple time-scales. Computers and Structures,

243:106410.

Conde, J., Munoz-Arcentales, A., Alonso, A., Lopez-

Pernas, S., and Salvachua, J. (2021). Modeling dig-

ital twin data and architecture: A building guide with

ﬁware as enabling technology. Internet Computing.

Famelis, M., Salay, R., and Chechik, M. (2012). Partial

models: Towards modeling and reasoning with uncer-

tainty. In 2012 34th International Conference on Soft-

ware Engineering (ICSE), pages 573–583. IEEE.

Grace, P., Pickering, B., and Surridge, M. (2016). Model-

driven interoperability: engineering heterogeneous iot

systems. Annals of telecommunications.

Guermazi, S., Tatibouet, J., Cuccuru, A., Dhouib, S.,

erard, S., and Seidewitz, E. (2015). Executable mod-

eling with fuml and alf in papyrus: Tooling and exper-

iments. strategies, 11:12.

Kaur, M. J., Mishra, V. P., and Maheshwari, P. (2020). The

convergence of digital twin, iot, and machine learn-

ing: transforming data into action. In Digital twin

technologies and smart cities, pages 3–17. Springer.

Ketzler, B., Naserentin, V., Latino, F., Zangelidis, C., Thu-

vander, L., and Logg, A. (2020). Digital twins for

cities: A state of the art review. Built Environment,

46(4):547–573.

Ladj, A., Wang, Z., Meski, O., Belkadi, F., Ritou, M.,

and Da Cunha, C. (2021). A knowledge-based dig-

ital shadow for machining industry in a digital twin

perspective. Manufacturing Systems, 58:168–179.

Lektauers, A., Pecerska, J., Bolsakovs, V., Romanovs, A.,

Grabis, J., and TEILANS, A. (2021). A multi-model

approach for simulation-based digital twin in resilient

services. WSEAS Trans. Syst. Control, 16:133–145.

Mayerhofer, T., Langer, P., Wimmer, M., and Kappel, G.

(2013). xmof: Executable dsmls based on fuml. In

International conference on software language engi-

neering, pages 56–75. Springer.

Moawad, A., Hartmann, T., Fouquet, F., Nain, G., Klein,

J., and Le Traon, Y. (2015). Beyond discrete mod-

eling: A continuous and efﬁcient model for iot. In

Conf. Model Driven Engineering Languages and Sys-

tems (MODELS), pages 90–99.

Patni, H., Henson, C., and Sheth, A. (2010). Linked sensor

data. In 2010 International Symposium on Collabora-

tive Technologies and Systems, pages 362–370. IEEE.

Peltonen, J. and Selonen, P. (2001). Processing uml models

with visual scripts. In Proceedings IEEE Symposia on

Human-Centric Computing Languages and Environ-

ments (Cat. No. 01TH8587), pages 264–271. IEEE.

Raj, P. and Surianarayanan, C. (2020). Digital twin: the

industry use cases. In Advances in Computers, volume

117, pages 285–320. Elsevier.

Salay, R. and Chechik, M. (2013). Supporting agility in mde

through modeling language relaxation. In XM 2013–

Extreme Modeling Workshop, page 21. Citeseer.

Singh, S., Shehab, E., Higgins, N., Fowler, K., Reynolds,

D., Erkoyuncu, J. A., and Gadd, P. (2020). Data man-

agement for developing digital twin ontology model.

Proc. of the Institution of Mechanical Engineers.

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

ible modelling framework. FlexMDE@ MoDELS,

1694:42–51.

Zarwin, Z., Bjekovic, M., Favre, M., Sottet, J.-S., and

Proper, H. (2014). Natural modelling. Journal of Ob-

ject Technology, 13:4–1.

Zolotas, A., Matragkas, N., Devlin, S., Kolovos, D. S.,

and Paige, R. F. (2019). Type inference in ﬂexi-

ble model-driven engineering using classiﬁcation al-

gorithms. Software & Systems Modeling, 18(1):345–

366.

Towards a Lightweight Model-driven Smart-city Digital Twin

327