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

Keywords:

Connected Vehicles, Digital Twin, Internet of Vehicles, Autonomous Driving.

Abstract:

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 trafﬁc. By doing so, vehicles can notify other vehicles of hazardous

driving conditions, accidents, or trafﬁc 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 ﬁrst 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.

1 INTRODUCTION

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 trafﬁc 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 trafﬁc 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 trafﬁc 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 difﬁcult task, besides for le-

gal and psychological reasons, also due to the high

Assigned priority

Planned turning direction

Roadside

intersection

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

189

paper. We deﬁne 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 trafﬁc 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 ﬁrst 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.

2 EXEMPLARY SCENARIO

In this section, we introduce a exemplary scenario,

which serves as foundation for the concepts of our

paper. The goal is increasing time efﬁciency of traf-

ﬁc 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, trafﬁc light systems or static rules would now

have to be applied. In IoV, on the other hand, an

RSU may regulate trafﬁc by giving priority to vehi-

cles entering the intersection. This way, it is possible

to use the exchanged sensor data to regulate trafﬁc

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 trafﬁc 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

intersection.

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 trafﬁc 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

requirements.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

190

3 RELATED WORK

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 speciﬁcation 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, identiﬁcation, 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

Adapter

Watcher 1

Adapter 2Adapter 1 Adapter 3

Adapter

Watcher 2

Communication Layer

Adapter

Manager

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 trafﬁc 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 speciﬁcally 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 DIGITAL TWIN FOR

CONNECTED VEHICLES

4.1 Framework

An exemplary digital twin based on our proposed

framework is depicted in Figure 2. The general struc-

ture is inﬂuenced 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 trafﬁc 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-deﬁned interface.

Towards a Digital Twin Framework for Connected Vehicles

191

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 ﬂeet management. In our ex-

emplary scenario, it would be possible that some con-

nected vehicles interact with a cloud analyzing trafﬁc

patterns. If a vehicle registers a delay at the intersec-

tion, other members of a ﬂeet can be notiﬁed of the

delay and may be able to search for a more efﬁcient

route. Such a system should be realized using a CF.

4.1.2 Adapter

An Adapter enables devices to communicate using a

speciﬁc interface. This interface is unambiguously

deﬁned and based on messages. It characterizes how

devices can interact with each other and is identiﬁed

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 deﬁned 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

trafﬁc 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 notiﬁcations 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

192

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 speciﬁc

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 identiﬁers are used to

make intentions and data unambiguous.

When receiving a message, the CL is tasked with

forwarding it to its speciﬁed 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 speciﬁc 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 fulﬁll 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 fulﬁlled. When these

attributes are deﬁned, 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 speciﬁc 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 conﬁguration 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 trafﬁc 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 ﬁrst to bring new

features on the market or react to a change in demand.

Towards a Digital Twin Framework for Connected Vehicles

193

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 deﬁned 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 ﬁrst 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 deﬁned. 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 bugﬁxing easier. Especially

in the domain of connected vehicles, this is very valu-

able, as identiﬁers can be understood across differ-

ent developer teams. The information about the con-

crete structure of the messages is ﬁxed 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 ﬁnd 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 ﬁeld indicating its type. This is

used by AMs to determine the format of the rest of

the message. Depending on the type, different ﬁelds

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

194

{

” 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 Trafﬁc Participants

In addition to vehicles, other entities/trafﬁc partici-

pants are to be considered as well. These include

(but are not limited to) pedestrians, trafﬁc 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 trafﬁc participants of these options.

5 PROTOTYPICAL VALIDATION

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 ﬁtting 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 conﬁgure the pro-

totype instances to react differently to certain events.

This makes it possible to show interactions between

digital twins with varying behavior. The conﬁguration

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

195

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 efﬁciency.

6 SUMMARY AND OUTLOOK

In this paper, we present a ﬁrst 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.

REFERENCES

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., Knaﬂa, 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.

Bitkom/VDMA/ZVEI.

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:

//www.plattform-i40.de/IP/Navigation/EN/

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.

Springer.

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

196