Integration of Private and Carsharing Vehicles

into Intermodal Travel Information Systems

Christian Samsel

1,3

, Markus Christian Beutel

1,3

David Thulke

, Detlef Kuck

and Karl-Heinz Krempels

1,3

Information Systems, RWTH Aachen University, Aachen, Germany

Ford Research and Innovation Center, Aachen, Germany

Fraunhofer FIT, St. Augustin, Germany

Keywords:

Carsharing, Intelligent Transportation Systems, Intermodal Travel Information, Web Information Systems.

Abstract:

In the last years, intermodal mobility platforms offering combinations of various modal types, like trains,

buses, carsharing and ride sharing, have emerged. These platforms often also offer a smartphone-based door-

to-door navigation and a sophisticated travel assistance. Unfortunately, these smartphone-based services can-

not be used by the travelers as soon as they are driving a car themselves, e.g., a carsharing vehicle or their

private car, due to road safety regulations. The driver is essentially disconnected from the service. In addition,

modern cars have a lot of conﬁguration options a driver might want to set up. This discourages using shared

vehicles in an intermodal itinerary. In this work we identify use cases of how an integration of carsharing vehi-

cles into intermodal travel information systems can enhance travel experience, introduce a system architecture

to allow the necessary information exchange and present a preliminary prototype to demonstrate its technical

feasibility.

1 INTRODUCTION

In the last years, the demand for intermodal mobility

has been increasing and especially in younger genera-

tions, car ownership becomes less popular (Klein and

Smart, 2017). Reasons for this include high main-

tenance cost, the declining value of cars as a status

symbol and environmental concerns (Kalmbach et al.,

2011). In urban areas, other modes of transporta-

tion offer higher availability and ﬂexibility by avoid-

ing parking problems and congestions. In many sit-

uations, traditional public transport provides an ade-

quate replacement. But areas with insufﬁcient cov-

erage of traditional public transport services or spe-

cial demands (e.g., high reliability) are requiring addi-

tional mobility services. One service to complement

traditional public transport is carsharing. Carsharing

became more and more popular in recent years (Sha-

heen and Cohen, 2007).

To make these complementary services appealing,

a seamless integration of various transportation sys-

tems is needed. One approach for such an integration

are advanced Travel Information Systems (TIS) offer-

ing intermodal itineraries (Beutel et al., 2016a). Inter-

modal itineraries consist of a mix of different modes

of transportation, e.g., using both trains and a carshar-

ing vehicle in the same journey. This requires com-

plex planning, which is enabled by integrating hetero-

geneous information from multiple mobility service

providers. This information can include for example

timetable information, vehicle availability or delays.

Besides traditional public transport providers like bus

or railway companies, integrated mobility services

can include, among others, car, bike and ridesharing

providers, parking services, taxi services or innova-

tive services like Uber

. In addition to the offering

of an intermodal itinerary, some of these systems also

provide integrated booking and billing services for all

legs of the itinerary. In this way, the user does not

have to book them individually. Examples for these

systems are Qixxit

by Deutsche Bahn (German rail-

ways), Moovel

by Daimler AG or “Mobility Broker”

as suggested in (Beutel et al., 2014).

The rising number of features in modern cars al-

lows an increasing amount of possibilities for cus-

tomization and personalization. Besides standard fea-

https://www.uber.com

https://www.qixxit.de/en

https://www.moovel.com/de/en

312

Samsel, C., Beutel, M., Thulke, D., Kuck, D. and Krempels, K-H.

Integration of Private and Carsharing Vehicles into Intermodal Travel Information Systems.

DOI: 10.5220/0006347803120319

In Proceedings of the 3rd International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2017), pages 312-319

ISBN: 978-989-758-242-4

tures like seat and mirror positions, air conditioning

and radio, cars can integrate the drivers’ smartphones,

offer connected infotainment systems or even driving

assistants. Furthermore, many parts of current vehi-

cles become electronically controllable and intercon-

nected. In this way, the infotainment system is en-

abled to control settings like the seat or mirror posi-

tion.

Motivation

Currently, TIS’s are not integrated into cars booked

via carsharing providers. When users arrive at their

booked carsharing vehicles, these vehicles do not

know anything about the users nor about their route.

Unlike in transport modalities like trains, it is difﬁcult

for users to interact with their smartphone or to use it

for navigation, as it is a security hazard and often for-

bidden by law. Necessary equipment like hands free

systems are often not available in carsharing vehicles.

Thus, the travel assistance provided by the TIS is dis-

rupted and the user has to manually enter the destina-

tion address into the car navigation systems, which is

a major inconvenience.

Furthermore, every time a traveler uses the ser-

vice, he or she has to manually customize most of the

car settings to his or her personal preferences. If a car

is unknown to them, they have the additional hassle of

ﬁnding out how to apply these settings to the car. Oth-

erwise they have no access to useful features. Accord-

ing to (Berylls Strategy Advisors, 2015), the second

most common reason (28%) for people not to use car-

sharing is that they do not want to drive an unfamiliar

vehicle. If carsharing vehicles could be already con-

ﬁgured for these users, this may mitigate the problem.

Additionally, misconﬁgured vehicles can become a

security risk. For example, it is crucial that the mir-

rors of the car are correctly adjusted, to remove blind

spots.

2 RELATED WORK

This section gives an overview over related work, in-

cluding actual systems and technologies which are

currently in use, as well as related academic research.

As mentioned in the introduction, Qixxit is an ex-

ample for a TIS by Deutsche Bahn. Beside train ser-

vices, it includes local public transport services, mul-

tiple carsharing providers, rental cars, ride sharing,

taxis, bike sharing and even airlines. Qixxit offers its

services via a webportal and a mobile application.

INRIX Intermodal Navigation

is a in-car ser-

http://inrix.com

vice to integrate local public transport connections

into journey planning. It is able to suggest users to

switch to alternative modes of transportation if these

are faster than the expected vehicle travel time. If

users choose to use a different mode of transporta-

tion, the vehicle navigates them for example to the

next train station. In contrast to the system proposed

in this work the system is bound to the navigation sys-

tem in the vehicle and is not accessible for example

via the user’s smartphone.

The problem of driver preferences in shared vehi-

cles already has been recognized by others. Among

other car manufactures, Ford has been approach-

ing the problem by offering the so called “MyKey”.

Drivers can store several settings of the car, like the

seat position, on their keys. If the car is opened us-

ing the key, the settings which are stored on it are

initiated. This solution works for a limited number

of drivers (e.g., for families) but requires that every

driver has a personal key and does not allow settings

to be shared between multiple cars.

In (Beutel et al., 2014), the authors introduce an

architecture for a TIS called Mobility Broker. It is

designed to allow heterogeneous mobility providers

to collaborate on a joint platform. Besides inter-

modal routing, it allows querying pricing information

and manages the booking and payment of intermodal

routes for users. Additionally, the advantages for par-

ticipating stakeholders are discussed. In (Beutel et al.,

2016a) the architecture is reﬁned by discussing the

information ﬂow between the TIS and the different

transportation providers in more detail.

A protocol used to communicate with sharing

providers, including car and bike sharing, is the Inter-

face for X-Sharing Information (IXSI) protocol, pro-

posed in (Kluth et al., 2015). It is designed to cre-

ate a uniﬁed interface between sharing providers and

TIS’s. It deﬁnes different services to enable function-

ality like availability queries, exchange of pricing in-

formation and booking of vehicles.

A solution more adequate to carsharing regarding

the problem of driver preferences in shared vehicles

is proposed in (K

ummerling et al., 2013). The idea

is to create a centralized platform where every driver

can store his or her own Mobility Proﬁle containing

his preferred vehicle settings. The user applies the

proﬁle to the car by connecting his or her phone over

a Near Field Communication (NFC) interface. The

authors applied the concept to a prototype of a car

(consisting of a middle console and an electrically ad-

justable seat) and developed a mobile app. An advan-

tage compared to other solutions is that the proﬁle can

be used for an arbitrary amount of vehicles. It addi-

tionally suggests four categories of data which may

Integration of Private and Carsharing Vehicles into Intermodal Travel Information Systems

313

be stored in such a Mobility Proﬁle. These consist of

information about the driver, car dependent (e.g., seat

position) and independent (e.g., radio station) settings

and logging data (e.g., consumed fuel or driven kilo-

meters). The disadvantage of their solution is that the

driver still has to manually apply the settings to the

car with his or her phone.

3 USE CASES

To guide the design, we start with possible use cases.

Each use case discusses a real world example com-

prising problems mentioned in Section 1. Moreover,

these are used to provide an evaluation for the imple-

mentation.

Scenario 1: Synchronized Preferences. Every fri-

day, Bob uses a carsharing vehicle to drive from

Aachen to D

usseldorf (and back). Previously, he ad-

justed the seat positions and searched for his favorite

radio station every time. It annoys him that he has to

adjust the vehicle every week. With the integration of

the carsharing vehicle and the TIS, the TIS can now

automatically apply the preferences to the vehicle be-

fore Bob arrives at the car. Thus, he can immediately

start driving without the need to apply any conﬁgura-

tions, giving a similiar experience as a private car.

As the preferences are transfered to the TIS, which

offers multiple carsharing services, his favorite radio

station is even preset when he uses a different model

and carsharing operator at the weekend.

Scenario 2: Preconﬁguring the Navigation System.

Alice plans a trip from her home in Cologne to a lake

in the Eifel. The TIS recommends her to take the train

to Aachen and to rent a carsharing vehicle to get to

the lake from there. Without an integration of the TIS

with the infotainment system of her carsharing vehi-

cle, she had to manually enter the address of the lake

into the navigation system of the vehicle. Because of

the unknown interface, this was time consuming and

frustrating for her. With the integration of the TIS and

carsharing system respectively vehicle, the TIS can

now preconﬁgure the navigation system of the vehi-

cle. At the time Alice arrives at the vehicle, the ad-

dress of the lake in the Eifel is set as destination and

she can start driving immediately.

Scenario 3: Changing the destination while driv-

ing (using car sharing). Bob has to travel from

Aachen to a meeting in Cologne. He booked a car

sharing vehicle using his preferred TIS. An unex-

pected road accident on the highway causes a delay of

over an hour. Due to this, he would be late to his meet-

ing. Fortunately, his TIS is now integrated with the

carsharing vehicle. Using the Infotainment System,

he is notiﬁed about the possibility to stop the car and

change to a train in D

uren. Bob can then accept this

itinerary change and thus still arrive at his meeting in

time. The train booking is done automatically and the

required ticket is transferred to his smartphone.

Current Coverage of Use Cases

The key-based preference systems are not applica-

ble to carsharing but only to situations where a small

number of persons share a vehicle. The concept of

Mobility Proﬁles in (K

ummerling et al., 2013) re-

quires the interaction of the user to manually apply

his preferences to the vehicle. As a result, the process

is not as seamless as described in Scenario 1.

The integration of intermodal travel information

of INRIX in vehicles enables the navigation system

to suggest the driver to change to other modes of

transportation. In Scenario 3, it could suggest Bob

to switch to a train. But there is no full integration of

a TIS, a booking of the service is not possible. The

component in the vehicle is not connected to other

mobility applications and thereby is not able to sup-

port any of the other use cases.

4 APPROACH

As concluded in the last section, none of the solutions

discussed so far supports all use cases presented and

integrate carsharing vehicles into TIS. The approach

presented in this section is similar to (K

ummerling

et al., 2013) but does not require the user to manually

apply his settings.

4.1 Architecture

For Scenario 1, the TIS has to be able to synchronize

the user’s preferences with the car. Before the start

of the booking, it has to send the vehicle all applica-

ble preferences of the user it knows. The carsharing

vehicle has to apply these preferences before the user

arrives at the car. During a trip it has to propagate all

changes in the preferences back to the TIS. The TIS

then stores these settings to reapply them at the next

booking. For Scenario 3, the TIS has to be able to

track the position of the carsharing vehicle. On a reg-

ular basis, it should check whether the user is still tak-

ing the optimal route with regard to the current trafﬁc

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

314

TIS VRS

Vehicle

Website

/ App

Driver

IXSI

New Protocol

Proprietary

Figure 1: Sketch of the proposed architecture. Arrows indi-

cate information ﬂow, dashed arrows indicate user interac-

tion.

and the current location of the vehicle. If the optimal

route changes it has to propagate this change back to

the carsharing vehicle which notiﬁes the user. Thus,

the part of the architecture deployed to a carsharing

vehicle has to be able to identify its location and to

expose it to the TIS. Additionally, it has to be possi-

ble to change the current destination of the navigation

system, preferably with the option to notify the user

about this change and to ask for approval.

The carsharing operator uses a Vehicle Rental

System (VRS), which is connected to the vehicles to

manage bookings and to track the state of the car (lo-

cation, mileage, etc.). This is done via an onboard

unit, which is installed in the car. One of these solu-

tion is “CloudBoxx”

by Invers GmbH. Among oth-

ers, it offers the management of vehicle access and

connectivity between the vehicles and the servers of

the carsharing provider. Given these capabilities, it is

possible to deploy an additional software to such an

onboard unit to manage vehicle preferences. Once

deployed in a vehicle, such a software component

is difﬁcult to access and thus should be designed to

require low maintenance. To minimize the possible

need for updates, it should contain a minimal amount

of logic. Our approach uses this existing carsharing

infrastructure and does not require additional hard- or

software. This also has some further advantages. In-

stead of giving one TIS full access to all carsharing

vehicles, the access rights can be managed by the car-

sharing provider. Also the scalability is better, as a

TIS does not have to communicate with potentially

thousands of vehicles, and the vehicles do not have to

communicate with multiple TIS’s.

By including the driver, the architecture depicted

in Figure 1 emerges. The driver communicates with

the TIS over the website of the TIS or its mobile ap-

plication. Additionally he or she indirectly communi-

cates with the module installed in his or her carsharing

vehicle by modifying preferences or by responding to

destination changes.

http://cloudboxx.invers.com/index.en.html

4.2 Data Models and Protocols

After introducing particular components of the archi-

tecture, the next step is to discuss data models and

protocols used by these components for communica-

tion. The communication between TIS and website /

mobile application is not covered here as it is usually

proprietary.

The update of the status of the current trip is mod-

eled by a TripProgress. A TripProgress consists of a

coordinate which represents the current location, the

progress on the route as percentage or the estimated

arrival time, depending on the preferences of the car-

sharing provider and the user. Futhermore, it contains

a timestamp to match it to a speciﬁc point in time.

The modeling of Preferences is not as straightfor-

ward. The value of a Preference can have an arbitrary

type. They can range from a simple decimal value to

conﬁgure the volume of the speakers to a set of angles

to conﬁgure the seat position. To keep the handling

of these various types of values simple, the idea is

to store them as one decimal or one string value. For

most preferences either one or both of these properties

are sufﬁcient (e.g., the volume or temperature). All

other settings can be encoded in these properties (the

set of angles for example could be encoded as a string

value). Different preferences are distinguished by

their type property. A value of a type is a ﬁxed string

identifying a preference across different vehicles, car-

sharing providers and TIS’s. In order for this to be

possible, types have to be standardized, an appropri-

ate standardization could be based on the Automo-

tive Ontology (Feld and M

uller, 2011). Finally, each

preference has a boolean property to encode whether

its value depends on certain vehicle components or

whether it is universal. The vehicle components are

determined by deﬁnition of its type and context of the

booking. In case a preference is universal, its value

has to be encoded as speciﬁed by its type.

TIS to VRS Communication

As mentioned in Section 2, one protocol designed for

the communication between a TIS and a car sharing

provider is IXSI. It deﬁnes different loosely coupled

services. These services include static data, availabil-

ity of vehicles, booking and pricing information. The

smart car extension (Beutel et al., 2016b) adds two

additional services to IXSI to allow the remote conﬁg-

uration of preferences (referred to as service 10 in the

standard speciﬁcation) and to set and track the current

trip (service 11). Each service offers the possibility to

set preferences or the destination via a request and

the possibility to subscribe to changes of preferences

Integration of Private and Carsharing Vehicles into Intermodal Travel Information Systems

315

:VRS

:Vehicle

CONNECT

ACK

SET

ACK

PUSH

. . .

UNSUBSCRIBE

ACK

Figure 2: Interaction protocol between a VRS and a vehicle.

and the trip progress. Users’ preferences are mod-

eled by a set with elements of the type BookingSet-

ting. Each BookingSetting contains a BookingSet-

tingsClassType deﬁning the type of the preference, a

decimal, a string value, the id of the current booking

and a boolean value indicating whether it depends on

the current booking target. This boolean value can

be used by the carsharing provider to indicate a pref-

erence depending on a speciﬁc vehicle component.

The trip progress is modeled by the type Booking-

ProgressType. Its properties are the time stamp of

the point of time the progress was determined, the

ETA, the current position and progress. Because of

the privacy considerations discussed in the design of

the carsharing provider, the latter two properties are

optional. After the booking of the vehicle, the TIS

sends a SetNavigationDestinationRequest to the VRS

containing the coordinates of the destination of the

current trip. If the destination is successfully applied,

the VRS sends the associated response. The next step

of the TIS is to send a BookingProgressSubscription-

Request. This enables the subscription of trip updates.

Subsequently, the VRS sends messages containing the

current booking process. If the TIS intends to change

the destination, it simply sends a SetNavigationDesti-

nationRequest again. The VRS continues to send up-

dates of the booking process until the vehicle arrives

at the destination or the TIS terminates the subscrip-

tion.

VRS to Vehicle Communication

For the communication between the VRS and the ve-

hicle, an information exchange protocol has been de-

veloped. Its structure is inspired by the smart car ex-

tension of IXSI discussed in the last section. Simi-

lar to IXSI, it allows to set preferences and the des-

tination in a request / response scheme and allows

Figure 3: Implementation setup with the Ford TDK, a Rasp-

berry Pi (a mini computer) and a cellular network router.

asynchronous subscriptions to listen for trip updates

and for changes in the preferences. Because of the

requirement of asynchronous subscriptions and bidi-

rectional communication, the protocol is designed to

work on top of WebSockets. The data model of the

protocol outlined in this section is similar to the one

discussed at the beginning of this section and the one

used in IXSI. Each message consists of an ID, a type

and a body. The ID of a message is unique in re-

gard to the current session. A type can be one of the

following: CONNECT, SET, SUBSCRIBE, UNSUB-

SCRIBE, PUSH, ACK or NACK. The body of a mes-

sage depends on its command. A possible protocol

interaction is illustrated in Figure 2.

5 IMPLEMENTATION

The goal of the implementation is to create a proto-

type of the proposed architecture to prove its feasibil-

ity. To limit the scope of the prototype, the goal is

to only implement a client on the vehicle side and a

component for a VRS.

5.1 Vehicle Module

Instead of an actual car, a Technical Development Kit

(TDK), the Ford SYNC Gen3 TDK X2, is used for

the implementation. It contains the current genera-

tion of infotainment systems which are deployed in

vehicles built by Ford and Lincoln. The included

infotainment system consists of a large touchscreen,

built-in speakers, a CD player and buttons to control

the radio, the heating and the air conditioning. As

in a normal vehicle, the communication between the

components works over a Controller Area Network

bus (CAN bus). Beside the messages necessary for

the functionality of the infotainment system, the TDK

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

316

contains a module which simulates CAN trafﬁc for

further modules of the car which are not included in

the TDK. These include, for example, the state of the

locking system or the ignition of the vehicle. A set

of buttons at the bottom of the TDK allows to send

messages over the simulated CAN bus.

Figure 3 shows a picture of the implementation

setup with the TDK, a Raspberry Pi and a cellular

network modem. The Raspberry Pi represents the car-

sharing onboard unit.

In the following, two methods are discussed which

could enable the implementation of the proposed ve-

hicle client. Smart Device Link (SDL) is a standard

to connect a driver’s smartphone with the infotain-

ment system inside vehicles

. It was originally devel-

oped by Ford and integrated in their vehicles under

the name AppLink

. SDL is designed to work with

applications running on the driver’s smartphone. Ad-

ditionally, the connected device has to be linked with

the infotainment system and the applications have to

be manually started by the driver. Thus, SDL in its

current form is not a suitable solution for the imple-

mentation of the vehicle module. In contrast to us-

ing SDL, accessing the vehicle over the CAN bus is a

rather low level approach. Due to the standardization

of OBD-II, a common interface to access the CAN

bus exists in most vehicles. OBD-II is a standard

to diagnose malfunctions in various vehicle compo-

nents. Though the protocols used in OBD-II and the

CAN bus are standardized, the implementation varies

between different manufactures and between different

vehicle generations. Unfortunately, none of the ap-

proaches presented above is an ideal solution to im-

plement a vehicle client as designed in Section 4.1.

To create a prototype for the vehicle client, the solu-

tion to access the vehicle via the CAN bus has been

preferred to the approach of using SDL. To get access

to the CAN bus of the TDK, the adapter OBDLink

SX by ScanTool

has been used. It was possible to

identify a few CAN bus messages to read and set the

state of vehicle settings. The ﬁrst preference is the

volume of the infotainment system. The volume can

be set by sending its value (between 0 and 30) to the

CAN bus. Unfortunately, no way was found to di-

rectly query the value of the current volume. To be

able to report the current volume to the VRS, the idea

is to set the volume at the start of each session (either

to the value provided by the TIS or a default one) and

to track its changes. The second preference identiﬁed

is the current frequency of the radio. Messages were

found which are sent when the knob to change the fre-

https://smartdevicelink.com

https://developer.ford.com/pages/sdl

https://www.scantool.net/obdlink-sx/

Car Sharing Provider

Sessions

Id Settings Open

8a3de

TEMPERATURE POSITION

false

ada65

TEMPERATURE POSITION

true

Preferences

Type Decimal Value String Value

TEMPERATURE

Destination

Latitude:

Longitude:

Trip Progress

Position

Vehicle 94403

Position

Temperature

21 °C

Fehler bei Google Maps melden

Figure 4: Web clients developed to test the implementation

of the server.

quency is rotated to the left or the right. Additionally,

the current frequency is constantly broadcasted. This

is sufﬁcient to read and set the frequency.

The next step is to implement a prototype for

the vehicle client. Python was chosen as program-

ming language for the implementation. Python al-

lows quick prototyping and libraries exist to commu-

nicate over the serial interface with the vehicle and

over WebSocket with the VRS. The implementation

is divided into two modules. The vehicle module im-

plements the communication with the vehicle over the

serial interface. It listens for changes in the prefer-

ences and exposes a method to apply a preference.

The server module handles the communication with

the VRS over the protocol deﬁned in Section 4.2. The

implementation is build on top of websocket-client

a WebSocket implementation for Python. The mod-

ule manages subscriptions of the VRS and exposes

SET messages to other components. Additionally, it

offers a method to send changes in preferences via a

PUSH message to the subscribed VRS. When start-

ing the client, it conﬁgures the adapter as described

above. Afterwards, it establishes a connection to the

VRS server and sends a CONNECT message. Then it

waits for changes in the preferences or for SET mes-

sages. As soon as one of them arrives, they are for-

warded to the respective module.

https://github.com/liris/websocket-client

Integration of Private and Carsharing Vehicles into Intermodal Travel Information Systems

317

5.2 Server

To supplement the vehicle client, a server was cre-

ated that mocks the behavior of a VRS in the pro-

posed architecture. It was implemented in Java as

a Spring Boot

application. The implementation is

separated into three modules. The core module han-

dles the management of vehicle sessions. If a new

vehicle client connects to the server, a vehicle session

is stored in the session store. A vehicle session is an

abstraction of the connection between the server and

the vehicle client which exposes the functionality of

the underlying protocol. The core module offers inter-

faces to backend and frontend modules. Both types of

modules are designed to be interchangeable and to al-

low multiple implementations to work in parallel. As

a consequence it is possible to extend the server with

compatibility for other protocols. The backend mod-

ule handles the connection with the vehicle client. It

implements the protocol used to communicate with

the vehicle and provides it as an implementation of

a vehicle session. When a vehicle establishes a con-

nection and sends a CONNECT message, it adds the

session to the session store of the core module.

To allow the testing of features not supported by

the vehicle client described in the previous section, an

additional web client, has been implemented which

simulates a vehicle (Figure 4). It displays its current

location on a map and provides simulated preferences

as a slider. Besides testing additional features, this

allows to test the system with multiple connected ve-

hicles.

6 EVALUATION

The goal of this section is to evaluate how far the de-

sign and implementation support the use cases listed

in Section 3 and how them compare to the systems

presented in Section 2.

6.1 Methodology

The test setup for the integration test includes the

TDK, a Raspberry Pi, a cellular modem and a test

computer. The server component discussed at the end

of the last chapter is deployed on the test computer.

The vehicle client is deployed on the Raspberry Pi.

The OBDLink SX adapter connects the TDK with the

Raspberry Pi. The cellular modem is connected to

the Raspberry Pi to allow network access under con-

ditions similar to that in an actual vehicle. Over this

https://projects.spring.io/spring-boot/

connection, it can connect to the server on the test

computer.

To initialize the preferences, a radio station and

the volume is conﬁgured on the TDK. The vehicle

client notices these changes and sends PUSH mes-

sages to the server. As a result, the table displaying

the preferences gets updated. If one modiﬁes the pref-

erences in the web client of the carsharing provider, it

sends a SET message to the vehicle client. This then

appropriately applies the preferences to the TDK.

To test the system with multiple vehicles, the ve-

hicle web client can be used to simulate additional ve-

hicles. As soon as it opens in the browser, it connects

to the server and is displayed as an additional session

in the web client of the VRS. By clicking on this new

session in the web client, it can be simulated that the

user switches to another vehicle. The VRS releases

the previous vehicle client of the TDK and terminates

its subscriptions. As a second step, the session of

the web vehicle client is acquired and subscriptions

for preferences and the trip progress are created. Ad-

ditionally, all currently known preferences (currently

displayed in the preferences part of the screen) are

sent in a SET message to the client. The client is then

automatically conﬁgured with the known preferences.

The vehicle web client can then be additionally

used to test the subscription of trip updates and the

change of the destination. By entering a coordinate

in the destination ﬁeld of the VRS web client, a SET

message with this destination is sent to the vehicle

client. This moves the destination marker (red) in the

map to the corresponding location. If the marker of

the current location (green) is moved, the client sends

a PUSH message with the appropriate trip progress to

the server.

6.2 Results

The designed system supports all use cases presented

earlier. It is able to set the destination of the naviga-

tion system before the user arrives at the vehicle and

can change the destination during a trip, based on trip

progress updates it receives from the vehicle. There-

fore, it supports the Scenarios 2 and 3. Though the

server implemented and the vehicle web client sup-

port the functionalities required, it was not possible to

implement them in the vehicle client. We do not know

whether it is possible to set the destination of the nav-

igation system via messages over the CAN bus.

Additionally, the system is able to apply arbitrary

preferences to a vehicle before the user arrives and is

able to listen to their changes. In contrast to the Mo-

bility Proﬁles proposed in (K

ummerling et al., 2013),

the functionalities discussed above work without ad-

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

318

ditional interaction with the driver. Finally, the de-

signed system works across the boundaries of differ-

ent carsharing providers. The reason for this is that

the core logic of the system is located at the TIS and

thus preferences can be applied to vehicles of all car-

sharing providers supporting the system. Although,

only a limited set of preferences has beeen imple-

mented into the vehicle client, the supported prefer-

ences show that the general approach is working and

therefore Scenario 1 is possible.

7 CONCLUSION AND OUTLOOK

In this work, a system was proposed to integrate car-

sharing vehicles into intermodal travel information

systems. To guide the design process and to create a

base for evaluation, use cases were deﬁned. The sys-

tem was designed to enable continuation of a user’s

navigation via the navigation system integrated in a

carsharing vehicle and furthermore to conﬁgure car-

sharing vehicles according to the preferences of the

user. The progress compared to similar approaches

lies in the integration of the navigation system and

the removal of necessity of any user interaction. To

prove the feasibility of the proposed architecture, a

prototype of a vehicle client and a prototype of a VRS

were built. Comparing the features provided by the

prototype with the listed use cases showed that the ap-

proach is a viable ﬁrst step to integrate carsharing ve-

hicles into intermodal travel information and by that

improve the travel experience.

The next step is to complete the implementation of

the proposed architecture. This includes an extension

for an existing TIS to manage the user’s preferences.

Such a system should be able to reason about pref-

erences to infer them for new vehicles. Additionally,

a robust implementation of vehicle clients is neces-

sary. The most promising way of realization is that

manufacturers implement these functionalities in their

vehicles natively. As mentioned in the introduction,

the popularity of carsharing increases. If the system

proposed in this work is able to accelerate this trend,

which has to be evaluated, an automobile manufac-

turer could gain a competitive advantage in the market

of carsharing vehicles. Last but not least, the system

is to be assessed for user feedback in a realistic sce-

nario with a real car.

ACKNOWLEDGMENTS

This work was conducted in cooperation with Ford

Research and Innovation Center Aachen.

REFERENCES

Berylls Strategy Advisors (2015). Carsharing – der

große Durchbruch steht noch bevor [german].

http://www.berylls.com/media/informationen/

downloads/presse/150216 Berylls Carsharing -

PM Slides.pdf, visited 2017-08-19.

Beutel, M. C., G

okay, S., Kluth, W., Krempels, K.-H.,

Ohler, F., Samsel, C., Terwelp, C., and Wiederhold,

M. (2016a). Information Integration for Advanced

Travel Information Systems. Journal of Trafﬁc and

Transportation Engineering, 4(4):177–185.

Beutel, M. C., G

okay, S., Kluth, W., Krempels, K.-H., Sam-

sel, C., and Terwelp, C. (2014). Product oriented in-

tegration of heterogeneous mobility services. In Pro-

ceedings of the 17th International Conference on In-

telligent Transportation Systems (ITSC 2014), pages

1529–1534, Qingdao, China. IEEE.

Beutel, M. C., G

okay, S., von Grumbkow, P., Hill-

brecht, D., Krempels, K.-H., Samsel, C., Terwelp,

C., Twele, H., and Wagner, H. (2016b). Mobility-

Broker Interface with Smartcar Extension based on

IXSI - Interface for X-Sharing Information Version

4. https://rwth-i5-idsg.github.io/downloads/ixsi/ixsi-

docu-smartcar-english-version.pdf, visited 2017-08-

20.

Feld, M. and M

uller, C. (2011). The Automotive Ontology:

Managing Knowledge Inside the Vehicle and Shar-

ing it Between Cars. In Proceedings of the 3rd In-

ternational Conference on Automotive User Interfaces

and Interactive Vehicular Applications (AutomotiveUI

2011), pages 79–86, Salzburg, Austria. ACM.

Kalmbach, R., Bernhart, W., Grosse Kleinmann, P.,

and Hoffmann, M. (2011). Automotive land-

scape 2025: Opportunities and challenges

ahead. Roland Berger Strategy Consultants.

http://www.rolandberger.com/media/pdf/

Roland Berger Automotive Landscape 2025

20110228.pdf, visited 2017-08-18.

Klein, N. J. and Smart, M. J. (2017). Millennials and car

ownership: Less money, fewer cars. Transport Policy,

53:20–29.

Kluth, W., Beutel, M. C., G

okay, S., Krempels, K.-H., Sam-

sel, C., and Terwelp, C. (2015). IXSI - Interface for

X-Sharing Information. In Proceedings of the 11th In-

ternational Conference on Web Information Systems

and Technologies (WEBIST 2015), Lisbon, Portugal.

ummerling, M., Heilmann, C., and Meixner, G. (2013).

Towards Seamless Mobility: Individual Mobility Pro-

ﬁles to Ease the Use of Shared Vehicles. In Pro-

ceedings of the 12th IFAC/IFIP/IFORS/IEA Sympo-

sium on Analysis, Design, and Evaluation of Human-

Machine Systems, pages 450–454, Las Vegas, USA.

IFAC HMS.

Shaheen, S. and Cohen, A. (2007). Growth in worldwide

carsharing: An international comparison. Transporta-

tion Research Record: Journal of the Transportation

Research Board, (1992):81–89.

Integration of Private and Carsharing Vehicles into Intermodal Travel Information Systems

319