system and data integration is a prominent research
field (Figueiredo et al., 2001).
(Fluhr and Lutz, 2011) define special use case
types for electric vehicles and underline their impor-
tance for the development of comprehensiveinforma-
tion system architectures. Similarly, our work starts
out from outlining the use cases.
(Barth et al., 2002) focus on wireless communi-
cation of shared vehicle systems and describe a data
communication architecture for sharing systems with
multiple stations. (Beutel et al., 2014) propose an ar-
chitecture for comprehensive travel information sys-
tems and touch on the issue of interfacing heteroge-
neous mobility modes. Thereby, methods of data in-
tegration are addressed.
Furthermore, (Doshi, S., 2010) focuses on the de-
velopment of a multimodal traveler information sys-
tem and describes an interface with a limited amount
of functionalities.
3 USE CASES AND APPROACH
Integration of different mobility providersinto one in-
formation system which provides a central interface
to the user is challenging. Current methods which in-
volve redirecting users from the TIS to the VRS for
further information and booking services, lowers the
usability and quality of the process.
Therefore, a protocol is needed which allows a
seamless integration of one or more VRS into a sin-
gle TIS which handles vehicle information, bookings,
and price information.
3.1 Use Case Evolution
To investigate possible effects, two use-cases are pre-
sented, with and without VRS integration, taking into
consideration the roles represented in Figure 1.
TIS Operator
Travel
Information
System
VRS Operator
Vehicle Sharing
System
User TIS
IXSI
Figure 1: Overview Roles.
Without Integration
Today, Jack has a business appointment with a new
customer to discuss a project in Cologne later that
day. At the moment, he is sitting in his office in
Aachen, so he needs to plan a trip from Aachen to
Cologne. For this purpose, he uses a TIS to request
several travel chains. The results represent solutions,
using public transport, but no VRS options. To get
further options, e.g. car sharing, he has to explicitly
query a VRS to get information about the availability
of nearby stations and cars. Jack has decided to take
the car sharing option, despite the fact that he has to
walk one kilometer to the next car station. He stops
further efforts to find a better solution, because com-
bining public transport and car sharing is too complex
and time-consuming.
With Integration
Jack’s colleague, Linda is in the same situation, but
her appointment is one day later. She has access to a
novel TIS with a full integration of the VRS. As input
for her request she is using her office address as the
starting point, the customer’s address as the destina-
tion, the arrival, and return time. As result she gets
a list of trips with public transportation and car shar-
ing, separated and combined. She decides to take the
route which involves traveling by bus to the carshar-
ing station for the first kilometer. From there she is
going to drive the carsharing vehicle the rest of the
way. She is not worried about her plans, because the
TIS checked implicitly the availability of the car and
in the next step she can book it directly without in-
volving the VRS.
Interlinking Between TIS & VRS
Considering both use cases, the integration of the
VRS into the TIS shows significant improvements
of usability. One fundamental piece is the integra-
tion of the VRS into the TIS, which covers all neces-
sary functionalities (e.g., availability query and vehi-
cle booking). For this purpose, IXSI (Interface for X-
Sharing Information), which connects the VRS with
the TIS, was developed, In the following section the
functionality and general structure of IXSI are pre-
sented.
3.2 Hierarchy Model
The hierarchy model of IXSI describes different qual-
ities of information coupling based on service groups.
Furthermore, it contains recommendation for various
levels of implementation.
The interlinking between TIS and VRS needs at
least the implementation of Service 1 (static data) by
both systems. Figure 2 shows the dependencies be-
tween services.
Service 1 (static data) exchanges information about
providers and static data of booking targets (see
Subsection 4.1). For example, sharing stations
(VRS) can be presented in a TIS.
WEBIST2015-11thInternationalConferenceonWebInformationSystemsandTechnologies
294