Towards a Digital Twin Framework for Connected Vehicles
Jan Gerhards, Tim Schneider and Pascal Hirmer
Institute for Parallel and Distributed Systems, University of Stuttgart, 70567 Stuttgart, Germany
Connected Vehicles, Digital Twin, Internet of Vehicles, Autonomous Driving.
In the last decade, vehicles have become more and more sophisticated in terms of automated driving assistance
systems, safety systems, such as sleep detection, or infotainment. These systems are enabled through a grow-
ing amount of sensors and actuators built into modern vehicles, including cameras, GPS, distance sensors, or
collision detection sensors, each controlled by a growing number of ECUs. Using the data generated by these
vehicles, new applications can be developed, the most promising being autonomous driving. However, be-
sides the sensing capabilities, e.g., to detect other vehicles or pedestrians, it is also necessary to provide a high
interconnection of multiple vehicles in traffic. By doing so, vehicles can notify other vehicles of hazardous
driving conditions, accidents, or traffic jams, leading to an Internet of Vehicles. Yet, ensuring a reliable and
uniform communication and coordination of multiple heterogeneous vehicles from different manufacturers
is a challenging task. In this paper, we introduce a first approach for a digital twin framework intended for
connected vehicles. It enhances connected vehicles with an administration shell, making it possible for them
to be recognized by other vehicles and to communicate with them.
In recent years, modern vehicles have become more
and more intelligent due to a growing amount of Elec-
tronic Control Units (ECU) as well as built-in sensors
and actuators, including internal and external cam-
eras, pedestrian detection sensors, distance sensors,
sleep detection sensors, and so on (Coppola and Mori-
sio, 2016). These high sensing and acting capabil-
ities form the foundation for new applications, such
as autonomous or semi-autonomous vehicles (Gerla
et al., 2014; Mariani and Zambonelli, 2020), increas-
ing the safety and comfort of passengers, pedestri-
ans, and other traffic participants (e.g., bicycles or
motorcycles). However, in order to fully utilize the
capabilities of a single vehicle, it is also vital to en-
able communication and interconnection with other
vehicles, pedestrians, and road infrastructure, such
as traffic lights (Coppola and Morisio, 2016). In
addition, Road-side Units (RSU) can serve as com-
munication hubs, offer data pre-processing capabili-
ties, or provide information to vehicles, e.g., weather
or traffic information (cf. Figure 1). However, en-
abling modern applications in the Internet of Vehi-
cles (IoV) (Coppola and Morisio, 2016), such as au-
tonomous driving, is a difficult task, besides for le-
gal and psychological reasons, also due to the high
Assigned priority
Planned turning direction
control unit
Figure 1: Example of a cooperative intersection manage-
ment system.
heterogeneity regarding software and hardware com-
ponents, or communication protocols. Furthermore,
legacy vehicles, providing no interconnection or so-
phisticated sensing and acting capabilities, further in-
crease the already high complexity.
In order to build modern IoV applications, it is
necessary to create a digital representation of the
physical world, including all involved connected and
non-connected vehicles, pedestrians, and infrastruc-
ture components.
This digital representation is called the digital
twin (Alam and El Saddik, 2017) in the scope of this
Gerhards, J., Schneider, T. and Hirmer, P.
Towards a Digital Twin Framework for Connected Vehicles.
DOI: 10.5220/0011066600003194
In Proceedings of the 7th International Conference on Internet of Things, Big Data and Security (IoTBDS 2022), pages 189-196
ISBN: 978-989-758-564-7; ISSN: 2184-4976
2022 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
paper. We define the digital twin as a geographically
independent software representation of a physical ob-
ject. The digital twin is an essential concept to realize
new applications for connected vehicles, such as au-
tonomous driving.
In this paper, we introduce a framework for a dig-
ital twin of connected vehicles. It equips different
connected vehicles or other traffic participants with an
administration shell, making it possible for them to be
recognized and considered by each other, and further-
more, to communicate with others to share informa-
tion or warn about dangerous situations. By doing so,
the high heterogeneity of the different involved enti-
ties can be abstracted and an intercommunication can
be facilitated. We validate our approach by a exem-
plary scenario, a list of requirements, as well as a pro-
totypical implementation serving as proof-of-concept.
The main contributions of this paper are: (i) a list
of requirements, derived from an exemplary scenario,
(ii) a generic digital twin framework, and (iii) a proof-
of-concept implementation of our exemplary scenario
for validation purposes.
The remainder of this paper is structured as fol-
lows: In Section 2, we first introduce an exem-
plary scenario, which serves as foundation for our
approach. Section 3 then describes related work. In
Section 4, our main contribution is described – a dig-
ital twin framework for connected vehicles. Section 5
then describes our prototype and Section 6 summa-
rizes our paper and gives an outlook on future work.
In this section, we introduce a exemplary scenario,
which serves as foundation for the concepts of our
paper. The goal is increasing time efficiency of traf-
fic at intersections using IoV technologies. The sce-
nario is depicted in Figure 1. Four cars are about to
pass through an intersection with overlapping planned
turning directions. In a world without connected ve-
hicles, traffic light systems or static rules would now
have to be applied. In IoV, on the other hand, an
RSU may regulate traffic by giving priority to vehi-
cles entering the intersection. This way, it is possible
to use the exchanged sensor data to regulate traffic
optimally. Beside priorities, this can be achieved by
providing vehicles with concrete instructions for ac-
tions, such as their ideal speed. The RSU can also be
used as a connection point to a cloud or fog comput-
ing component that, for example, may have an overall
view of the total traffic situation of a city.
An optimization applied in the scenario could be
that the car coming from the right gets priority over
the car coming from the top due to being closer to the
The car coming from the left can already prepare
the turn, while the prioritized car is crossing the inter-
section. Therefore, the car coming from the top gets
the lowest priority and is instructed to reduce its speed
so that it only arrives at the intersection when all other
cars have already passed.
Based on this exemplary scenario, we derived sev-
eral nonfunctional requirements that need to be con-
sidered by digital twin framework. These require-
ments are: (i) high scalability, (ii) coping with hetero-
geneity, (iii) high extensibility, and (iv) robustness.
First, since the scenario’s environment is very dy-
namic in the sense of constantly entering and leaving
vehicles, scalability is an important issue. The dig-
ital twin framework needs to be able to cope with a
strong increase in vehicles, pedestrians, and other en-
tities without causing latency issues or bottlenecks.
Second, it is of vital importance to cope with a
high level of heterogeneity. Each vehicle manufac-
turer may use different technologies and standards.
Furthermore, besides the intercommunication of ve-
hicles, communication with other entities may also
be required. In our scenario, this would be the RSU
controlling priorities or smart phones of pedestrians
planning to cross the intersection.
Third, the framework needs to be extensible to in-
tegrate new hardware and software technologies or
network protocols. This ensures that all involved sce-
nario entities are always able to communicate with
each other.
Finally, we aim at ensuring a high degree of
robustness, since IoV environments are considered
safety critical. Hence, failing or leaving entities need
to be discovered and their surroundings need to be in-
formed in a timely manner. In our scenario, the fail-
ure of an entity’s communication component must be
communicated to the RSU aiming to give this vehicle
the right of way preemptively or, in case of doubt, to
indicate that conservative traffic rules should be ap-
plied. We are aware that security and privacy are also
important requirements for such scenarios. However,
due to the limited scope of this paper, we do not focus
on them.
The aforementioned requirements aim for a so-
lution in the context of IoV scenarios. Since many
different actors have to communicate with each other
in IoV, these requirements are intended to be rather
generic. Therefore, the solution proposed in the paper
can also be applied to other domains that have similar
IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security
A similar concept to our approach is the Asset Admin-
istration Shell (AAS) (I4.0, 2021), which is mostly
applied in Industrie 4.0. The AAS was introduced in
2015 as part of the Reference Architecture Model for
Industrie 4.0 (Boss et al., 2020). Since its introduc-
tion, AAS was often subject of further discussion and
its specification was improved multiple times.
According to Dorst et al. (Dorst et al., 2016), In-
dustrie 4.0 components can be based on objects with
at least passive communication ability”. The inten-
tion of the AAS is to turn[...] an object into an
Industrie 4.0 component”. In order to achieve this,
an administration shell is used to surround an ob-
ject. Communication between the AAS and the object
uses an internal interface that can be manufacturer-
dependent. A standardized external interface is used
by the AAS to manage the communication with other
systems. Both interfaces in combination make the
concept of AAS able to be standardized, while still
being able to support different functionalities of an
entity (Tantik and Anderl, 2017).
The AAS structure contains a body and a header.
A manifest is a part of the header and contains im-
portant administrative information regarding commu-
nication, identification, and functionality. Addition-
ally, it contains an index of submodels, which to-
gether with a component manager make up the body
of the AAS and characterize the associated asset. The
body of contains the component manager, which is
an interface whose main functionality is accessing the
payload of the submodels (Tantik and Anderl, 2017).
Submodels are meant to be standardized accord-
ing to certain characteristics. Every single one should
represent an aspect of the asset. The general idea is
to include multiple submodels in an AAS, making it
possible to represent different aspects of an asset. If
a submodel is available within the body of an AAS,
it can be assumed that some relevant properties are
available (Bedenbender et al., 2017).
In summary, the AAS has been explored in-
tensely in the context of the manufacturing industry.
Within the domain of connected (and possibly au-
tonomous) vehicles, however, only few concepts re-
garding framework of a digital twin are available. In-
stead, it is important to note ways in which vehicles
may communicate in the future and what informa-
tion needs may arise. Two important concepts are the
Vehicular ad hoc Network (VANET) and the Vehicu-
lar Cloud, which are discussed by Gerla et al. (Gerla
et al., 2014). This shows that connected vehicles may,
in theory, be capable of collaborating and acting as in-
telligent agents.
Functionality Core
Watcher 1
Adapter 2Adapter 1 Adapter 3
Watcher 2
Communication Layer
Figure 2: Example instance of a digital twin.
A different concept illustrating possibilities of this
domain is proposed by Mariani and Zambonelli (Mar-
iani and Zambonelli, 2020). In it, the authors dis-
cuss using different levels of autonomy depending on
the current traffic situation. When using this con-
cept, connected vehicles may have different informa-
tion needs during operation, depending on the cur-
rently chosen level of autonomy. Therefore, a digital
twin has to take into account changing information
and communication needs, which are not known at
the beginning of a route.
Our concept aims to consider the wide variety
of approaches proposed for connected vehicles. The
goal is to provide a reference framework for a digi-
tal twin designed specifically to handle relevant com-
plexities. Elements of this framework are based on
ideas related to AAS. Especially the use of different
submodels for providing information relevant to sep-
arate aspects is interesting for us. Our concept com-
bines this approach with the possibility to manage a
digital twin in a constantly changing environment.
4.1 Framework
An exemplary digital twin based on our proposed
framework is depicted in Figure 2. The general struc-
ture is influenced by the AAS. A digital twin should
be able to support multiple interfaces at the same time.
These have to be managed according to current in-
formation needs and the state of the environment. In
addition, the framework includes components capa-
ble of providing functionality and data that is relevant
to other traffic participants. To achieve this, our ap-
proach revolves around different Adapters which are
managed by an Adapter Manager and make function-
alities contained in a Functionality Core accessible
using a well-defined interface.
Towards a Digital Twin Framework for Connected Vehicles
4.1.1 Functionality Core
The Functionality Core (FC) is the part of the digital
twin that contains data and functionality concerning
the vehicle and its environment. Any logic required
to obtain, process, and store data (like sensor han-
dlers) is part of the FC. If decision-making is avail-
able for the vehicle (e.g., for autonomous driving),
any relevant logic is encapsulated within this compo-
nent. Furthermore, software used to control the ve-
hicle itself (e.g., cruise control, high beam control) is
also part of the FC.
The internal structure of the FC is mainly a black
box in order to allow developers to use approaches
they prefer when implementing logic used to control
a vehicle. Communication partners of the digtal twin
are not able to communicate with the FC directly. In-
stead, they use interfaces provided by Adapters.
If developers choose to include cloud infrastruc-
ture (e.g., for processing or communication), the FC
is divided into a Local Fragment (LF) and any num-
ber of Cloud Fragments (CF). The latter are an ab-
straction for cloud interfaces the vehicle hardware in-
teracts with. In order to account for data exchange of
different systems located in a cloud environment, CFs
are allowed to communicate with each other. A no-
table use case for CFs is fleet management. In our ex-
emplary scenario, it would be possible that some con-
nected vehicles interact with a cloud analyzing traffic
patterns. If a vehicle registers a delay at the intersec-
tion, other members of a fleet can be notified of the
delay and may be able to search for a more efficient
route. Such a system should be realized using a CF.
4.1.2 Adapter
An Adapter enables devices to communicate using a
specific interface. This interface is unambiguously
defined and based on messages. It characterizes how
devices can interact with each other and is identified
by a unique ID.
Different kinds of Adapters can be used by the
digital twin. They can be capable of connecting not
only to nearby connected vehicles, but also other
types of devices. For example, in our scenario, an
interface has to be defined for communication with
RSUs. These could then be used by connected vehi-
cles to simplify assignment of priorities at intersec-
tions. An Adapter always offers exactly one interface
and transforms calls to it into instructions for the FC.
This means that an Adapter bridges the black-box im-
plementation of the FC and a known standardized in-
terface, thereby enabling cooperation with other par-
ticipants. Since all data used by Adapters is stored in
the FC, the state of an Adapter consists only of infor-
mation on currently available quality of service (QoS)
attributes or communication channels.
When two digital twins include the same Adapter,
they are able to communicate using its associated in-
terface. One advantage of this approach is that a dig-
ital twin can provide multiple Adapters, which may
be active at the same time. As a consequence, the
connected vehicle will be able to exchange informa-
tion and coordinate with different devices in differ-
ent ways. Furthermore, it is possible to communi-
cate with the same device using multiple Adapters.
This enables the use of different interfaces at the same
time. An example for such a use case may be that two
cars use one Adapter for coordinating their relative
speed, while simultaneously sharing information on
traffic conditions using another.
4.1.3 Adapter Watcher
Adapter Watchers (AWs) are components responsible
for observing the operation of Adapters. In order to
achieve this, every Adapter is associated with exactly
one AW. As shown in Figure 2, an AW may be con-
nected with multiple Adapters at the same time. This
may be advantageous if very similar Adapters are pro-
vided by the digital twin. One of the main tasks of
AWs is to route outgoing messages of their Adapters
to appropriate communication channels. This re-
quires AWs to evaluate which channels may be used
by which Adapter when communicating with which
partner. Furthermore, QoS attributes may have to be
taken into consideration when choosing a communi-
cation channel. While a connection is active, the AW
of an Adapter may analyze messages in order to gain
information about its state. This includes the outgo-
ing messages sent by the Adapter as well as incom-
ing messages sent by its communication partner. In
addition to analyzing them, an AW may modify the
content of a message, e.g., if an Adapter expects to
receive only application layer data, its associated AW
may remove all other layers from a message.
Another way for the AW to collect information
about an Adapter is by receiving it directly, e.g., in
case of an error. These notifications are then aggre-
gated with the data gained through message analy-
sis. Based on this, the AW is able to provide data
to the Adapter Manager on request or by notifying it
directly. In our scenario, this is how digital twins are
able to detect that a vehicle is no longer communicat-
ing. If no more messages are sent, AWs pick up on
this and initiate their digital twins’ responses.
Finally, an AW is able to send commands to its as-
sociated Adapters. As Adapters store only little data
and should be based mainly on the state of the FC,
IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security
these controls are very limited. An example of a use
case for them is turning the Adapter on and off.
4.1.4 Communication Layer
The Communication Layer (CL) is the component of
the digital twin that makes it possible to exchange
messages with other devices. Any software compo-
nent used to transmit or receive information is part of
it. Internally, the CL is a collection of various com-
munication channels. Each of these channels is capa-
ble of sending or receiving messages using a specific
protocol and technology. For example, there may be
a communication channel capable of exchanging in-
formation via 5G and another using LoRa. To iden-
tify different channels, a unique character sequence is
used. When digital twins exchange information about
communication channels, these identifiers are used to
make intentions and data unambiguous.
When receiving a message, the CL is tasked with
forwarding it to its specified destination. If no con-
nection for the recipient exists, the Adapter Manager
is informed. In order to decide which message should
be passed to which component, the CL is informed
about existing connections. This includes informa-
tion on which communication channels have been as-
signed to which Adapters and partners. A situation
illustrating this idea can occur when a digital twin
communicates with a partner using multiple Adapters.
Depending on existing connections, a communication
channel may pass on messages sent by the partner and
addressed to a specific Adapter. However, those spec-
ifying a different destination may not be forwarded if
the CL was not informed that the channel can also be
used for this other Adapter.
In the context of connected vehicles, communi-
cation has to fulfill various different requirements.
Some examples for these are reliability and latency
characteristics. However, it is not possible to make
any guarantees based on the architecture of the frame-
work. Instead, the developer implementing a com-
munication channel for use in the framework has to
make sure all requirements are fulfilled. When these
attributes are defined, the framework is able to take
them into account. Adapter Watchers should route
messages to an appropriate communication chan-
nel based on QOS attributes requested for messages
by the Adapters sending them. Furthermore, the
Adapter Manager can consider the different guaran-
tees of available communication channels when de-
ciding which channels should be used to establish a
connection. This way, the framework can include
handling of QOS of communication channels, even
though the guarantees have to be made by communi-
cation channels and their developers.
4.1.5 Adapter Manager
The component controlling Adapters and connections
of the digital twin is the Adapter Manager (AM). Its
main task is the communication with AMs of other
digital twins. Together, they decide which Adapters
and communication channels to use. In order to do
this, the AM is aware of the available Adapters. It
is able to prioritize them based on static knowledge
(e.g., their optimal use case) as well as the current
state of the digital twin (e.g., number of currently on-
going connections using a specific Adapter).
During operation, the AM keeps track of connec-
tions and can react to events that might arise. For ex-
ample, in our exemplary scenario, an AM may ask
other AMs to connect an Adapter able to coordinate
a reaction to a vehicle that stopped communicating.
To command other parts of the digital twin, the AM
is connected to the CL and all AWs. Adapters can be
controlled indirectly via their associated AW.
Furthermore, the AM is connected to the FC. This
connection is bidirectional, meaning the AM can re-
quest information from the FC and vice versa. The
AM uses this connection to gain information on the
state of the environment and the vehicle in order to de-
termine the optimal configuration regarding the con-
nections of the digital twin. This includes both the
Adapters and communication channels used as well as
with which digital twins connections should be estab-
lished. Additionally, the FC is able to request infor-
mation from the AM. For example, the amount of on-
going connections may be a relevant data point when
trying to assess traffic density.
4.2 Goal of the Framework
The main goal of our framework is to isolate logic re-
garding the vehicle and its environment in the FC and
allow access using different interfaces. An advantage
of this approach is that it is possible to support dif-
ferent concepts using Adapters. The FC can be im-
plemented independently of concepts used by inter-
faces provided to other digital twins, while Adapters
include logic to transform the internal view into one
compatible with their respective interfaces. In addi-
tion, different communication channels and CFs al-
low for different modes of communication. Further-
more, it is possible to develop Adapters and com-
munication channels independently of one another.
This facilitates separate development of different in-
terfaces and technologies in short cycles. In the con-
text of this domain, vehicle manufacturers could use
this to their advantage by being the first to bring new
features on the market or react to a change in demand.
Towards a Digital Twin Framework for Connected Vehicles
Communication is possible on two different levels
using the proposed framework. First, a connected ve-
hicle should be able to exchange messages with other
devices in its vicinity. This is possible using the CL.
It contains communication channels, which support
different technologies used to communicate to other
devices. The use of these channels is managed by the
AM, which matches channels and Adapters together
based on compatibility and other factors. Second,
communication with cloud infrastructure is also pos-
sible using the framework. This is done by allowing
for communication with a system located in a cloud
as part of the FC. Internally, its CFs are used to model
a connection to an outside system related to the con-
nected vehicle.
4.3 Digital Twin Communication
The interaction of digital twins using this framework
is based on messages. This allows use of a variety
of technologies and approaches for Adapters. AMs
also communicate based on messages. Every digi-
tal twin receives messages using its CL, which dis-
tributes them to the appropriate component.
Furthermore, communication between Adapters
of digital twins is based on messages. This is done in
an effort to keep the concept simple while still allow-
ing for all methods of remote communication to be
applicable. Using, e.g. RPC, an Adapter implement-
ing this concept would have to transform messages
into the provided calls. Then, it would use FC calls to
receive a result and return it using RPC messages.
The AM is responsible for managing the connec-
tions a digital twin engages in. This includes deci-
sions, such as with which devices a connection should
be established and which Adapters should be used.
All coordination with other digital twins takes place
using the messages defined for the AM. As a way to
react to changes of the environment, the AM is able
to communicate with the FC. Since the AM does not
contain information on the state of the environment,
this connection is used to assess the need for differ-
ent connections and connection partners. Vice versa,
it is possible for the FC to request data on the aspects
managed by the AM, if this is needed for its operation.
Apart from the FC, the AM is also in contact with all
AWs and the CL. This enables it to receive informa-
tion on other aspects of the digital twin, which can be
considered in its decision-making.
4.3.1 Message Format
When a digital twin receives a message, it has to de-
termine both the sender and the addressed component.
This is necessary in order to check if the use of the
communication channel is allowed or if the message
is invalid. The first 128 bits of a message are an ID
used to identify the sender. Every device has a unique
ID enabling digital twins to quickly recognize each
other. After the sender ID, another 64 bits are used
to identify the target Adapter. For every Adapter, a
unique ID is defined. This makes it possible to pass
messages on to the interface they are designated for.
If the target is the AM, the Adapter ID is 0.
After these two IDs, the actual message content
begins. This can include any number of bits in any
format, though, this may depend on the communi-
cation channel. The goal of this approach is to give
extensive freedom to developers regarding the struc-
ture and content of messages they use. Consequently,
many different data formats can be used for interfaces
implemented by Adapters.
4.3.2 Adapter Manager Messages
Messages that can be processed by the AM are called
Adapter Manager Messages (AMM). An example for
such a message can be seen in Listing 1. In our proto-
type, AMMs are encoded in JSON using UTF-8. The
reason for this is that a human-readable message for-
mat makes logging and bugfixing easier. Especially
in the domain of connected vehicles, this is very valu-
able, as identifiers can be understood across differ-
ent developer teams. The information about the con-
crete structure of the messages is fixed in our proto-
type, however, it could also be derived by underlying
knowledge models, e.g., using JSON-LD.
Overall, a format other than JSON could be cho-
sen if the framework is to be used in practice. How-
ever, it is important that every digital twin instance
uses the same format for AMMs.
In order to check which messages should be pro-
cessed, a sequence count is used. Since no guarantees
regarding the order of arrival of messages has to be
made for AMMs, the AM has to account for them ar-
riving out of order. In these cases, the sequence num-
ber in conjunction with the content of a message can
be used to find out if it should still be processed.
For example, if a message arrived with a re-
quest contradicting a message with a higher sequence
count, the earlier message would be ignored. Every
AMM contains a field indicating its type. This is
used by AMs to determine the format of the rest of
the message. Depending on the type, different fields
are included containing the required parameters. Fur-
thermore, depending on the state of the connection,
an AM may be able to immediately recognize invalid
requests based on their type.
IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security
i d : 472656947346 ,
s e q u e n c e : 3 ” ,
t y p e ” : ” c o n n e c t ” ,
” v e r s i o n : 1 . 2 . 3 ,
” a d a p t e r s : [
1 0 0” ,
7 ” ,
3 89 ]
Listing 1: Example AMM.
4.3.3 Including Other Traffic Participants
In addition to vehicles, other entities/traffic partici-
pants are to be considered as well. These include
(but are not limited to) pedestrians, traffic adminis-
trators, or road operators. In our exemplary scenario,
the RSU is an example of such a participant. Further-
more, computing-related entities, such as (edge)cloud
servers, may be relevant. These entities can also be
represented using the introduced framework as long
as they are able to communicate. For example, pedes-
trians may use their smart phones to exchange infor-
mation and coordinate with their surrounding.
In addition to participants being included using
their own digital twin, CFs can be used to connect
stakeholders to digital twins using a static interface.
Especially large systems which use a well-known in-
terface for communication can provide a CF to ex-
change data with many digital twins. Using this data,
it may then be possible to determine optimizations
and inform traffic participants of these options.
One of the goals of the prototype was to demon-
strate how to incorporate cloud environments into
the framework. In order to achieve this, the Multi-
purpose Binding and Provisioning Platform (MBP)
was used to provide such an environment. This is
an IoT platform introduced by Franco da Silva et
al. (Franco da Silva et al., 2020). The reason for
choosing the MBP is its ability to display complex
JSON objects. As the AMMs are formatted in JSON,
including MBP is very simple and reduces the over-
all complexity of the digital twin. We used JSON in
our prototype, since we consider it a fitting format
for exchanging messages among the involved entities.
However, it is important to note that other data for-
mats could also be used, depending on the scenario
our framework is applied to, as long as the format is
uniform and all involved entities agree on using it.
The digital twin itself was implemented using the
programming language Python, mainly due to its na-
tive JSON support. A VM running Ubuntu was cho-
sen as the environment in which the digital twin in-
stances were run. In order to show how digital twins
interact, multiple instances of the same code were ex-
ecuted. These instances then exchanged messages
with each other. It is possible to configure the pro-
totype instances to react differently to certain events.
This makes it possible to show interactions between
digital twins with varying behavior. The configuration
and other commands are controlled using a command
line interface. As a way to illustrate how CFs work,
the MBP instance runs on a different system than the
rest of the digital twin. In our implementation, a Win-
dows computer was used to install and execute MBP.
5.1 Implementation of the Scenario
In our exemplary scenario, different vehicles should
coordinate at an intersection. In order to achieve this,
all participants have to provide Adapters which make
the exchange of relevant information possible. In the-
ory, vehicles may be able to solve this challenge using
only Vehicle-to-Vehicle communication. However, in
this scenario an RSU is utilized as a way to reduce
the amount of connections every vehicle has to main-
tain. Due to this, every digital twin has to implement
at least one Adapter that is also provided by the RSU.
Furthermore, at least one of the communication chan-
nels offered by the RSU has to be implemented in or-
der to exchange messages.
There are some requirements regarding the FC of
participating digital twins. While the way they are im-
plemented can be chosen freely, the necessary func-
tionality has to be included. In our scenario, this is
mainly the ability to coordinate the use of the intersec-
tion. As mentioned in Section 4.1.1, some connected
vehicles may notify a cloud system of waiting times
at intersections. In these cases, the FC has to include
an appropriate CF.
AWs are used to oversee the state and operation of
Adapters. In our scenario, this may be used to recog-
nize vehicles that stopped communicating. If a digital
twin does not send messages, AWs of its communica-
tion partners will be able to pick up on that by stop-
ping the time they last received a message. If a certain
threshold is passed, the AW may inform the AM, who
can then react to the problem. For example, present
vehicles may connect using an Adapter to communi-
cate about the erroneous participant and how to be-
have in a safe manner while still trying to minimize
waiting times.
Towards a Digital Twin Framework for Connected Vehicles
5.2 Validation
The proposed framework supports loose coupling be-
tween components. This makes it possible to extend
a digital twin without a large amount of effort. Fur-
thermore, Adapters and communication channels as
used in the framework make it possible to cope with
a highly dynamic environment, such as the one con-
nected vehicles operate in. As different interfaces
can be used in different situations and a multitude of
communication technologies can be supported, het-
erogeneity may even become an asset for developers
using the concept. For example, a digital twin imple-
menting many different Adapters may be able to more
appropriately react to a given situation. Also, differ-
ent communication technologies can be used based on
the current requirements.
Apart from supporting connections with devices
in the vicinity of a vehicle, this framework also al-
lows for parts of a digital twin to be located in the
cloud. This supports many different approaches, for
example, ones which rely on large processing power
of powerful machines in the cloud. Other cloud ap-
plications can also be included, for example a cloud
solution which receives vehicle data and makes it ac-
cessible to the owner using a mobile app.
In addition to interoperability, a big advantage of
the FC being used to encapsulate the internal logic
and decision-making is the improved adaptability. As
long as the interface provided for Adapters supports
the required functionalities, little to no changes are
expected to be necessary when adding new Adapters.
Hence, a FC may be used for a long time without go-
ing out of date. Even if other technology for com-
munication or interfaces become popular, logic in
Adapters can be used to bridge old and new interfaces.
Furthermore, the FC can be upgraded indepen-
dently of Adapters and communication channels.
This enables developers to use new concepts in the in-
ternal logic. If older interfaces would normally not be
compatible with them, Adapters can be used to trans-
form the data as necessary. As a consequence, it is
possible to improve the internal logic of the FC with-
out affecting the interfaces provided to communica-
tion partners. This can be used, e.g., to prepare for
the introduction of new features or to improve inter-
nal efficiency.
In this paper, we present a first approach of a digital
twin framework, which can be applied to various sce-
narios, e.g., in the IoV. An exemplary scenario serves
as a foundation for a list of requirements of the digi-
tal twin we aim for. Based on these requirements, we
introduce our framework and show how communica-
tion can be enabled among heterogeneous vehicles.
We validate our approach based on a prototypical im-
plementation of our exemplary scenario.
We are aware that security and privacy are core
aspects of such architectures. Due to the limited scope
of this paper, this is not discussed here and is part of
our future work. Another issue which could be added
is the discovery of devices by the digital twin.
Alam, K. M. and El Saddik, A. (2017). C2ps: A digital
twin architecture reference model for the cloud-based
cyber-physical systems. IEEE access, 5:2050–2062.
Bedenbender, H., Billmann, M., Epple, U., Hadlich, T.,
Hankel, M., Heidel, R., Hillermeier, O., Hoffmeis-
ter, M., Huhle, H., Jochem, M., et al. (2017). Ex-
amples of the asset administration shell for industrie
4.0 components–basic part. ZVEI white paper.
Boss, B., Malakuti, S., Lin, S., Usl
ander, T., Clauer, E.,
Hoffmeister, M., and Stojanovic, L. (2020). Digital
twin and asset administration shell concepts and ap-
plication in the industrial internet and industrie 4.0.
Plattform Industrie, 4.
Coppola, R. and Morisio, M. (2016). Connected car: tech-
nologies, issues, future trends. ACM Computing Sur-
veys (CSUR), 49(3):1–36.
Dorst, W., Glohr, C., Han, T., Knafla, F., Loewen, U.,
Rosen, R., Schiemann, T., Vollmar, F., and Winter-
halter, C. (2016). Implementation strategy industrie
4.0-report on the results of the industrie 4.0 platform.
Franco da Silva, A. C., Hirmer, P., Schneider, J., Ulusal,
S., and Frigo, M. T. (2020). MBP: Not just an iot
platform. In 2020 IEEE International Conference
on Pervasive Computing and Communications Work-
shops (PerCom Workshops), pages 1–3. IEEE.
Gerla, M., Lee, E.-K., Pau, G., and Lee, U. (2014). Internet
of vehicles: From intelligent grid to autonomous cars
and vehicular clouds. In 2014 IEEE world forum on
internet of things (WF-IoT), pages 241–246. IEEE.
I4.0, P. (2021). Industrie 4.0 glossary. https:
Industrie40/Glossary/glossary.html. [Online; ac-
cessed 16-September-2021].
Mariani, S. and Zambonelli, F. (2020). Degrees of au-
tonomy in coordinating collectives of self-driving ve-
hicles. In International Symposium on Leverag-
ing Applications of Formal Methods, pages 189–204.
Tantik, E. and Anderl, R. (2017). Integrated data model and
structure for the asset administration shell in industrie
4.0. Procedia Cirp, 60:86–91.
IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security