Cooperative Driving in Mixed Trafﬁc with Heterogeneous

Communications and Cloud Infrastructure

Rico Auerswald

1 a

, Roman Busse

, Markus Dod

3 b

, Richard Fritzsche

, Alexander Jungmann

Michael Kl

oppel-Gersdorf

1 c

, Josef F. Krems

, Sven Lorenz

3 d

, Franziska Schmalfuß

Sabine Springer

and Severin Strobl

1 e

Fraunhofer IVI, Fraunhofer Institute for Transportation and Infrastructure Systems, Dresden, Germany

IAV GmbH, Chemnitz, Germany

Mugler AG, Oberlungwitz, Germany

Chemnitz University of Technology, Cognitive and Engineering Psychology, Chemnitz, Germany

Keywords:

Cooperative Driving, Mixed Trafﬁc, Hybrid Communication, HMI Design, Modular System Concept,

ITS-G5, C-V2X, Cloud Computing.

Abstract:

In this paper we introduce an Intelligent Transport System (ITS), designed for enabling cooperative driving

manoeuvres in mixed trafﬁc scenarios considering heterogeneous communications and cloud infrastructure

systems. We present an architecture that enables connected vehicles to access ITS services independent of

their underlying communication technology. This is achieved by introducing a large scale communication

system including the road-side infrastructure as well as a heterogeneous cloud. We present insights from the

Automated Connected Vehicle (ACV) concept and examine human factors elaborating on the experience of

two aspects: driving in an ACV as well as driving in a Non-Automated Connected Vehicle (NACV), interacting

with an ACV. Furthermore, we present insights of initial demonstrations, emphasizing that the system works

well in real trafﬁc scenarios.

1 INTRODUCTION

Automated driving is in the focus of recent research

and development activities in the ITS community, but

also highly present in the media, especially w.r.t. its

target expansion: fully autonomous vehicles. Modern

communication technologies are seen as one of the

main enabler for realizing safety, comfort, and eco-

nomic goals, especially in more complex urban traf-

ﬁc scenarios (Hobert et al., 2015). Since the intro-

duction of automated driving is going to be a grad-

ual process, the majority of the vehicles will not

be equipped with automation technology for several

years. Especially for such mixed trafﬁc scenarios,

inter-vehicle communication is crucial for a seamless

https://orcid.org/0000-0002-5716-7069

https://orcid.org/0000-0003-1084-6088

https://orcid.org/0000-0001-9382-3062

https://orcid.org/0000-0002-7399-163X

https://orcid.org/0000-0002-1636-5368

integration of automated vehicles. On the one hand

inter-vehicle communication in combination with ad-

vanced Human-Machine-Interfaces (HMIs) can sup-

port human drivers in conventional cars by under-

standing the behaviour of automated vehicles, which

can differ from conventional driving behaviours in

speciﬁc situations. On the other hand, communica-

tion could also help the automated vehicle to react

on human driven cars more sensible and foresighted

(Zhang, 2018). In addition to improving acceptance

for Automated Connected Vehicle (ACV), commu-

nication also supports cooperative manoeuvres be-

tween ACV and Non-Automated Connected Vehicle

(NACV), which can help to avoid critical situations

and unnecessary congestions that arise in everyday

trafﬁc.

In order to support vehicles and human drivers in

their decision process, the infrastructure plays a ma-

jor role, e.g., to give neutral recommendations to par-

ticular vehicles or groups of vehicles. While the ad-

vantage of communication is undisputed, the choice

Auerswald, R., Busse, R., Dod, M., Fritzsche, R., Jungmann, A., Klöppel-Gersdorf, M., Krems, J., Lorenz, S., Schmalfuß, F., Springer, S. and Strobl, S.

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure.

DOI: 10.5220/0007682900950105

In Proceedings of the 5th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2019), pages 95-105

ISBN: 978-989-758-374-2

of the actual technology is subject to lively discus-

sions and a clear prospect of a preferred technology

exchanging ITS information is missing. Protocols

and messages designed for exchanging information

among vehicles as well as among vehicles and the in-

frastructure are based on direct communication (Fes-

tag, 2014). While there is a competitive situation

for direct Vehicle-to-Everything (V2X) communica-

tion technologies between IEEE 802.11p and Cellular

V2X (C-V2X), conventional cellular is already imple-

mented in about one third of today’s vehicles (Statista,

2018). Hence, some researchers (Hameed Mir and Fi-

lali, 2014; Cecchini et al., 2017) see advantages in us-

ing current cellular systems, at least for a transition

period.

In this work, we focus on cooperative manoeuvres

among ACVs and NACVs supporting heterogeneous

communication technologies as well as a heteroge-

neous cloud infrastructure.

This paper is structured as follows: First we

present the system concept by introducing the over-

all architecture as well as an exemplary use case. We

give more insights in Sections 3, 4, and 5, by pre-

senting the communications system, the infrastruc-

ture and the vehicle side, respectively. We show an

overview of a ﬁrst live demonstration in Section 6,

before we conclude the work in Section 7.

2 SYSTEM CONCEPT

In the presented system setup, three major compo-

nents are considered: the vehicle, the infrastructure,

and the communication system. The latter connects

vehicles with each other as well as the vehicles with

the infrastructure. The unique feature of the sys-

tem concept is the integration of heterogeneity w.r.t.

all three components. On the vehicle side, ACVs

and NACVs are considered, while for the infrastruc-

ture side a cloud at the Road-Side Units (RSUs) as

well as a central cloud is taken into account. The

exchange of ITS messages is based on either di-

rect Device-to-Device (D2D) communications (e.g.

802.11p, C-V2X), or cellular uplink/downlink com-

munications.

2.1 Architecture

The overall architecture is illustrated in Figure 1. On

the vehicle side the ACV (blue) can execute its ma-

noeuvres fully automated, while it might be beneﬁcial

to inform the passenger about driving decisions. On

the other side, the driver of the NACV (grey) should

be informed about manoeuvres of the ACV, especially

Figure 1: Overall system architecture.

about those not typical for conventional trafﬁc situa-

tions. The cooperation of ACV and NACV is of spe-

cial interest in this work. A speciﬁc use case is de-

scribed in more detail in the next section.

All vehicles, independent of their degree of au-

tomation, can be equipped either with direct commu-

nication units or with both, direct and cellular com-

munication units. Note, that vehicles equipped with

D2D units only, are not considered in this work (cellu-

lar is typically assumed for connectivity to the public

key infrastructure as well as the central cloud).

The vehicles are not just communicating with

each other, but also with the infrastructure in order to

obtain information about, e.g., trafﬁc light phases or

receive support for driving decisions. The heteroge-

neously equipped vehicles are supported by a hetero-

geneous infrastructure. Hence, services provided by

the RSU clouds via direct D2D communication can

also be provided by the central cloud via cellular com-

munication. Moreover, the communication among

vehicles is supported by a geographical messaging

service, which allows distributing messages via the

cellular uplink-downlink in a particular region.

2.2 Use Cases

While a number of cooperative driving use cases are

discussed in the ITS community, we only consider a

selected subset of manouvres as shown in Figure 2.

For the remainder of this section, we focus on the

cooperative turn as an example, as it makes use of a

broad set of architectural features. The scenario con-

sists of an intersection, potentially equipped with traf-

ﬁc lights, while the two main actors are an NACV

(grey vehicle) and an ACV (blue vehicle), both ap-

proaching the intersection from opposite directions.

The trafﬁc light is passed based on Green-Light Op-

timized Speed Advisory (GLOSA) (Kloeppel et al.,

2019). At the intersection, the NACV intends to turn

left, but needs to wait for the ACV. We assume that

there are other vehicles behind both cars (dark grey

vehicles), which makes the situation more relevant,

VEHITS 2019 - 5th International Conference on Vehicle Technology and Intelligent Transport Systems

Figure 2: Example use cases of automated and connected driving: (A) cooperative lane change manoeuvres, (B) cooperative

turn, (C) predictive intersection crossing and trafﬁc light approaching for blocked ﬂow-offs.

due to a noticeable delay for the NACV and all fol-

lowing vehicles.

In order to avoid a blocking, the ACV can coop-

erate by giving up its right of way. Based on com-

munication between the two vehicles but also with

support from the infrastructure, the NACV recognizes

the ACV’s willingness to cooperate and passes the

crossing. For that purpose, we introduce two new

message types. The Maneuver Coordination Message

(MCM) is transmitted form vehicles in order to in-

form about planed and ongoing manoeuvres but also

request manoeuvres from other vehicles. The mes-

sage is currently studied in ETSI ITS standardization,

where several approaches are discussed. Based on

the MCM, we introduce the Maneuver Recommen-

dation Message (MRM), sent out from the infrastruc-

ture side, in order to support vehicles in their driving

decisions.

Based on the cooperative turn, the mean delay

(w.r.t. all involved vehicles) is assumed to be reduced

substantially. Hence, with a large penetration of co-

operatively behaving vehicles, trafﬁc ﬂow can be in-

creased. In the following sections, we show how the

cooperative turn can be implemented in a practical

system, incorporating heterogeneous communication

and cloud technologies.

CAM

ITS Applica�ons

DENM SPATEM MAPEM CPM MCM MRM

...

ITS Facili�es

Transport & Network

Access Technologies

Security

Management

Figure 3: ITS communication stack.

3 COMMUNICATIONS

Information exchange among vehicles but also among

vehicles and the infrastructure is subject to standard-

isation activities at several international committees,

e.g., ETSI, IEEE or SAE. A common view on com-

munications in ITS is given by the principle stack de-

sign, illustrated in Figure 3. In this paper, the focus

w.r.t. communications is on ITS facilities messages

as well as on access technologies. The messages uti-

lized in this paper are based on ETSI ITS-G5, see,

e.g., (ETSI EN 302 637-2 V1.3.2 (2014-11), 2014).

Even though ITS facilities have been primarily

designed assuming IEEE 802.11p as access technol-

ogy, the protocol layer is reused for C-V2X and is

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure

also discussed for cellular-based data exchange, e.g.,

at 5GAA (5GAA, 2018). Note that for transport

and network layer we assume Basic Transport Proto-

col (BTP) (ETSI EN 302 636-5-1 V2.1.1 (2017-08),

2017) plus geo-networking (ETSI EN 302 636-4-1

V1.3.2 (2017-08), 2017) for D2D, and TCP/IP with

geo-based addressing for cellular communications.

3.1 ITS Facilities Messages

Basic messages of ETSI ITS facilities have been used

for enabling day 1 and day 1.5 use cases (C-ITS Plat-

form, 2016). Such messages are, e.g., the Coopera-

tive Awareness Message (CAM), Decentralized En-

vironmental Notiﬁcation Message (DENM), Signal,

Phase and Timing Extended Message (SPATEM) and

the Map Extended Message (MAPEM). On top of the

basic set, we integrate advanced messages, currently

under investigation and subject to an ongoing stan-

dardization process in ETSI ITS. The Collective Per-

ception Message (CPM) enables to transmit dynamic

object information gathered from sensors located in

the vehicle or at the infrastructure side.

For realizing cooperative manoeuvres, however, a

more dedicated information exchange needs to be es-

tablished. For this reason, MCM and MRM have been

designed and integrated into the system. Both for-

mats are used for realising the cooperative turn. Even

though the details of the message format are beyond

the scope of this paper, the basic idea and message

ﬂow is explained in the following.

The NACV sends out an MCM with its short-term

route information (based on the navigation system)

and the intention to turn left (based on the turn-left

signal). Note, that the route information is optional.

The ACV recognizes the intention of the NACV by

receiving a MCM. Moreover, it receives a CPM from

the infrastructure, informing about the overall traf-

ﬁc situation. This might include non-connected road

users, detected by road-side sensors. The blue vehicle

realises the overall gain of cooperation and decides

to let the NACV pass. In order to inform the NACV

about this decision, the ACV sends an MCM includ-

ing two main information. First, the ACV’s ego in-

tention of decelerating a certain amount (for letting

the NACV pass) and secondly a request to the NACV

to pass the intersection in a certain time.

In addition to that, the infrastructure can support

both vehicles. As a basic service, the infrastructure

is sending out SPATEM and MAPEM in order to let

both vehicles perform GLOSA. On top of that, the

MRM is utilized to support both, the ACV and the

NACV. The ACV can receive the recommendation to

initiate a cooperative turn, while the NACV can re-

ceive a recommendation to cooperate with ACV and

pass the intersection as requested. The concept of

MCM and MRM presented in this paper includes the

possibility to communicate a cause of an intention, re-

quest or recommendation. One of the various causes

can be a reference on another intention, request, or

recommendation. Based on this concept, unambigu-

ous coordination is possible.

3.2 Access Technologies

Access technologies for communication in ITS is a

well-studied ﬁeld for several years. However, the

right choice of technology is still subject of current

discussions.

3.2.1 Direct Communication

The development of a direct Vehicle-to-Vehicle

(V2V) communication technology has been moti-

vated by the independence of the availability of a

managed infrastructure, like the cellular system. On

that basis, the direct communication system IEEE

802.11p has been standardized, which supports higher

vehicle speeds, works without any initialization pro-

cedures and is based on broadcasting information to-

wards road users in the surrounding. While the IEEE

802.11p is available for several years, an alternative

standard for V2X communication has been developed

and integrated into the 3GPP standard. It allows ex-

changing information directly among road users, sim-

ilar to IEEE 802.11p, but based on the cellular frame

structure. Hence, it is also referred to as C-V2X. The

two direct communication systems are in a competing

situation, while it is not clear at the moment which

technology is going to be used in which region, or if

a coexistence of both technologies is realistic.

In the presented system architecture both direct

access technologies are integrated, i.e., ITS messages

can be transmitted via 802.11p, C-V2X, or both. Note

that it is technically not possible to receive a message

via C-V2X, which has been send via 802.11p and vice

versa. However, if differently equipped vehicles are in

the surrounding, ITS-messages need to be transmitted

via cellular in parallel. For such situations, the in-

frastructure supports to achieve that vehicles with dif-

ferent direct communication technologies recognize

each other.

3.2.2 Cellular Communication

Even though direct communication clearly has its ad-

vantages, e.g., in an efﬁcient spectrum usage and

lower latencies, the penetration of vehicles equipped

VEHITS 2019 - 5th International Conference on Vehicle Technology and Intelligent Transport Systems

with this technology in real trafﬁc tends to zero. Al-

though several car manufacturers announced an inte-

gration of 802.11p or C-V2X in series-production ve-

hicles starting in 2019, the penetration rate will stay

low for several years. However, the number of cars,

equipped with cellular is markedly higher. Even with-

out cellular integrated in a vehicle itself, an upgrade

(e.g., cellular based HMI) is less costly compared to

today’s available direct-2-device units.

The presented architecture allows interaction

among vehicles and trafﬁc infrastructure independent

of the used communication technology. Messages can

either been forwarded via geo-based addressing (Ge-

oMessaging) or infrastructure services can be utilized

via the central cloud.

4 INFRASTRUCTURE

Beside the communication among vehicles itself, a

key aspect are the ITS services provided by the in-

frastructure. In the presented system, we extend basic

infrastructure-services (e.g., via SPATEM) by collec-

tive perception service via CPM as well as recommen-

dations via MRM in order to support cooperative ma-

noeuvres and foresighted driving. Due to the hetero-

geneous communication technologies also a heteroge-

neous cloud infrastructure is established for providing

services for both, vehicles equipped with direct com-

munication and those equipped with cellular. While

direct communication based services can be provided

by the RSU cloud, cellular users primarily refer to the

central cloud. Note that RSU cloud usage is also pos-

sible for cellular users via geo-messaging. For the fol-

lowing discussions cellular means Long Term Evolu-

tion (LTE).

4.1 RSU Cloud

The system concept of the RSU cloud is modular and

hybrid. It consists of various communication inter-

faces (like 802.11p and LTE), the ITS facilities and

the central element the hybrid communication unit,

which separates the ITS facilities from the communi-

cation interfaces and the software stack of the RSU

cloud. The hybrid communication control handles

the distribution and reception of the messages. So it

is possible to send one message parallel over more

than one communication interface. On the other hand

all the received messages will be forwarded to the

facilities-layer, no matter from which interface they

were received. With this concept it is possible to

reach more road users over various communication

Hybrid Communica�on Control

C-V2X Landline802.11p

Cellular

RSU Cloud

ITS Facili�es

ITS Cloud

Applica�on

ITS Cloud

Applica�on

Dynamic Object Map / Database

Central Cloud Traﬃc Light

...

Figure 4: System concept of RSU cloud.

technologies, or achieve a safer transmission by us-

ing redundant paths.

The current system concept of the RSU cloud con-

sists of various communication interfaces to enable

different applications. The LTE interface realizes the

connection to the backbone. Furthermore, this inter-

face is used to distribute messages to all vehicles in re-

gion via GeoMessaging. The two interfaces 802.11p

and C-V2X are used to directly communicate with the

road user.

All the ITS applications run in Docker-Containers

(Rad et al., 2017) so that they are separated from each

other. This strengthens the safety and security, facil-

itates the roll out of the software components, and

makes them independent from the hardware. This

concept enables different partners to run their own

applications on the RSU cloud without causing inter-

ference to other applications (see (Salahuddin et al.,

2014) for an analysis from the resource management

point of view). Each ITS application could subscribe

for messages and information from the ITS-Facility-

Layer and from the Dynamic Object Map (DOM)

to realise their services. The RSU cloud, namely

a NVIDIA

 Jetson

TX2, is a computation unit

which contains a GPU to support parallel computa-

tion and AI algorithms.

Figure 4 shows the system concept of the RSU

cloud. Components that are also used in the cen-

tral cloud are marked grey. The components that are

unique to the RSU cloud are marked blue. Due to

the modular structure the concept is future-proof. Not

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure

further supported interfaces can be easily replaced by

new state of the art interfaces or additional interfaces

can be added. It enables the simulcast operation for

backward compatibility. The software stack in the

RSU cloud shares the concept of modularity already

found in the hardware layout. It consists of a number

of micro services, which communicate using gRPC

(Google, 2018).

This approach offers ﬂexibility for future exten-

sions and allows to quickly exchange single compo-

nents, e.g., for bug ﬁxing or version updates. The core

system is the DOM, which stores static (e.g. maps)

and dynamic (e.g. vehicle positions, trafﬁc light state)

information. Data ingress happens through ITS mes-

sages (especially CAM, CPM) as well as backend

systems (e.g., prognoses for trafﬁc lights) and the

TLS (current trafﬁc light state). Before information

is passed into the DOM, there is an additional step

of data fusion and validation. This step ensures that

only valid entries are inserted and objects, which were

detected by more than one method (e.g. via its own

CAM and the CPM of another vehicle), are inserted

only once. Data egress mainly concerns the genera-

tion of MAPEM and SPATEM and the communica-

tion with backend systems as described above. Ad-

ditionally, the information stored in the DOM can be

used to generate manoeuvre recommendations (e.g.,

lane change), which are broadcast using the MRM.

4.2 Central Cloud

In addition to the decentralized cloud environments

provided by the individual RSUs, we also consider the

usage of a centralized cloud-based solution, termed

central cloud in the scope of this project. A high-level

view of the architecture is provided in Figure 5, where

the components speciﬁc to the central cloud are high-

lighted in blue.

While the services provided via the central cloud

address the same ITS applications as the RSU, there

are some key differences. The only communication

channel between the connected vehicles and the cloud

services is provided by a cellular data connection. In

order to evaluate different communication schemes,

two distinct means of transporting ITS messages via

the cellular connection are supported. For the ﬁrst

scheme, a TCP/IP connection providing the trans-

port layer for the standardized communication pro-

tocol MQTT (ISO/IEC 20922:2016, 2016) is estab-

lished to a central message broker deployed as part of

the central cloud in order to transport the ITS mes-

sages between the communicating parties. The mes-

sages are routed by the message broker according to a

topic-based publish-subscribe pattern. Alternatively,

ITS Facili�es

Traﬃc

Management

System

Central Cloud

Smart RSU/ RSU

Cloud

Smart RSU/ RSU

Cloud

RSU Cloud

Hybrid Communica�on Interface

ITS Cloud

Applica�on

ITS Cloud

Applica�on

ITS Cloud

Applica�on

ITS Cloud

Applica�on

Dynamic Object Map / Database

MQTT GeoMessaging

Figure 5: Architecture of the central cloud.

in order to allow for an efﬁcient and scalable com-

munication without a central message broker, a Ge-

oMessaging solution, implemented by means of IPv6

multicast, which is deployed in the core of the cellular

network, is used. The interface between the commu-

nication channels and the applications is provided by

the ITS facilities layer, which allows for a complete

decoupling of the mode of communication from the

actual ITS applications.

The individual services deployed on the central

cloud platform are implemented as micro-services

and are coupled via a high-performance messaging

bus and gRPC APIs (Google, 2018). Due to the more

centralized nature of the central cloud, the ITS ap-

plications deployed have a larger pool of information

available, as information is ingested from a wider ge-

ographical region. Speciﬁcally, the central cloud ser-

vices are connected to all equipped vehicles and RSUs

in the target area. This allows the ingestion of real-

time data provided by the RSUs, including the status

of the trafﬁc lights and sensor data. Additional in-

formation is made available via the Trafﬁc Manage-

ment System (TMS) of the city of Dresden, VAMOS

(Krimmling, 2014). The TMS provides predictions

for both the signal state and the delay for each sig-

nal at the relevant intersections. This information is

pushed from the TMS to the respective service in the

central cloud using the well-established DATEX II

(CEN/TC 278, 2018) interface. The information pro-

vided by the various sources is combined into a coher-

VEHITS 2019 - 5th International Conference on Vehicle Technology and Intelligent Transport Systems

100

ACV / NACVCentral/RSU Cloud

Tac�cal Planning

Sensors

Radar

Camera

Lidar

Environmental

Model

Opera�onal

Planning& Control

Hybrid Communica�on Interface

Environmental

Data

V2X Messages

Driving Maneuver

Recommenda�ons

and Inten�ons

V2XData

Driving Maneuver

Sensor Data,

Objects, Lanes

Situa�on

Interpreta�on

Environmental Data

Situa�on

V2X Messages

Human Machine Interface

Vehicle Interface

Situa�on

Human

Vehicle

Figure 6: Automated Driving System (ADS) and its inte-

gration into the overall architecture.

ent dynamic object map and, after fusion with static

information such as HD maps, provides the basis for

the ITS applications. The messages generated by the

cloud applications are processed by the ITS facilities

and, either via cloud-based MQTT or GeoMessaging,

transmitted to the connected vehicles. The messages

generated by the vehicles take the reverse path and are

forwarded to the appropriate cloud application, based

on the type of the message and other factors such as

the location of the originating vehicle.

5 VEHICLES

Cooperative driving in real trafﬁc cannot be accom-

plished by focusing on automated vehicles alone.

In our work, we consider both automated and non-

automated vehicles and assume that all entities are

connected and share information.

5.1 Automated Connected

Vehicle (ACV)

Each ACV implements an ADS that enables the vehi-

cle to operate without intervention of a human driver

in a deﬁned Operational Design Domain (ODD).

Brieﬂy speaking, an ODD deﬁnes environmental and

time-of-day conditions and restrictions, respectively,

the presence or absence of certain trafﬁc, and roadway

characteristics. Furthermore, in order to facilitate co-

operation during dynamic driving tasks, each ADS is

embedded into the overall architecture, as presented

in Section 2.1. That is, each ADS can rely on infor-

mation from other ACVs as well as NACVs while

simultaneously providing information such as driv-

ing manoeuvre intentions or sensor objects to both

other trafﬁc participants and infrastructure services.

Figure 6 gives a broad overview of the implemented

ADS and its integration into the overall architecture.

The dashed line indicates the boundary of the ADS.

Three components serve as main input for the system:

sensors, the human machine interface (cf. Section

5.2) and the hybrid communication interface. Sensor

data, such as camera images, radar objects, lidar point

clouds, or even positioning data is essential to create a

local view of the surrounding environment. The ego-

centric environmental model includes host data from

the vehicle interface as well as relative sensor data

(e.g., dynamic objects or lanes). Furthermore, it in-

corporates world data such as static map data and dy-

namic environment data (e.g., accidents or trafﬁc light

status) from the hybrid communication interface. As

discussed in Section 3 and 4, the hybrid communi-

cation interface allows for vehicle to vehicle, vehi-

cle to infrastructure, as well as vehicle to backend

communication. Finally, as different sources possi-

bly provide information about the same objects, ob-

ject data is fused on a ﬁne-grained level. The environ-

ment model’s data is used to interpret situations and to

select and plan abstract manoeuvers. The situation in-

terpretation is necessary to detect possibly hazardous

situations, to obey trafﬁc regulations, or to optimize

other metrics such as long-term fuel consumption.

Depending on the current situation, a tactical plan-

ner is subsequently selecting and planning abstract

driving manoeuvers such as lane changes, speed ad-

justments, or even parking manoeuvers. For coopera-

tion, the tactical planner simultaneously takes MRMs

from the infrastructure as well as MCMs from other

trafﬁc participants into account. Due to their ab-

stract nature, manoeuvers are not directly realizable

by car actuators. For that reason, an operational plan-

ner translates the current driving manoeuvere into

time-dependent trajectories. A control component ﬁ-

nally subdivides the trajectory into multiple control

sequences for the vehicle interface. More concretely,

it computes throttle and brake commands as well as

the steering angle for the car actuators. The ADS

provides two levels of output: local and environmen-

tal output. Local output refers to the interaction with

the driver of the vehicle via HMI (e.g., by visualizing

the next planned manoeuvre). Furthermore, it refers

to the control of the vehicle via the previously intro-

duced vehicle interface. Environmental output refers

to the provision of data via the hybrid communication

interface to the environment. That is, parts of the lo-

cal view of the host are transmitted in terms of the

following ITS messages:

• CAMs for host data (position, acceleration, etc.),

• CPMs for detected dynamic objects, and

• MCMs for coordinating manoeuvers with other

trafﬁc participants.

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure

101

In order to implement the cooperative turn discussed

earlier, the NACV and ACV exchange MCM mes-

sages and rely on CAM information. For NACV there

is no vehicle controlling component. However, the

communication and HMI parts (the upper part of Fig-

ure 6) are equivalent to the ACV architecture. More

insights on HMI design for both, ACV and NACV are

given in the following section.

5.2 Human Factors Regarding

Connected Vehicles and HMI

Development

Introducing connected vehicles to the trafﬁc changes

the road-vehicle-user-system as new opportunities of

interaction and exchange of information arise (Kul-

mala and R

a, 2013). Potential beneﬁts of con-

nected vehicles such as reduced pollution, increased

safety, and trafﬁc ﬂow can only be achieved if the

technology is accepted by the users. ACV users need

to feel comfortable throughout each drive and trust the

system when driving manoeuvres are adapted to in-

coming ITS messages by the system (Elbanhawi et al.,

2015). Assuming the cooperative turn with an NACV

as left-turning vehicle, the ACV driver might get con-

fused or even take over control, because the own car

reduces its speed without any obvious reason. There-

fore, it is important to understand whether the ACV

user needs information and if so, which information

these are in order to appreciate the system.

Contrary to ACV users, NACV users are still re-

sponsible to fulﬁl the main driving task. In the sce-

nario of connected vehicles, drivers should react to

incoming information and adapt their behaviours. In

case of the cooperative turn (see Figure 2), the driver

may get the information that he/she can turn ﬁrst be-

fore the oncoming ACV takes its right of way. The

driver, ﬁrst, needs to receive and understand this mes-

sage, and second, is expected to agree or just react ac-

cording to the message. Otherwise, cooperation fails

and expected beneﬁts will not be achieved. One chal-

lenge for such cooperation is that implicit commu-

nication such as eye contact between drivers is not

possible if one party drives automatically; alterna-

tive communication channels are needed. Moreover,

NACVs have an additional need for an input channel

that enables its users to tailor cooperative manoeuvres

with other connected vehicles. If we modify the coop-

erative turn use case a bit, so that the oncoming vehi-

cle would be a NACV and is asked to agree to the co-

operation and reduce speed, the left-turning car might

need an agreement to this manoeuvre in order to en-

sure safe driving and execute the cooperative turn.

When designing technology that enables con-

nected, cooperative driving, we should take into ac-

count that driver’s behaviour is based on mental mod-

els that represent knowledge and learning experi-

ence with the system (Wilson and Rutherford, 1989).

Driver behavioural adaption will only take place if the

driver trusts the system (Lee and See, 2004). Trust

in the system is determined in turn by its reliabil-

ity and the users’ competence of the system. These

factors can only be established if users are given ap-

propriate feedback and system transparency, for in-

stance, on system performances, processes and objec-

tives (Rudin-Brown and Ian Noy, 2002; Lee and See,

2004; DIN EN ISO 9241-210, 2011).

Visual human-machine-interfaces (HMI) that are

developed in a user-centred manner have the potential

to support behavioural adaption by providing users

with individually relevant information on the current

trafﬁc situation. Research focused on highway situa-

tions showed that inexperienced users of highly auto-

mated vehicles do not need much information in the

longer term, but certain information should always

be displayed. This includes the status of the system

(autopilot vs. manual), planned driving manoeuvres

and the current speed (Beggiato et al., 2015). In ad-

dition, emerging special situations, such as conges-

tion or accidents should be displayed. Mixed, urban,

connected trafﬁc is much more complex than high-

way trafﬁc. Research regarding speciﬁc information

needs for mixed, urban, connected trafﬁc is limited.

Identifying such needs was part of the project and one

ﬁrst important step in the development process of the

HMIs.

5.2.1 Identiﬁcation of Information Needs

For the purpose of capturing ACV users’ and NACV

users’ potential informational needs as a ﬁrst step,

three focus group discussions were conducted (N

total

= 16); for details see (Springer et al., 2018). The focus

groups consisted of experienced (N

= 6) vs. novice

= 10) participants concerning vehicle automation,

which empathised with the ACV users’ (N

ACV

= 11)

vs. the NACV users’ (N

NACV

= 5) perspective. On the

basis of different use cases (e.g., see Section 2.2 and

Figure 2) the informational needs for each group were

discussed. Afterwards the relevance of each collected

piece of information was rated using a point system.

We developed a categorical system that distinguishes

between informational needs of the different vehicle

type users (NACV vs. ACV) as well as between the

users’ degree of experience in vehicle automation (ex-

perienced vs. non-experienced). Summing up the

ﬁndings, NACV users want the HMI to support them

in situation recognition as well as by giving action

recommendations. In detail, information about the

VEHITS 2019 - 5th International Conference on Vehicle Technology and Intelligent Transport Systems

102

Figure 7: Schematic setup for an exemplary driving test

of connected and automated driving functions on a test

corridor in the Digital Testbed Dresden (source: Open-

StreetMap).

duration of the green and red phase, recognition of

other road users and their movement direction as well

as the status of cooperation were discussed as impor-

tant aspects. In the cooperative turn use case feedback

from the oncoming trafﬁc relating to the cooperation

were of highest value. Some information such as the

duration of the green and red phase have been imple-

mented in existing HMIs (see Figure 8), but many de-

sired aspects have not been displayed yet.

According to the focus group results, an HMI

for ACV users is supposed to increase system trans-

parency by informing about driving manoeuvres,

recognised elements and by explaining “unusual” sys-

tem behaviour. For the use case cooperative turn, for

example, a risk assessment of the vehicle regarding

safe manoeuvring on basis of the vehicle’s capabili-

ties and the context of the situation was rated as most

important. Just as important as the risk assessment

was the situation detection; information regarding the

recognition of other vehicles, followed by the infor-

mation of what the intention of the own vehicle is,

was desired by the participants.

As an overall result, it was found that non-

experienced participants need a substantially higher

amount of information with a higher level of detail

compared to the experienced ones. Therefore, we rec-

ommend the development of adaptive and personalis-

able HMIs.

5.2.2 Mock-up Evaluation

Findings of the focus groups were used for develop-

ing ﬁrst new HMI mock-ups. For ACV users, the

idea is to use a portable Head-Up Display (pHUD)

to have a ﬂexible tool that can be used to integrate

connected driving in a conventional car. As a sec-

ond step in the HMI development process, the pHUD

mock-ups were discussed and evaluated within both

an HMI-Workshop (N

HMI−W S

= 4) with ACV experi-

Figure 8: HMI for connected test vehicles visualising re-

ceived trafﬁc light information and speed recommendations

from RSU (source: Fraunhofer IVI).

enced participants and within a usability expert eval-

uation (N

expert

= 4) in order to identify improvement

potential before realizing the HMI.

Both studies showed that the development is on a

good path. However, chosen symbols for automated

vehicles were not intuitive and the usage of trafﬁc

signs such as the right of way sign to describe ma-

noeuvre recommendations was judged as confusing.

For the cooperative turn, arrows showing movement

intentions of the cooperating vehicles were color-

coded with red, yellow and green to show the status

of cooperation and who has the right of way. Partici-

pants stated that yellow-coding was seen as negligible

and text would help to understand the manoeuvre rec-

ommendations. Identiﬁed potential for improvement

was presented to developing partners and will be in-

cluded in the further work.

6 LIVE DEMONSTRATION

The outlined architecture and the interaction of its

systems and components were initially demonstrated

as part of a ﬁrst test event in November 2018 on the

Digital Testbed Dresden. One ACV and three NACVs

took part in multiple driving scenarios in public traf-

ﬁc on a speciﬁc test corridor. The test corridor is

located in the north of the city of Dresden near the

Dresden International Airport and is equipped with

RSUs at four trafﬁc light coordinated intersections

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure

103

(Figure 7). The road infrastructure itself is well de-

veloped, with two lanes per direction allowing coop-

erative driving manoeuvres and minimizing possible

interference with public road trafﬁc. The equipped

RSUs are connected to the respective trafﬁc light con-

trol unit and to the central cloud. At the time of

the driving demonstration, the RSUs supported V2X

communication via 802.11p. A central element of the

driving demonstration was the connected mixed traf-

ﬁc scenario. While driving along the test corridor, the

NACVs and the ACV communicated with the RSU

cloud, the central cloud as well as with each other.

The test vehicles approached the equipped intersec-

tions and received the current trafﬁc light state, the

predicted remaining time as well as a speed recom-

mendation from the connected infrastructure. In the

connected vehicles, this information was forwarded

to the driver via a HMI shown in Figure 8. On the left

side of the HMI, the trafﬁc light state and the remain-

ing time was visualised for each direction whereas

the speed recommendation was displayed speciﬁcally

for the test vehicle’s path. In addition, the test ve-

hicles sent CAMs to the central cloud. On the return

path several cooperative manoeuvres were performed,

demonstrating basic functionalities for cooperation in

mixed trafﬁc scenarios (e.g. cooperative awareness)

with regard to the initially described use case cooper-

ative turn.

The driving demonstration showed that the de-

scribed architectures and systems can be operated un-

der real conditions. The event served as a starting

point for an intense evaluation phase equally consist-

ing of simulations and driving tests in public trafﬁc.

7 CONCLUSIONS AND

OUTLOOK

In this work we presented an ITS system concept

for supporting cooperative driving in mixed trafﬁc

scenarios. We especially emphasised the ability of

the system to incorporate vehicles equipped with het-

erogeneous communication technologies by introduc-

ing a heterogeneous cloud architecture that makes it

possible to support connected vehicles with ITS ser-

vices, e.g., recommendations regarding cooperative

manoeuvres or foresight driving. We gave insights

into the design and the interaction of the heteroge-

neous components, the automated vehicle and HMI

concepts and ﬁndings for both, the ACV and NACV.

We introduced a ﬁrst live demonstration, which

showed that the system is usable in real mixed traf-

ﬁc scenarios. After the successful demonstration of

the ﬁrst system prototype, results of upcoming user

studies focusing on the HMI as well as results of real-

life tests on the test ﬁeld will be integrated in the

next development steps. Our goal is to end up with a

user-friendly, reliable system that can cover the iden-

tiﬁed use cases and help to reach the long-term goals

such as reduced trafﬁc jams, reduced pollution, and

increased trafﬁc safety.

ACKNOWLEDGEMENTS

This work has been supported by the project Har-

monizeDD funded by the Federal Ministry of Trans-

port and Digital Infrastructure under the grant

16AVF1024.

REFERENCES

5GAA (2018). 5G Automotive Association project page.

https:/5gaa.org. Accessed: 2019-02-20.

Beggiato, M., Hartwich, F., Schleinitz, K., Krems, J., Oth-

ersen, I., and Petermann-Stock, I. (2015). What would

drivers like to know during automated driving? infor-

mation needs at different levels of automation.

C-ITS Platform (2016). Final report. Technical report, C-

ITS Platform. Accessed: 2019-02-12.

Cecchini, G., Bazzi, A., Masini, B. M., and Zanella,

A. (2017). Performance comparison between ieee

802.11p and lte-v2v in-coverage and out-of-coverage

for cooperative awareness. In 2017 IEEE Vehicular

Networking Conference (VNC), pages 109–114.

CEN/TC 278 (2018). Intelligent transport systems - DA-

TEX II data exchange speciﬁcations for trafﬁc man-

agement and information - Part 1: Context and frame-

work. Standard.

DIN EN ISO 9241-210 (2011). Prozess zur Gestaltung

gebrauchstauglicher interaktiver Systeme. Standard,

ISO.

Elbanhawi, M., Simic, M., and Jazar, R. (2015). In the

passenger seat: Investigating ride comfort measures

in autonomous cars. IEEE Intelligent Transportation

Systems Magazine, 7(3):4–17.

ETSI EN 302 636-4-1 V1.3.2 (2017-08) (2017). ETSI EN

302 636-4-1 V1.3.2 (2017-08) Intelligent Transport

Systems (ITS); Vehicular Communications; GeoNet-

working; Part 4: Geographical addressing and for-

warding for point-to-point and point-to-multipoint

communications; Sub-part 1: Media-Independent

Functionality . Standard, ETSI.

ETSI EN 302 636-5-1 V2.1.1 (2017-08) (2017). ETSI EN

302 636-5-1 V2.1.1 (2017-08) Intelligent Transport

Systems (ITS); Vehicular Communications; GeoNet-

working; Part 5: Transport Protocols; Sub-part 1: Ba-

sic Transport Protocol . Standard, ETSI.

ETSI EN 302 637-2 V1.3.2 (2014-11) (2014). ETSI EN

302 637-2 V1.3.2 (2014-11) Intelligent Transport Sys-

tems (ITS); Vehicular Communications; Basic Set of

VEHITS 2019 - 5th International Conference on Vehicle Technology and Intelligent Transport Systems

104

Applications; Part 2: Speciﬁcation of Cooperative

Awareness Basic Service. Standard, ETSI.

Festag, A. (2014). Cooperative intelligent transport systems

standards in europe. IEEE Communications Maga-

zine, 52(12):166–172.

Google (2018). gRPC project page. https://grpc.io. Ac-

cessed: 2018-01-23.

Hameed Mir, Z. and Filali, F. (2014). Lte and ieee 802.11p

for vehicular networking: a performance evaluation.

EURASIP Journal on Wireless Communications and

Networking, 2014(1):89.

Hobert, L., Festag, A., Llatser, I., Altomare, L., Visin-

tainer, F., and Kovacs, A. (2015). Enhancements

of v2x communication in support of cooperative au-

tonomous driving. IEEE Communications Magazine,

53(12):64–70.

ISO/IEC 20922:2016 (2016). ISO/IEC 20922:2016 In-

formation technology – Message Queuing Telemetry

Transport (MQTT) v3.1.1. Standard, ISO.

Kloeppel, M., Grimm, J., Strobl, S., and Auerswald,

R. (2019). Performance evaluation of GLOSA-

algorithms under realistic trafﬁc conditions using C2I-

communication. In Nathanail, E. G. and Karakikes,

I. D., editors, Data Analytics: Paving the Way to Sus-

tainable Urban Mobility. CSUM 2018, volume 879

of Advances in Intelligent Systems and Computing,

pages 44–52, Cham. Springer International Publish-

ing.

Krimmling, J. (2014). Das Dresdner Verkehrsmanage-

mentsystem VAMOS. In Sandrock, M. and Riegel-

huth, G., editors, Verkehrsmanagementzentralen in

Kommunen: Eine vergleichende Darstellung, pages

157–197. Springer Fachmedien Wiesbaden, Wies-

baden.

Kulmala, R. and R

a, P. (2013). Deﬁnition of behavioural

adaptation. In Rudin-Brown, C. and Jamson, S., ed-

itors, Behavioural adaptation and road safety : the-

ory, evidence, and action, pages 11–22. Boca Raton,

Florida CRC Press. Formerly CIP.

Lee, J. D. and See, K. A. (2004). Trust in automation:

Designing for appropriate reliance. Human Factors,

46(1):50–80. PMID: 15151155.

Rad, B. B., Bhatti, H. J., and Ahmadi, M. (2017). An in-

troduction to Docker and analysis of its performance.

International Journal of Computer Science and Net-

work Security (IJCSNS), 17(3):228.

Rudin-Brown, C. and Ian Noy, Y. (2002). Investiga-

tion of behavioral adaptation to lane departure warn-

ings. Transportation Research Record: Journal of the

Transportation Research Board, (1803):30–37.

Salahuddin, M., Al-Fuqaha, A., Guizani, M., and

Cherkaoui, S. (2014). Rsu cloud and its resource

management in support of enhanced vehicular appli-

cations.

Springer, S., Schmidt, C., and Schmalfuß, F. (2018). In-

formationsbedarf von Nutzern konventioneller, ver-

netzter und automatisierter, vernetzter Fahrzeuge im

urbanen Mischverkehr. In VDI, editor, Fahrerassis-

tenzsysteme und automatisiertes Fahren 2018, VDI-

Berichte 2335, pages 391–406. VDI-Verlag GmbH,

usseldorf.

Statista (2018). Connected car report 2018. https://

www.statista.com/outlook/320/109/connected-car/

united-states. Accessed: 2019-02-20.

Wilson, J. R. and Rutherford, A. (1989). Mental models:

Theory and application in human factors. Human Fac-

tors, 31(6):617–634.

Zhang, L. (2018). Cooperative adaptive cruise control in

mixed trafﬁc with selective use of vehicle-to-vehicle

communication. IET Intelligent Transport Systems,

pages 1243 – 1254.

Cooperative Driving in Mixed Trafﬁc with Heterogeneous Communications and Cloud Infrastructure

105