On the Integration of Shared Autonomous Mobility on Demand in
Mobility Service Platforms
Felix Schwinger
1,3
, Ralf Philipsen
2
, Simon Himmel
2
, Matthias Jarke
1,3
and Martina Ziefle
2
1
Information Systems, RWTH Aachen University, Aachen, Germany
2
Human-Computer Interaction Center (HCIC), RWTH Aachen University, Aachen, Germany
3
Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany
Keywords:
Mobility Service Platform, Ride-sharing, Mobility-as-a-Service, Web Services, Platform Architecture.
Abstract:
Recently, travelers increasingly book trips that combine public transportation with emerging mobility modes
such as ride-sharing. Mobility service platforms aim to integrate this heterogeneous mobility mix on a single
software platform. In practice, only first appearances of collaborations between public transit companies and
ride-sharing companies have emerged so far. Especially with the coming emergence of autonomous vehicles,
ride-sharing services will become a vital mobility mode as part of Mobility-as-a-Service schemes. Therefore,
this study aims to research the requirements for integrating ride-sharing services into a mobility service
platform from a user-centered and technical perspective. For this, we first analyzed the overall attitude towards
autonomous ride-sharing in a citizen workshop and evaluated a prototype of the system in a small user study.
Additionally, we conceptually integrated the service into an existing reference platform for mobility services and
investigated the technical and operational differences between public transportation and ride-sharing services.
The analysis shows that autonomous ride-sharing services are integrable into a mobility service platform but
have distinct requirements that other mobility services such as scooter-sharing or public transit do not have.
1 INTRODUCTION
Due to an ongoing digitalization, the number of dif-
ferent transportation modes in urban mobility systems
has significantly risen in recent years (Shaheen and
Cohen, 2019). Next to private and public transit, mod-
ern urban transportation systems increasingly consist
of a range of smartphone-enabled mobility services
such as car-, bike-, scooter-, and ride-sharing. Road
networks are at their limit in urban areas, congestion is
the norm, and parked vehicles consume valuable space
in cities. These emergent modes may help promote
a switch from private transportation to more environ-
mentally and space sustainable mobility modes. In
particular, the heterogeneity of the travel modes of-
fers the opportunity to personalize the mobility service
perfectly to the travelers’ requirements matching the
flexibility of private transportation. However, it also
risks burdening travelers with too many travel options.
To allow travelers to handle these complex multi-
modal transportation networks, mobility service plat-
forms ( MSP s) aim to integrate different travel modes
into a single platform (Jittrapirom et al., 2017). These
platforms implement the idea of Mobility-as-a-Service
( MaaS ) and mobility-on-demand ( MoD ), where mo-
bility is not enabled by owning a private vehicle but
by subscribing to a service. Multiple MSP s are differ-
entiated depending on the degree of integration and
their underlying cooperation scenarios (Beutel et al.,
2018b). The least integrated platform only allows
viewing travel information, while the most integrated
platform offers the booking of intermodal trips that
combine products of several mobility providers. Over-
all, MSP s ease the problem of manually comparing
and combining mobility offers for the customer; the
tighter the integration on the platform, the easier the
service is usable for the customer.
Among other transportation modes, ride-sharing is
a rapidly rising mobility mode (Wenzel et al., 2019).
Ride-sharing is provided by so-called transportation
networking companies (TNCs) and describes primar-
ily door-to-door trips by taking a just-in-time called
vehicle (Rayle et al., 2016). In contrast to regular
taxis, this mobility form offers the possibility of pool-
ing customers with similar destinations in one vehicle,
thus reducing the required vehicles. Furthermore, au-
tonomous vehicles will become available in the follow-
ing years. As autonomous vehicles will be expensive,
332
Schwinger, F., Philipsen, R., Himmel, S., Jarke, M. and Ziefle, M.
On the Integration of Shared Autonomous Mobility on Demand in Mobility Service Platforms.
DOI: 10.5220/0010675000003058
In Proceedings of the 17th International Conference on Web Information Systems and Technologies (WEBIST 2021), pages 332-340
ISBN: 978-989-758-536-4; ISSN: 2184-3252
Copyright
c
 2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

their usage will be concentrated on TNCs offering
autonomous mobility-on-demand ( AMoD ) services
before becoming more publicly available. Hence, au-
tonomous vehicles are of particular interest to TNCs
(Pakusch et al., 2018). Ride-sharing is already one of
the fastest-rising mobility modes. In conjunction with
autonomous vehicles in shared autonomous mobility-
on-demand ( SAMoD ) services, the popularity may
even further rise.
While an MSP ensures that technically travelers
can use all mobility modes in conjunction, it does not
influence whether the mobility services on it are com-
peting or complementing each other and how the user
is considered in this approach. Shared scooters are
more suited for short trips and primarily displace bike,
car, or foot trips (Hollingsworth et al., 2019). Services
for short trips are often seen as complementing pub-
lic transportation, as their on-demand character makes
them especially suited for first-mile-last-mile trips (Co-
hen and Kietzmann, 2014). In contrast, ride-sharing
currently most prominently replaces taxis, public trans-
port, and private car legs (Tirachini, 2019). Herein
also lies the chance and risk of ride-sharing regard-
ing environmental, equity-related, and traffic-related
challenges: ride-sharing can compete or complement
public transportation services (Shaheen et al., 2020).
To understand why and when new mobility ser-
vices compete with established transportation modes,
it is crucial to understand the individual users’ mobility
behavior, needs, and constraints. Research shows that
especially flexibility given by owning a car (Philipsen
et al., 2020) is a key barrier for using public transport
- and this flexibility is evaluated differently for vary-
ing users. In addition to understanding the user, it is
crucial to integrate the user iterative into the whole
development circle, from scratch (Svanaes and Seland,
2004) via video-based scenarios (Flohr et al., 2020)
to prototypes of multimodal travel systems (Himmel
et al., 2016). However, when autonomous vehicles
join the game, it is even more critical to understand
user acceptance (Jing et al., 2020): the overall chances
of autonomous driving are high, but users’ constraints
have to be addressed. In addition to the complexity
of SAMoD from the autonomous vehicle’s point of
view, it is also challenging to understand which new
requirements MSP s have to fulfill when integrating
these services.
SAMoD has a pivotal role in the future of trans-
portation systems. It promises to match the flexibil-
ity of private ownership-based transportation with the
accessibility of public transportation. Its highest po-
tential is reached if the service complements public
transportation on routes with lower demand, as pub-
lic transportation offers higher throughput routes with
high demand. Recent studies suggest that SAMoD
may compete with public transportation systems with-
out regulation and the right incentives instead of com-
plementing them (Liu et al., 2017). However, most
of these studies focus on economic, societal, environ-
mental, political, or governance aspects of the problem
but rarely focus on the user or technical challenges
regarding the integration into an mobility service plat-
form ( MSP ) (Pakusch et al., 2018). This paper re-
searches the opportunities and technical difficulties of
integrating SAMoD into an MSP that interconnects
multiple available transportation modes in intermodal
journey chains. For this, we will introduce a devel-
oped prototype for autonomous ride-sharing services
consisting of web services and a corresponding mo-
bile application and conceptionally integrate it in an
MSP . We consider three relevant perspectives: the
user’s, the mobility provider’s, and the MSP operator’s
perspective while focusing on the user and technical
requirements. In this position paper, we propose first
solutions; hence the evaluation is still limited.
2 APPROACH
We identified several open questions in the litera-
ture concerning the integration of (autonomous) ride-
sharing: 1) research of user requirements integrating
of shared autonomous mobility-on-demand ( SAMoD )
services into mobility service platforms ( MSP s), 2) the
requirements of SAMoD providers toward a MSP ,
3) the novel requirements of a MSP operator regarding
the SAMoD provider integration. In the following, we
introduce the scenario of an MSP and a pre-existing
reference platform. Next, we describe our methodol-
ogy for tackling the identified research gaps.
2.1 Scenario
As the envisioned scenario for a multimodal MSP and
Mobility-as-a-Service ( MaaS ) is, if any, only imple-
mented in local projects, we will introduce it here. We
base our work on the mobility service platform on the
reference platform architecture for mobility as defined
by the Association of German Transport Companies
in its normative model VDV-436
1
. An MSP integrates
multiple mobility products from different providers
into one single platform. Figure 1 shows the mobility
service chain on an MSP , from login, to information
gathering, booking, travel, and finally, customer assis-
tance during the trip. Concurrently to other phases,
1
https://www.beka-verlag.info/advanced search result.
php?keywords=vdv+436 (only available in German)
On the Integration of Shared Autonomous Mobility on Demand in Mobility Service Platforms
333

assistance
clearing
customer service
booking informationlogin
authorization
Figure 1: Sketch of a holistic mobility chain over all phases.
the phases of authorization, clearing, and customer
service may occur. In the login phase, the customers
identify themselves towards the platform. Next, cus-
tomers may request information about itineraries and
book them in the next step. Depending on the level
of integration, these itineraries may already consist of
offers from multiple transportation companies. Finally,
the customer may receive further assistance regarding
the trip, for example, turn-by-turn directions. The au-
thorization phase handles the issuing access privileges
to the traveler, and clearing describes the phase where
the customer is billed with the actual cost of traveling.
Additionally, an MSP offers customer service along
with all steps of this holistic mobility service chain.
As VDV-436 represents a reference architecture, it
aims to capture all possible characteristics of possible
specific technical implementation of platform archi-
tectures for mobility. We, therefore, assume that the
technical concepts are easily adaptable to different im-
plementations of MSP s in other regions and do not
depend on the actual implementation of the MSP . A
possible technical platform is shown in a condensed
form in Figure 2. The behavior of all presented com-
ponents is defined, guaranteeing the replaceability of
components. For a complete overview, we refer the
reader to Beutel et al., 2018b. The architecture consists
of three main functional groups: information, platform
management, and booking. The information group
integrates travel information and products. Its router
can chain different mobility modes into intermodal
travel chains by using linked data concepts on the ex-
ternal data sources. The platform management group
deals with internal platform tasks, e. g., user manage-
ment and user preferences. Finally, the booking and
account group handles the booking of products on the
distinct external subsystems in a transaction-safe man-
ner. External mobility providers can join the platform
by providing data to the information group and adapt-
ing their booking system to receive booking requests
from the platform. For the integration of ride-sharing,
we will focus on these two external systems.
2.2 Methodology
For the first research gap related to the users’ require-
ments of the integration of SAMoD into MSP , we
information
transport schedule and
vehicle availability
intermodal router
product and price
information
external data sources
external booking
systems
platform management
user and contract
management
recommender system
clearing B2C
booking and
accounting
reseller and broker
booking system
reseller booking and
accounting manager
booking and
accounting manager
user interface
other OMPs
service controller
Figure 2: Architecture of an open mobility standard as de-
fined by VDV-436, adapted and truncated from Beutel et al.
2018b. Solid boxes define internal platform components,
dashed boxes represent external components, layered dashed
boxes indicate that more than one such component may exist.
first analyzed the overall attitudes towards such a sys-
tem in citizen workshops, went deeper using online
focus groups (due to COVID-19, no more public work-
shops were possible) and evaluated the prototype of
a SAMoD service in a small user study in a real-life
scenario in the town of Aachen. The empirical ap-
proach was based on a consecutive mix of qualitative
and quantitative methods to identify and quantify user
needs and attitudes. The qualitative procedure was
guideline-based, and the resulting discussion and inter-
view transcripts were structured and evaluated using
content analysis. The quantification was mainly done
with conventional questionnaires, based on, among oth-
ers, agreement scales and semantic differentials to cap-
ture user perceptions. For addressing the requirements
a SAMoD service imposes on an MSP (Gap 2), we
checked the organizational and technical requirements
of a developed prototypical SAMoD service against
the previously introduced reference architecture. For
this, we will introduce the system architecture of a
WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies
334

prototype we have developed and analyze how it could
be integrated into an MSP , and gather possible require-
ments. As currently, no implementation of an MSP
exists, this integration has to be performed conception-
ally. Finally, for Gap 3, regarding the needs of an MSP
towards integrated SAMoD services, we align the re-
quirements of the reference mobility service platform
with that of SAMoD providers. As of now, existing
architectures have not considered the mobility mode
offered by autonomous ride-sharing. Therefore, we an-
alyze which additional requirements arise to integrate
ride-sharing services with other transportation modes.
3 RESULTS AND DISCUSSION
In the following, we introduce the system architec-
ture for a shared autonomous mobility-on-demand
( SAMoD ) service that we developed as part of a Ger-
man research project
2
. We and the project consor-
tium developed business models, process diagrams,
and software prototypes for autonomous ride-sharing
services. This service acts as a prototypical mobility
provider for the conceptual integration into an MSP
in this paper. This integration considers the mobility
providers’, the platform operator’s, and the customers’
requirements. Our contributions to the problem are
as follows: We propose a prototypical architecture
for ride-sharing services and present selected require-
ments for such a software system. Both a frontend
application and a corresponding backend have been
implemented and evaluated with users in user tests.
Based on this prototypical application, we checked the
requirements against a previously designed MSP . The
MSP and the SAMoD platform have been developed
in a user-centered design approach, allowing easy com-
parability between the requirements. The architecture
of the MSP has not influenced the proposed SAMoD
platform, as different people were involved, and we
were interested in the differences between a special-
purpose system for ride-sharing and a general-purpose
MSP . To align the requirements, we check which in-
formation needs to be exchanged between the MSP
and SAMoD . We manually align this information flow
with the requirements of the platform operator and the
mobility service provider to retrieve the final require-
ments.
3.1 Platform for Mobility on Demand
We selected a user-centered design approach for the
ride-sharing service system’s architecture that places
2
https://www.autonomousshuttle.de/en/
scheduling and planning
vehicle
scheduling
routing engine
fleet
management
traffic
information
autonomous
vehicles
user management and booking system
user and contract
management
recommender system
product and price
information
travel information
and booking system
clearing B2C
service controller
user interface
Figure 3: Prototype system architecture for ride-sharing
services. Solid boxes define platform components, dashed
boxes represent external components, whereas layered boxes
indicate that more than one such component may exist.
the user in the center during the whole development
cycle: We first defined the user scenarios of the mobil-
ity service, from which we then derived corresponding
use-cases. The initial user requirements could directly
be derived from the use-cases. For the technical re-
quirements, we analyzed existing external systems and
external policies. Using the requirements, we listed
distinct tasks that the system is required to perform.
After grouping these tasks according to their topic to
components, we obtained the first prototypical system
architecture. We then created corresponding activity
diagrams by analyzing how the platform implements
the use-cases. With these activity diagrams, we could
then analyze the information flow between the com-
ponents for specific use-cases. Finally, we derived the
data and interaction models from the information flow,
resulting in a complete system architecture description.
Following this design methodology, we developed
the system architecture (see Figure 3). For the plat-
form’s primary task of offering on-demand mobility
offers, important data messages were defined: travel
request, travel offer, travel order, and travel confirma-
tion. The communication between user and system
is initiated in the user interface, which communicates
with the user management and booking system over a
service controller. Inside the booking system, the main
components are the product and price information sys-
tem, storing information about purchasable products
such as monthly tickets and their prices. It is also able
to annotate journeys computed by the scheduling sys-
tem with a price. The task of the travel information and
On the Integration of Shared Autonomous Mobility on Demand in Mobility Service Platforms
335

Figure 4: User interfaces of the developed system during
user testing. Top: Smartphone application managing the trip
with displayed QR code for check-in at boarding. Bottom:
Invehicle display for visualization of current trip progress.
booking system is the provision of travel information
and processing all information regarding the booking
process, i. e. handling the booking, rebooking, or can-
cellation of trips. Suppose a user inquires travel infor-
mation using a travel request, this request is forwarded
by the service controller to the booking system. The
booking systems may optionally annotate this request
with the user’s preferences using the recommender
system and sends this request to the scheduling and
planning component. This travel request includes a
pick-up and drop-off location and either a departure
or arrival time. Next, the planning component checks
whether the user’s travel request is satisfiable by one of
the autonomous vehicles with a dial-a-ride algorithm
(G
¨
okay et al., 2019). This scheduling component can
always access the current position of the vehicles and
has a real-time traffic forecast for its routing engine. If
a valid schedule for the request is found, the scheduling
component generates multiple offers for the customer.
This offer is then sent back to the user through the
booking system. Before reaching the user, the offer,
including a specific itinerary with pick-up and drop-
off locations and time windows, is annotated with a
particular price by the price information subsystem in
the booking system. If the user chooses one of these
offers, the user interface sends an order, which gets
relayed to the scheduling subsystem. The order’s va-
lidity is checked as other bookings may have already
changed the vehicles’ schedules. If the order is valid,
it will get persisted in the vehicle’s scheduling, and the
fleet management informs the corresponding vehicle
of its new schedule. Finally, either a positive or neg-
ative confirmation is generated, which is sent to the
user. All data types and the interaction protocol were
modeled using the OpenAPI specification language
and implemented for this work.
An initial test of the implementation of the en-
tire system in real traffic (Figure 4) with N = 10
users (laypersons and usability experts) and non-
autonomous vehicles indicated that the implementa-
tion concept works for different scenarios (e. g., single
trip, ride-sharing, trip cancellation, competing vehi-
cles, etc.) and was positively perceived by the users.
The mobility service itself and the interaction with the
service were rated as useful, reasonable and offering
added value, which resulted in a general willingness to
use the system. In addition to these classic usability as-
pects, a positive - in the sense of a pleasant, enjoyable,
and activating - semantic perception of the mobility
service was found regarding the user experience. How-
ever, it also became apparent that flawless communica-
tion and interaction with the vehicle in an autonomous
system are essential. Numerous challenges arise from
the user’s point of view alongside the mobility chain,
which are explored in more detail in the next chapter.
3.2 Integration of Mobility on Demand
To the best of our knowledge, shared autonomous
mobility-on-demand ( SAMoD ) has not been techni-
cally and holistically integrated into a mobility service
platform ( MSP ). Therefore, we combine these two
concepts by comparing the concept of an MSP as de-
fined by VDV-436 with the requirements elicited dur-
ing the development of the previously introduced pro-
totypical SAMoD service. We evaluate the integration
challenges along with all phases of the mobility service
chain (Figure 1). While sharing modes such as car-,
bike-, scooter-sharing have been regarded during the
development of the reference platform, ride-sharing
and autonomous ride-sharing have not. Therefore, we
analyze which new requirements stem from the con-
cept of on-demand ride-sharing and which from the
integration of autonomous vehicles.
3.2.1 Novel Concepts
For the following requirements analysis, we define and
explore the concept of a vehicle’s autonomy and the
concept of ride-sharing.
Autonomy. We regarded the levels of automation as
defined in SAE J3016
3
. The norm differentiates be-
tween six levels of automation, with Level 0 describing
no automation and Level 5 representing full automa-
tion. In Level 0 all tasks are performed by the driver,
whereas in Level 5 the passengers of the vehicle do not
necessarily have to perform any task. For analyzing
the information flow and the backend’s requirements
3
https://www.sae.org/standards/content/j3016 202104/
WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies
336

for autonomous vehicles, we classified these levels
into two parts: Level 0-3, where a human driver must
be available in the vehicle and Level 4-5 where the
driver becomes optional. Regarding autonomous driv-
ing from the platform’s perspective, no further division
is necessary. For example, only the distribution of driv-
ing tasks between driver and vehicle differs between
Level 0 and Level 3. Only starting with Level 4, real
autonomous vehicles have to be regarded, especially
because a driver can not necessarily support passen-
gers with their questions. This means that for such a
system, the autonomous vehicle must understand the
driving assignments and that users can also perform all
tasks without a driver being present. On the upside, au-
tonomous vehicles may react more quickly to updated
itinerary schedules than a human driver could.
Ride-sharing. The most prominent characteristic of
ride-sharing or MoD is that the vehicles are only oper-
ating on-demand and that travelers can share the rides.
A user can request a pickup and drop-off location, a
time, and optionally a time-frame for traveling, result-
ing in a high flexibility. The system then dynamically
computes the routes. Often only time windows and
rough places are communicated toward the customer at
first. As the departure window gets closer, the system
concretizes this time. This approach allows the system
to optimize its itineraries later on and to fit in further
mobility requests on the schedule of a vehicle (G
¨
okay
et al., 2019). The vehicles do not follow a transpar-
ent schedule for the user; therefore, traveling without
booking a journey is impossible. Due to this dynamic,
it is also challenging for passengers to identify their
assigned vehicle at the pickup location - especially for
fleets of identical colors with a low model variance -
and their stop at their drop-off location. If such vehi-
cles gather in one location, e. g., a city’s main station,
it will become cumbersome to identify a single vehicle
in a fleet of vehicles. The ride-sharing service on the
other side also needs to identify distinct passengers to
know when the journey may be continued. In a non-
autonomous vehicle, the driver may check the identity
of each customer; in an autonomous vehicle, this pro-
cess needs to be automated, possibly by relying on the
smartphone applications of the passengers.
3.2.2 Identified Requirements
Following the service chain, as defined in Figure 1, the
following differences have been identified compared to
traditional transportation modes in the different phases
of an MSP due to the novel concept of ride-sharing or
the autonomy of the vehicles. We regard differences
in the MSP and the proposed ride-sharing system.
Registration and Login. During the initial registra-
tion at the MSP , there is a greater need for verifying
the user, as users may be alone on the autonomous
vehicle. This verification may happen in person, via
online video, or based on other verification media such
as IDs or credit cards. Similar checks are sometimes
already performed by car- or bike-sharing providers.
These mobility modes have in common that the traveler
uses the vehicle alone, without the mobility provider’s
supervision. This verification should happen once per
mobility platform, so the needs between different mo-
bility providers should be aligned. As this check is
only performed on the mobility platform, this infor-
mation needs to be shared between MSP and SAMoD
provider.
Information Provision. Most MSP s support two
ways of obtaining travel information. One way is the
timetable or availability functionality. Here, a user
selects a specific location and is interested in either
the departures of scheduled vehicles near there or in
the availability of shared vehicles in the vicinity. This
information is not useful for ride-sharing, as vehicles
only adjust their schedule only on-demand after book-
ing a trip. The only sensible method for inquiring
travel information about ride-sharing vehicles is the
journey planner, which plans a particular trip and aug-
ments the schedule of a vehicle. The MSP can also
only integrate ride-sharing if both origin and destina-
tion are known in the query. Additionally, the platform
may also offer fixed products for ride-sharing, e. g.,
products like a monthly pass that are not linked to a
specific trip. However, the description of these fixed
products is identical to other already described prod-
ucts, such as a monthly ticket, not bound to specific
itineraries.
One key concept of the reference architecture for
mobility platforms is that the MSP is able to provide
all information from its local data aggregator. The data
aggregator operates on semantically linked data for the
integration of different mobility modes and products.
Suppose a user, for example, inquires about currently
available shared bicycles or the timetable for a specific
bus stop. In that case, the platform is able to provide
this information without requesting it from the mobil-
ity operator. Therefore, the mobility providers must al-
ways provide the necessary information to the MSP as
an external data supplier. The platform itself then han-
dles the further steps of computing integrated mobility
itineraries. For MoD services (even non-autonomous),
this approach is unsuitable: for strategic reasons the
service provider will neither share the position and
state of its vehicle fleet in real-time as crucial trade
secrets can be extracted for it, nor will it share its route
On the Integration of Shared Autonomous Mobility on Demand in Mobility Service Platforms
337

planning algorithm with a third-party, as this would
be required to compute valid ride-sharing trips. There-
fore, such information will not be shared with an MSP .
Currently, the MSP only provides information on actu-
ally booking rides in its trip planner, meaning that it
can also not estimate which trips the SAMoD provider
can fulfill. Proposed standards for standardized ride-
sharing application programming interfaces ( API s),
such as GTFS-flex
4
, only allow general information
about the booking of ride-sharing services, such as a
geofence and time windows in which booking rides
is possible. These API s, however, lack information
on a trip level. This means that ride-sharing services
break the key concept of data locality and that mobility
platforms are required to integrate an external booking
system directly into the routing phase. However, sup-
pose a mobility provider is directly integrated into the
routing process. In that case, it needs to reply to many
travel requests, some of which are directly discarded
and never shown to customers. This becomes apparent
when regarding the integration of public transit and
ride-sharing: The algorithm has to find out where to
best end a public transit leg and begin the ride-sharing
leg.
Booking. While the booking process of intermodal
mobility itineraries itself remains the same, specific
characteristics of on-demand ride-sharing have to be
considered. One key aspect here is the on-demand
character of ride-sharing services, which means that
each mobility request is answered with an individual-
ized trip. There is a limit on how long the mobility
provider can guarantee the validity of offered trips.
The booking of other passengers may also influence
the schedule so that a specific offering is no longer
valid. Partial solutions to this problem include that the
customer does not receive a specific departure time
and location but rather a location and time window
that will get updated in real-time once the departure
time is getting nearer. Locking offers to a customer
to ensure that an offer is bookable for a specific dura-
tion is infeasible in practice: many travel requests on
a mobility platform are performed for informational
purposes without booking a particular trip. Especially
with the aforementioned aspect of being directly inte-
grated into the routing process, this becomes challeng-
ing. This means that even under regular operation, the
booking of ride-sharing trips may fail as the mobility
provider cannot fulfill the initially promised route as
the customer waited too long between the inquiry of
the journey and the actual booking.
As ride-sharing bookings will fail more often than
the booking of regular public transit tickets, the MSP
4
https://github.com/MobilityData/gtfs-flex
must ensure that the booking of intermodal trips is
made in a transactional way. If a customer books a
trip spanning over multiple service providers, the plat-
form has to communicate with each of these service
providers for the actual booking of the individual trips.
It must never happen that the customer of the MSP re-
ceives and is billed for part of the tickets of a complete
travel chain, as parts of the bookings failed. These
internal booking steps may fail; for example, a user
books a trip, including a ride-sharing and train leg.
When booking, the ride-sharing operator cannot ful-
fill the initially proposed route anymore because the
proposed vehicle has reached its capacity limit in the
allotted time slot as another passenger booked a trip.
Now the customer should not receive the also included
train ticket of the journey, but rather the whole booking
of the travel chain must be rolled back. Therefore, the
systems of the mobility service providers must provide
either a way to cancel bookings for a specific time after
the initial booking or must implement locking mecha-
nisms that ensure that either all mobility services are
booked or none.
Once an itinerary including ride-sharing legs is
booked, the ride-sharing provider needs to be informed
about the booked route in order to persist it into its fleet
management. Furthermore, the ride-sharing provider
must be informed about potential delays on previous
legs for seamless integration. For smaller time devia-
tions, the provider may be able to adapt the schedule
to real-time data, compensating for possible delays.
Travel Assistance. In the travel assistance phase,
the system assists the customer with various tasks re-
garding their mobility. These tasks include finding the
correct departure location, communicating potential
delays to the traveler, helping the traveler identify the
proper vehicle to board, or helping the customer in
case of disturbances to the itinerary. This vehicle iden-
tification is more complex for ride-sharing vehicles,
as the trips and the identification means are more dy-
namic. Especially for regions with many departures or
arrivals, this will be a challenge. Safely identifying the
correct vehicles may technically be done with the help
of QR-codes the travelers are required to scan when
entering the vehicle, but identifying the right vehicle
from far away remains challenging. The system may
send identifiers, such as a vehicle number or a vehicle
name and the exact current vehicle position for visual-
ization to the traveler beforehand. Once the traveler is
on board, she must also exit the vehicle at a specific
stop again. or this, the system might show specific
stop information inside the vehicle with the help of
pictographs and send it to the user’s mobile application.
In case of delays along a booked multimodal journey,
WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies
338

the MSP may propose alternatives to the customer,
e. g., the ride-sharing leg may be postponed when a
prior leg is delayed.
Authorization. During the authorization phase, pas-
sengers receive their tickets. Depending on the actual
implementation of the autonomous mobility service,
the system may be open or closed. In a closed system,
people cannot enter the vehicle without valid autho-
rization, e. g., the doors of the vehicles do not open
without a valid ticket. In an open system, everyone is
free to enter the vehicles, as there is no physical bar-
rier hindering people from doing so. For autonomous
ride-sharing, closed systems will likely emerge, as
the system needs to know when all passengers have
boarded to continue the journey.
From the user’s point of view, ride-sharing
providers must take the perception of safety into ac-
count. In addition to general vehicle safety, the in-
fluence of other passengers comes into play here. It
became apparent that users are concerned that other
passengers could impair the vehicle’s cleanliness and
safety, as well as the safety of any goods to be trans-
ported, without the control provided by the human
driver in a conventional vehicle. Interviews revealed
that users - especially for specific private trip purposes -
prefer a closed system where they can influence board-
ing. Alternatively, cameras and microphones for se-
curity purposes would be acceptable from the user’s
point of view, while for pure interaction between user
and vehicle, this is not wanted (Biermann et al., 2020).
Clearing. Clearing is the phase in which the cus-
tomer is billed. When and how a bill is created de-
pends on the implementation of the mobility service.
We identified three categories that influence the price
of the ride and the phase of the billing. The first cate-
gory consists of the initial request parameters, such as
the predicted duration of the ride and the booked vehi-
cle class. The second category describes the system’s
usage when the ride is started: A mobility provider
may reduce the cost if a customer utilizes a vehicle
with a high sharing-ratio or in times of low system
usage. The last category describes the parameters of
the actual trip. A ride-sharing provider may reduce
the price if the vehicle arrives particularly late or in-
crease it if the customer was repeatedly late. The actual
billing may happen before the booking, on pickup, or
after drop-off, depending on the business model.
Customer Service. The customer service supports
the traveler during all phases of the mobility service,
from problems regarding the login, the inquiry of travel
information, the booking of itineraries, or difficulties
during the travel. Most new problems will, however,
arise during travel on autonomous vehicles. User tests
in the early stages of system development have shown
that interaction with the vehicle gains in importance as
soon as the fallback level ”human driver” is no longer
present to compensate for any weaknesses in the com-
munication design. This observation suggests that
the customer service needs to quickly assist the users
and address matters that the vehicle’s driver usually
handles. For this, the customer service must be imple-
mented through the application of the mobility service
platform so that the service representative can retrieve
the current travel context of the user without needing
to inquire about everything from the user. Conversely,
the vehicle and mobility application user also expects
full transparency for the current progress of the trip
and any potential changes (Biermann et al., 2020). It
is also crucial that all security important features are
also directly usable without interacting with a smart-
phone. For example, an emergency button needs to be
placed inside the vehicle; providing the functionality
only inside the application is insufficient.
4 CONCLUSION
In the future, mobility services must be environmen-
tally sustainable while also being flexible enough to
fulfill all requirements of travelers. Single travel
modes, such as public transit, can never achieve the
flexibility of personal transportation such as a private
car. Therefore, different travel modes have to be bun-
dled to choose the mode of transportation according
to their specific needs for the journey. The integra-
tion of mobility service providers on a single platform
and the combination of their products offer immense
possibilities. These, in turn, result in a high poten-
tial for personalizing the mobility service: on the one
hand with regard to the composition of the multimodal
transport chain, and on the other hand with regard to
the individualization of the autonomous mobility ser-
vice itself, which can be individually adapted to the
requirements and needs of different user groups and
characteristics.
In this paper, we motivated the need for mobil-
ity service platforms and the integration of MoD . In
contrast to related work, we have focused on user re-
quirements and derived technical requirements for the
integrated services. We have introduced the system ar-
chitecture of ride-sharing services developed in a Ger-
man research project to reach this goal. We compared
this service with an existing standard for a reference
platform for mobility providers. This conceptual in-
tegration has shown that integrating autonomous ride-
On the Integration of Shared Autonomous Mobility on Demand in Mobility Service Platforms
339

sharing services into intermodal journeys is feasible.
We are mainly interested in researching flexible
alternatives to personal cars towards climatic-required
environmentally sustainable transportation. In partic-
ular, the spatial bundling of mobility services in so-
called mobility hubs sounds promising. These mobility
hubs may allow users to flexible access a multimodal
transportation network, offering similar flexibility as
their car. These novel transportation systems may
be tested and evaluated with the help of simulation
frameworks. Furthermore, we must research the user
requirements on tightly integrated intermodal mobility
itineraries in greater depth to be capable of developing
a demand-oriented and accepted mobility offer.
ACKNOWLEDGEMENTS
This work has been partly funded by the Fed-
eral Ministry of Transport and Digital Infrastructure
(BMVI) within the funding guideline “Automated
and Connected Driving” under the grant number
16AVF2134B. The authors would also like to thank
the APEROL consortium for the productive exchange
and contributions: https://www.autonomousshuttle.de/
en/project-partner/.
REFERENCES
Beutel, M. C., G
¨
okay, S., Jakobs, E.-M., Jarke, M., Kasugai,
K., Krempels, K.-H., Ohler, F., Samsel, C., Schwinger,
F., Terwelp, C., et al. (2018a). Information system
development for seamless mobility. In Smart Cities,
Green Technologies and Intelligent Transport Systems.
Springer.
Beutel, M. C., G
¨
okay, S., Ohler, F., Kohl, W., Krempels, K.-
H., Rose, T., Samsel, C., Schwinger, F., and Terwelp, C.
(2018b). Mobility service platforms - cross-company
cooperation for transportation service interoperability.
In Proceedings of the 20th International Conference
on Enterprise Information Systems - Volume 1: ICEIS,,
pages 151–161. INSTICC, SciTePress.
Biermann, H., Philipsen, R., Brell, T., and Ziefle, M. (2020).
Shut up and drive? user requirements for communica-
tion services in autonomous driving. In International
Conference on Human-Computer Interaction, pages
3–14. Springer.
Cohen, B. and Kietzmann, J. (2014). Ride on! mobility busi-
ness models for the sharing economy. Organization &
Environment, 27(3):279–296.
Flohr, L. A., Janetzko, D., Wallach, D. P., Scholz, S. C., and
Kr
¨
uger, A. (2020). Context-based interface prototyping
and evaluation for (shared) autonomous vehicles using
a lightweight immersive video-based simulator. In
Proceedings of the 2020 ACM Designing Interactive
Systems Conference, pages 1379–1390.
G
¨
okay, S., Heuvels, A., and Krempels, K.-H. (2019). On-
demand ride-sharing services with meeting points. In
VEHITS, pages 117–125.
Himmel, S., Zaunbrecher, B. S., Ziefle, M., and Beutel,
M. C. (2016). Chances for urban electromobility. In
International Conference of Design, User Experience,
and Usability, pages 472–484. Springer.
Hollingsworth, J., Copeland, B., and Johnson, J. X. (2019).
Are e-scooters polluters? the environmental impacts
of shared dockless electric scooters. Environmental
Research Letters, 14(8):084031.
Jing, P., Xu, G., Chen, Y., Shi, Y., and Zhan, F. (2020). The
determinants behind the acceptance of autonomous ve-
hicles: a systematic review. Sustainability, 12(5):1719.
Jittrapirom, P., Caiati, V., Feneri, A.-M., Ebrahimighare-
hbaghi, S., Alonso Gonz
´
alez, M. J., and Narayan, J.
(2017). Mobility as a service: A critical review of defi-
nitions, assessments of schemes, and key challenges.
Liu, J., Kockelman, K. M., Boesch, P. M., and Ciari, F.
(2017). Tracking a system of shared autonomous vehi-
cles across the austin, texas network using agent-based
simulation. Transportation, 44(6):1261–1278.
Pakusch, C., Stevens, G., and Bossauer, P. (2018). Shared
autonomous vehicles: Potentials for a sustainable mo-
bility and risks of unintended effects. In ICT4S, pages
258–269.
Philipsen, R., Brell, T., Biermann, H., and Ziefle, M. (2020).
On the road again-explanatory factors for the users’
willingness to replace private cars by autonomous on-
demand shuttle services. In International Conference
on Applied Human Factors and Ergonomics, pages
173–185. Springer.
Rayle, L., Dai, D., Chan, N., Cervero, R., and Shaheen, S.
(2016). Just a better taxi? a survey-based compari-
son of taxis, transit, and ridesourcing services in san
francisco. Transport Policy, 45:168–178.
Shaheen, S. and Cohen, A. (2019). Shared micromoblity
policy toolkit: Docked and dockless bike and scooter
sharing.
Shaheen, S., Cohen, A., Chan, N., and Bansal, A. (2020).
Sharing strategies: carsharing, shared micromobility
(bikesharing and scooter sharing), transportation net-
work companies, microtransit, and other innovative
mobility modes. In Transportation, Land Use, and
Environmental Planning, pages 237–262. Elsevier.
Svanaes, D. and Seland, G. (2004). Putting the users center
stage: role playing and low-fi prototyping enable end
users to design mobile systems. In Proceedings of the
SIGCHI conference on Human factors in computing
systems, pages 479–486.
Tirachini, A. (2019). Ride-hailing, travel behaviour and
sustainable mobility: an international review. Trans-
portation, pages 1–37.
Wenzel, T., Rames, C., Kontou, E., and Henao, A. (2019).
Travel and energy implications of ridesourcing ser-
vice in austin, texas. Transportation Research Part D:
Transport and Environment, 70:18–34.
WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies
340