Demand-Responsive Shared Transportation: A Self-Interested Proposal

Abstract

With the world population highly increasing, efficient methods of transportation are more necessary than ever. On the other hand, the sharing economy must be explored and applied where possible, aiming to palliate the effects of human development on the environment. In this paper we explore demand-responsive shared transportation as a system with the potential to serve its users’ displacement needs while being less polluting. In contrast with previous works, we focus on a distributed proposal that allows each vehicle to retain its private information. Our work describes a partially dynamic system in which the vehicles are self-interested: they decide which users to serve according to the benefit it reports them. With our modelling, the system can be adapted to mobility platforms of autonomous drivers and even simulate the competition among different companies.

1. Introduction

As the world’s population increases, the scarcity of our planet’s resources becomes apparent. Responsible authorities have developed a strong interest in the sustainability of our means of production as well as our way of life. Urban centres, for example, need to improve their services to make them competitive in today’s world. By implementing artificial intelligence in the different systems that make up a city, it becomes a Smart City. Among the different city systems, the urban transit system stands out as one of the most complex and dynamic. However, most affordable solutions still consist of high-capacity transport with fixed routes and stops, to whose operation users have to adapt. The considerably more expensive alternatives focus on a completely individual service, which does not favour a possible reduction of greenhouse gas emissions or congestion avoidance.

In the current ever-changing dynamic ecosystem that cities define, static systems have become, if not obsolete, outdated and often uncomfortable to use. Demand-responsive transportation (DRT) systems initially served people with special needs or those who lived in rural, ill-connected areas of a city or country. This type of mobility is characterised by its flexibility to adapt to different demand patterns. At first, this meant creating routes according to the departure location of users specifically. Nowadays, however, we see some demand-responsive behaviour implemented in most current transportation services. Ranging from picking a customer up at their desired location to increasing the number of vehicles in a fleet in periods of high demand, plenty of strategies try to make the service operation reactive to the demand.

Introducing the concept of shared transportation to DRT systems, we can develop demand-responsive shared transportation (DRST). DRST services can offer a reasonable middle-point between the stiffness of public transport and the pollution and individuality of dial-a-ride services. This mobility features strategies like dynamic modification of vehicle routes and stops, on-demand creation of routes and dynamic dispatching of vehicles according to demand. Shared mobility, however, generally involves a lower customer satisfaction with the service if compared to individual mobility. In addition, dynamic systems are complex, and their degree of dynamism affects their operation costs. DRST presents the challenge to find the balance between flexibility, shareability and sustainability of its fleet model so that (1) the service is economically viable, (2) the quality of service is maximised and (3) the pollution derived from its operation is minimised.

Most DRST research focuses on exploring service configurations, management and operation strategies to find the equilibrium among the above-mentioned indicators. For that, it is necessary to model and parameterise the transportation system, which is generally done through either mathematical or agent-based approaches. In this work, we focus on agent-based modelling (ABM), as it allows the design of behaviours for each component of the system and the analysis of the system’s operation, from which interactions and synergies may appear.

Regarding service operation, however, the reviewed publications mainly propose centralised systems. In this type of system, a central coordination entity makes all decisions, while the fleet vehicles are expected to follow every order. In practice, a manager entity accepts or rejects travel requests, assigns and modifies vehicle routes and organises vehicle dispatching. In contrast with the centralised operation, we find decentralised systems. Decentralisation allows the decision making to be performed individually by each component of the system, taking into account that their operation must be coordinated. Given the lack of works that apply distributed techniques to their modelling, we want to explore a decentralised operation in our DRST system. Decentralisation allows for implementation with open fleets, whose number of vehicles is variable and favour the autonomy of vehicles (and drivers). Transportation services like Uber are implemented with open fleets, and their drivers can choose which requests to accept according to their own preferences. Inspired by this, we propose developing the service’s operation from a distributed and self-interested perspective.

Self-interested agents (or entities) are those whose actions are guided by their own private objectives. These agents accurately represent many aspects of human behaviour, which is generally motivated by personal gains. When many of these agents operate in a shared environment (such as a city), they define a non-strictly competitive scenario. The goals of the agents might not be opposed, but their operation to reach the goals may cause conflicts with the operation of other agents. The field of game theory [1] explores the interactions among self-interested entities, offering tools to develop coordination techniques that ensure a conflictless operation. In addition, automated negotiation algorithms can also be applied for conflict resolution. Modelling with self-interested agents allows us to reproduce a DRST system where vehicles of different enterprises may “compete” to serve the customers of one mobility platform. We believe such a competition may result in a better quality of service for the user and higher adaptability of the system to the demand.

We hope to open a discussion on distributed demand-responsive shared mobility with this work. The aim is to analyse and discuss the requirements a DRST system needs if its fleet is implemented by self-interested vehicles. In accordance with the above, we propose a system architecture for a partially dynamic system that accepts real-time travel requests as well as bookings. We discuss the particularities that a fleet of self-interested vehicles involves and describe how the assignment of bookings and requests works in our distributed paradigm.

The rest of the paper is structured as follows. Section 2 discusses relevant works in the field of DRT systems, focusing on the differences in configuration and modelling approaches. Section 3 presents an overview of the proposed system, briefly describing our modelling and the system’s architecture. Section 4 discusses the operation of the static subsystem of our proposal, which takes care of booked trips. Section 5 describes how our system deals with real-time travel requests. In Section 6 our proposal is analysed and compared to other works. Finally, Section 7 assesses our work and comments on future extensions.

2. Related Work

Among the many works that explore DRST systems, three research currents stand out: service impact and viability assessment, system modelling and operational strategy optimisation. The current proposal lies between the last two, which are generally addressed together in scientific papers. In this section, we discuss different contributions to the field of demand-responsive mobility, grouping them according to the previously mentioned research currents.

There has been extensive research on the topic in hand, starting around the 1990s, when flexible transportation was aimed at disabled people [2]. Later, it evolved into a kind of public transport operated in zones with a low population density or low demand. Nowadays, it is being considered a potential mode of transportation for the general public, although its usefulness with respect to traditional transportation alternatives is yet to be demonstrated. Many recent works focus on the impact assessment and economic viability of DRST services. This type of research does not focus on algorithms or optimisation. Nevertheless, it is an essential part of mobility research, as it deals with transportation policies and user behaviour. As it is common in transportation research, most of these works are focused on particular cities or rural areas whose population lacks efficient mobility services. Alternatively, some authors propose using DRST services to substitute unproductive and ill-suited traditional transportation methods. The work in [3], for instance, proposes the replacement of the bus service in the city of Velenje (Slovenia) with a combination of bike-sharing and DRT systems. Their cost analysis reveals that the new system would not incur a much higher cost for the municipality while covering the citizen’s displacement needs much better than the current service.

A very relevant study for our particular modelling of DRST is the work in [4], where authors assess the implementation of an autonomous DRST service that communicates the rural area surrounding the city of Bremerhaven (Germany) with its city centre. Through multi-agent simulation, the authors find that operational and environmental costs significantly decrease if the individual transportation vehicles are entirely substituted with a fully automated DRT service. Their conclusions, however, remark how a fully autonomous operation of vehicles is crucial for the economic viability of the service. Cutting operator (driver) costs is essential to offer a competitive and attractive price policy. Our proposal bears this in mind and, although it could be applied to human-driven vehicles, the coordination methods we explore can be employed by autonomous vehicles once technological advances allow their implementation.

The interest in demand-responsive transportation also comes from its inherent sharing economic model. In a sharing economy, goods and resources are collaboratively shared by individuals and groups. From a general perspective, the sharing economy can reduce resource consumption. Focused on transportation systems, it can improve their sustainability by reducing, for instance, carbon dioxide emissions. In this regard, the authors in [5] present a hybrid unsupervised learning model which categorises taxis according to many features that are related to their CO₂ emissions. Their model proves useful to cluster vehicles with similar degrees of emissions and identify the most polluting ones for further improvements.

Reviewing the literature, we identified a set of elements which are common among all DRT systems (routes, stops, and driver strategy, among others), although the use of these is highly configurable, varying in each specific system.

Table 1. Review of Demand-responsive transportation system configurations. Column headers identify common elements to all systems. Rows enumerate configuration options of their corresponding element. Read from top to bottom, the options transition from a non-flexible shareable system to a flexible but less shareable system.

Stops	Routes	Fleet
Fixed	Fixed	Cooperative
Flexible	Flexible	Decentralised
On-demand	Hybrid
	On-demand
Vehicle Capacity	Services	Dispatching
+20 passengers	Trip reservation	All vehicles available
8–20 passengers	Real-time requests	Dynamic
4–8 passengers	Hybrid
1–4 passengers

enumerates the observed configurations. Such a variety of options presents advantages and disadvantages. On the one hand, a concrete system can be adapted to fit the mobility needs of a specific community or group of users. Many strategies can be followed, whether through flexible routes and stops, allowing reservations, changing timetables or more.

On the other hand, high flexibility in configuration can lead to a more costly implementation. In addition, in terms of research, each particular work focuses on a specific system configuration and characteristics. This may result in the type of DRST system that a transport manager is interested in not being sufficiently researched to be adequately implemented.

As commented in the introduction, many works focus on the research of management strategies and fleet operations that permit an economically viable, sustainable and reliable service [6]. These indicators must be defined according to the concrete service being researched. The balance among the indicators is generally found through experimentation with different system configurations. Besides this, an appropriate approach to model the system must be chosen. The most popular approaches for the topic at hand are either mathematical or agent-based, being the latter generally coupled with simulation. Following, we comment on relevant works which present the characteristics stated above.

The work in [7] models the dynamics of a DRT system mathematically and aims to identify a management strategy that incentivises system users to adapt the timing of trip requests uniformly over time. At the operational level, three strategies are identified concerning the pickup and dropoff of users: (1) minimise total distance travelled by finding the next closest pickup/destination point at each stop; (2) alternate between pickup and dropoff phases (of n customers each), reducing travel time variance; (3) each pickup is followed by the nearest unloading and vice versa. The total system cost is estimated according to the operational capacity of the system and the number of requests waiting to be served. Finally, it is a linear combination of the number of vehicles, driver salaries and energy and maintenance costs. The distinguishing feature of this work is that it studies the saturated system, with a number of waiting requests higher than the system’s operational capacity. The authors then aim to find an equilibrium among customers from the congestion theory point of view. A dynamic pricing policy is applied to motivate the users to advance or delay their requests to reduce their prices.

In contrast with the previous, the work in [8] uses ABM to describe a DRST system with fixed and flexible routes and stops. The authors aim is to analyse the necessary trade-off among the system’s economic efficiency, the service quality and the fleet’s sustainability. Their experimentation is performed with the NetLogo (https://ccl.northwestern.edu/netlogo/, accessed on 19 October 2021) simulator and based in a real-world setting. Different system configurations are tested, including fleet size, vehicle capacity and dispatching strategies. The results present a specific system configuration that guarantees the system’s economic viability while improving its sustainability with respect to a taxi service, although this inevitably comes at the cost of a reasonable reduction in service quality. Balancing the metrics above proves to be a challenge in any DRST research.

In line with the functional design of DRST systems, the authors in [9] extend their previous work to compare, through multi-agent simulation, their system with a traditional taxi service. They define three indicators: transport intensity, related to operational costs and environmental impacts; total unit cost, which represents the total costs of the system; effectiveness in terms of satisfied customers. The system was measured by varying the number of vehicles and their capacity. Their results point out how in low demand conditions, the taxi service outperforms DRST. On the contrary, during periods of high demand, the higher capacity of shared vehicles enables the demand-responsive service to stand out. Nevertheless, their analyses are inconclusive for medium demand intervals.

Additionally, within the operational strategy of a DRT system, one must decide the dynamism of its operation. Given the demand-responsive feature of this service, most works (including the last two mentioned) present fully dynamic systems, where the demand is unknown, and the requests are dealt with in real-time. In contrast, the authors in [10] model a service with degree of dynamism. Compared to fully dynamic systems, theirs accepts bookings, which are requests that are known before time. A request is defined by pickup and destination locations as well as a time window describing the acceptable times for the client to be picked up and dropped off. Their system works in two steps. First, all the static requests are divided among the fleet’s vehicles, creating an initial routing for the day. Then, as the fleet operates, dynamic requests appear. These requests are assigned to a vehicle ensuring minimal cost increments and respecting time window restrictions of the already assigned requests. If no vehicle is fit to serve the request, a new vehicle is dispatched, or the request is rejected. The conclusions drawn from this paper indicate that a dispatching system incurs higher system costs and serves fewer requests when the request arrival is partially dynamic, compared to static or fully dynamic operations.

In this paper, we model a system that is inspired in the revisited works. Nevertheless, we introduce two features that suppose a new approach to demand-responsive transportation.

On the one hand, we want to explore the potential of shared demand-responsive transportation. Shared transportation [11] consists of reducing the number of vehicles in a transport system by grouping different passengers, initially not related to each other, in vehicles with a capacity for two or more users. Generally, passengers are grouped so that the vehicle route can meet their transportation needs (regarding time and location). Therefore, passengers with origin and destination locations close to each other or whose origin or destination points are on the route to another passenger will be grouped together. Shared mobility has the potential to favour sustainability in transport systems by reducing the number of operating vehicles. However, it can also lead to a reduction in user satisfaction [12,13], because as the system becomes more shareable, it also becomes less flexible and adaptive to the different transportation requests of each individual user.

On the other hand, we want to develop a decentralised system, which includes the possibility for different transportation companies to serve the same demand. Most of the works that research demand-responsive transportation describe centralised systems, where a manager entity has full control over the vehicle fleet. The dispatching of vehicles, acceptance and assignation of transportation requests and vehicle routing are all decided by the system. Although some centralised systems include compensations for drivers forced to change their routes in real-time [14], most assume that drivers will act according to the orders of the central entity. In contrast to this, our system will model vehicles as self-interested agents, which act according to their own private interests. The transports in our system will have the chance to accept or reject requests and even alter their routes according to the benefits or costs that these changes would imply for themselves. Consequently with the stated above, the fleet of our system can be implemented by either fully autonomous or human-driven vehicles.

According to [15], a taxonomy on the coordination of autonomous vehicles, with our self-interested modelling of vehicles, we need to apply agreement or negotiation approaches to sort out the operation of the fleet. Therefore, we propose game-theoretic and automated negotiation techniques [16]. Modelling with self-interested agents allows us to reproduce a competition among drivers of different companies. These drivers, although mainly interested in their own benefit, are also keen to coordinate with potential competitors to optimise both their own operation and the operation of the global mobility system.

Following, we describe our system’s particularities, present its infrastructure and discuss its operation.

3. Overview

From a general perspective, a demand-responsive transportation system works as follows: users issue a travel request indicating the location and time they want to be picked up and their desired destination. Then, the fleet manager chooses a vehicle, among the available, to serve the customer request. This involves driving to the customer’s location, picking them up and dropping them off at their destination. All of this has to be performed considering any possible time restrictions of the customer’s request (pickup time, maximum arrival time). The assignment of requests to certain vehicles is performed in a centralised manner, aiming to maximise both the system profits and customer satisfaction. For this, routing and scheduling algorithms compute the best global assignment each time a travel request arrives. This computation may result in one or many vehicles having to dynamically change their own route to attend to the new requests they have been assigned. With a centralised system, however, it is assumed that all vehicles will be willing to adopt those changes, as they have no real willpower.

In contrast with the stated above, our proposal consists of a partially dynamic demand-responsive transportation system that makes use of autonomous (in terms of will) shared vehicles to serve its users. Our system focuses on the decentralisation of the service and the self-interest of the system’s vehicles. This type of autonomous vehicle has its own private goals and keeps its information (and its customers’ information) private. With this modelling, we can a have system that serves customers from different mobility platforms or companies. Therefore, the vehicle fleet of the system shares properties with open fleets. The total number of vehicles may vary, and each individual vehicle acts as an autonomous entity. The goal of the fleet is to serve as many travel requests as possible, maximising customer satisfaction while minimising overall costs. This goal, however, is achieved through the self-interested behaviour of the vehicles, who aim to maximise their own benefits, thus also reducing costs. Similarly to customers, the fleet may be integrated with vehicles from different companies. To make the system suitable for shared mobility, we assume that vehicles have a capacity that ranges from four to eight customers.

Although the utility that serving a customer request reports to each vehicle is private, there are a series of shared elements among all vehicle fleets. The vehicles have routing and scheduling algorithms that enable them to plan their operation according to their assigned tasks and time windows. In addition, a traffic condition estimator is available for all vehicles so that they estimate, to some extent, the time that will require serving a concrete travel request. The information retrieved by such a system is the same for every vehicle.

The crucial difference with respect to a centralised system is that self-interested vehicles have the will to decide whether to serve a travel request is in their best interest or not (if it reports them more benefits than costs). In addition, travel bookings and requests in our system are visible to every vehicle. One or more vehicles may be interested in serving a concrete request, making it necessary to introduce distributed processes to decide which vehicle is assigned the disputed request. This creates a somewhat competitive scenario among the fleet vehicles. Each request will have a different “value” to each vehicle, as they have their own utility function. Because of that, requests will generally be assigned to the vehicle which is more interested in it (the one to which the request has more value). We propose the use of best-response dynamics and auction procedures to sort out the request assignments. Both these methods are detailed below, in Section 4.1 and Section 4.2, respectively. The aforementioned techniques are concrete proposals, and they must be understood only as such. There are a variety of processes that could be employed for the task at hand, which would have to be tested to select the most appropriate.

As we mentioned above, we model a partially dynamic system. This means that the travel requests our system accepts are of one of two types: bookings (static) or real-time (dynamic) requests. Figure 1 shows the system’s architecture, which is split into two parts: static and dynamic.

The static part deals with travel bookings; displacement requests which are known before time. The static subsystem can be run every day or every few hours to obtain a route planning for every fleet vehicle, allocating the bookings in a distributed, self-interest guided manner. All fleet vehicles have a maximum number of bookings that can serve during a concrete working period. Such a number is proportional to the duration of the working period. The static subsystem is described in detail in Section 4.

The dynamic subsystem takes care of real-time requests, which arrive while the fleet is already operating. These requests may ask for the fastest possible pickup, in contrast with programmed pickups. The vehicles are filtered to sort out which of them can get a real-time request assigned. Any vehicle which, to include the new request in their route, fails to preserve the time restrictions of its previously accepted requests, will be discarded from the assignment process. Then, the distributed process takes place among the leftover vehicles through an auction. The vehicle that gets the request assigned updates its route planning accordingly to serve it. The dynamic subsystem is described in detail in Section 5.

Finally, we propose the integration of the proposal with a simulator. A simulator would enable the system’s managers to test the system with different configurations of vehicles, vehicle capacity and customer demand. In addition, it can be used to tune the parameters of the different algorithms and find the best combination. Specifically, we would integrate our system with SimFleet [17], a multi-agent-based simulator that counts with a web interface that allows the visualisation of the system in operation.

Following, we detail each part of our proposal, characterising the format of bookings and travel requests and describing the distributed assignment processes that take place among the self-interested vehicles.

4. Static Subsystem

The static part of our system computes an initial route planning for every fleet vehicle to perform during the following working day or period (as it could be run to plan for periods of a concrete number of hours). In order to do so, it receives a set of client bookings, as well as the set of vehicles that will be available during the day.

A booking b is defined in our system as a tuple with the following parameters:

$$b=\{L_{pickup}^b,L_{dest}^b,T_{pickup}^b{,}^b{T}_{dest},T_{thresh}^b\}$$

(1)

• $L_{pickup}^b$: Pickup location where the user issuing the booking will wait to be picked up by a vehicle.
• $L_{dest}^b$: Destination location where the user issuing the booking wants to be dropped off the vehicle.
• $T_{pickup}^b$: Preferred pickup time at which the user expects to start travelling towards its destination.
• $T_{dest}^b$: Preferred arrival time at which the user expects to be dropped off at its destination. The system will indicate a minimum arrival time according to the expected pickup time, trip distance, route and predicted traffic flow. The user is free to delay its preferred arrival time, which would give the system more flexibility to allocate their trip.
• $T_{thresh}^b$: Time threshold indicating the amount of time the user is willing to wait past their preferred pickup time or the delay on their preferred arrival time they could accept. A longer time threshold would give benefits for the user, such as a lower service price. It is crucial to incentivise the duration of this parameter as it offers the vehicles more free time to either better adjust their routes or serve incoming real-time requests.

According to the definition of a booking, the utility that serving a booking b reports to a vehicle v is defined by Equation (2). Let $dist(x,y)$ be a function that returns the distance travelled by road between locations x and y; and $service\_fare(time)$ a function that returns a price value according to the $time$ passed to it. Let $v_{loc}$ be the current location of v; $km\_price$ a fixed price per trip kilometer; $w_{thresh}^v$ a weight that determines the importance of a flexible threshold for v; $L_{pickup}^{b+1}$ the pickup location of the booking $b+1$ that will be served after b.

$$Utility(b,v)=benefits(b,v)-costs(b,v)$$

(2)

The benefits (Equation (3)) that serving booking b reports to a vehicle v are determined by the distance travelled by the user that issued the booking, the time in which the booking time window begins and the time threshold, whose influence is pondered by a weight. A service that begins at a specific time of the working period might be more costly for the customer. Ideally, this would, to some extent, motivate users to spread their trip times uniformly throughout the working period. In addition, the time threshold represents more benefit for the vehicles the longer it lasts, as it gives them more free time to adjust their route or serve real-time requests.

$$\begin{array}{c}\hfill cbenefits(b,v)=dist(L_{pickup}^b,L_{dest}^b)\ast km\_price+\\ \hfill service\_fare(T_{pickup}^b)+T_{thresh}^b\ast w_{thresh}^v\end{array}$$

(3)

As for the costs (Equation (4)), these include the distance travelled while the vehicle is empty and the inverse of the time threshold. With this, trips that start nearby the vehicle and finish nearby another assigned booking will be more attractive. The threshold, in this case, adds fewer costs the longer it lasts.

$$costs(b,v)=dist(v_{loc},L_{pickup}^b)+dist(L_{dest}^b,L_{pickup}^{b+1})+\frac{1}{T_{thresh}^b\ast w_{thresh}^v}$$

(4)

As it can be seen, the functions combine values with different units. For a correct utility computation, those values would be normalised to adjust their magnitudes. In addition, take into consideration that these are equations developed for the current proposal. They could be modified in the future and adjusted to other system configurations.

Once all the information has been loaded, a distributed process begins in which the fleet vehicles, all modelled as self-interested agents, build their routes by choosing to serve one booking at a time, taking turns. As they incrementally build their route planning, the vehicles take into account the time restrictions associated with every booking in order to ensure all clients will be served satisfactorily. Vehicles run a routing algorithm that analyses the inclusion of the next booking they are interested in serving into their current route. A vehicle will be able to choose a booking if its inclusion in their route planning does not delay any of the already selected bookings past their threshold.

Regarding the distributed booking allocation process, we propose two alternatives in which the decision to include or not a booking in their routing plan is driven by the self-interest of each agent. In particular, we discuss a game-theoretic approach named best-response coordination (Section 4.1), in which the vehicles, in turns, select the booking that better fits their routing, also taking into account the routing of every other participant vehicle. This process eventually converges to an equilibrium, an assignment of bookings to vehicles from which no vehicle is incentivised to deviate. On the other hand, we propose an approach based on automated negotiation: the Bertsekas auction algorithm (Section 4.2). This algorithm allows vehicles to bet on the bookings they are most interested in.

Finally, as an extra feature of our system, we enable users to configure periodic bookings. A periodic booking is issued with the same parameters regarding location and daytime, but with a different date. A clear example of a periodic booking would be one which is repeated from Monday to Friday to transport a user from their home to their workplace (or vice versa). Periodic bookings are comfortable for our system and would be encouraged among users, as they provide certainty for the initial route plannings of each vehicle for each working period.

4.1. Best-Response Coordination

The best-response coordination [18,19] is a game-theoretic distributed algorithm which obtains an equilibrium among the strategies of a set of agents. In game theory, an equilibrium is a solution or set of agent actions from which no agent is incentivised to deviate. In other words, every agent has decided on a set of actions that reports them the maximum possible benefit with respect to the actions of every other participant agent. Applying this concept to our DRST system, with an equilibrium we obtain a coordinated global route planning; that is, a route planning containing the individual route plannings of every vehicle. The booking assignment of the global route planning creates no conflict during the vehicles’ operation.

To apply such an algorithm would require the definition of the booking assignment as a multi-agent planning task. Therefore, the route planning that each vehicle intends to perform during its operation would be encoded in an agent plan. An agent plan, in this context, would describe the bookings the vehicle would like to serve, indicating also the route and schedule it would follow. During the best-response process, the agents propose their best plan (the one that reports them more benefits), taking turns. After a whole round, the agents reevaluate the plan they proposed taking into account the plan of every other agent. If the actions of another agent are in conflict with theirs (for instance, because more than one agent is interested in serving the same booking), the agent will propose a different plan which (1) avoids any conflict, and (2) is its current best plan. This process repeats iteratively until no agent has modified its plan after a whole round. This means that each agent is proposing their best plan with respect to every other agent’s best plan. Consequently, as no agent will benefit from switching plans, an equilibrium has been reached. The agents are coordinated, no conflicts will arise from the execution of their plans, and their private interests have been preserved.

This coordination, however, needs vehicle information to be shared among participants. As commented above, agents propose their best plan with respect to other agents’ best plans. This implies that every agent has complete information about every other agents’ intentions. In addition, when a booking conflict arises (more than one vehicle interested in serving the same booking), information such as the location of vehicles is vital to determine who will end up serving the booking, as generally a vehicle closer to it will be able to get there sooner, increasing customer’s satisfaction and reducing wasted time.

4.2. Bertsekas Auction

The Bertsekas’s auction algorithm, presented in [20], is generally used to assign a set of jobs (or persons) to a set of tasks (or objects) such that each job is assigned to only one task and the effectiveness of the assignment is optimised. We adapted the formulation of this distributed algorithm to our problem modelling. Following, we describe the algorithm’s input and its operation.

For our proposal, we have a set of m bookings which must be assigned to one of the n vehicles of the fleet. Each booking $b_i$, $i\in [1,m]$, has a real static cost $price(b_i)$ associated to it. This cost is independent of the vehicle serving the booking and is computed only taking into account the attributes of the booking (distance between pickup and destination, time of pickup and flexibility on the time threshold). In addition, for each vehicle $a_j$, $j\in [1,n]$, each booking has a unique estimated cost $estim(a_j,b_i)$.

The estimated cost of each booking for a particular vehicle is determined by the costs that would imply to serve such a booking if it was assigned to it. Its value depends on many factors such as the vehicle’s location, the number of bookings it has already assigned and the necessary modifications in its route planning to serve the new booking. Because of that, the estimated cost that each request has for every vehicle is unique. This estimated value will determine the vehicle’s willingness to serve a particular booking.

Given the aforementioned input, the algorithm develops in iterations until each booking is assigned to a vehicle. An iteration works as follows: The vehicles compute their own perceived cost for each booking, $cos{t}_{a_j}(b_i)$, by adding the estimated (unique) and real (static) costs:

$$cos{t}_{a_j}(b_i)=estim(a_j,b_i)+price(b_i)$$

(5)

Each vehicle bids on the booking with less cost: $min(cos{t}_{a_j}(b_i))$. The “price” of the bidding is the difference between the cost of the booking with the second lowest cost ($b_{sub}$) and the one with minimum cost ($b_{min}$):

$$bi{d}_{a_j}=cos{t}_{a_j}(b_{sub})-cos{t}_{a_j}(b_{min}).$$

(6)

Each booking that has received at least one bidding is assigned to the highest bidder. Then, the real cost of such a booking is incremented by adding the highest bidding price to it. Let $a_u$ be the vehicle with the highest bid ($bi{d}_{a_u}$) for booking $b_i$ and $pric{e}^{\prime }(b_i)$ be $b_i$’s price for the next iteration:

$$pric{e}^{\prime }(b_i)=price(b_i)+bi{d}_{a_u}$$

(7)

With this price increment, the algorithm makes all other vehicles bidding for booking $b_i$ aware of how interested is $a_u$ in it. If the increment in the real price does not dissuade other vehicles from bidding for $b_i$ in the following iteration, $a_u$ could lose it (get the booking unassigned). At the end of the process, each task will be assigned to the vehicle that can afford to “pay” more for it. In other words, the vehicle that is willing to increase its costs the most to serve the booking’s customer.

Our system will generally receive a higher number of bookings than the number of vehicles in the fleet. Therefore, to assign all of them to the different vehicles, we must run the auction algorithm iteratively. At the end of the first iteration, the vehicles will have one booking assigned to them. Each consecutive iteration, they may be assigned one more booking. As explained in Section 3, the vehicles have a limit in the number of tasks they can be assigned during a specific working period, whether it is the whole working day or a few working hours. Once a vehicle reaches that limit, it will not participate in any following auction. Finally, when every booking has been assigned, the iterative auctions finish. At that time, each vehicle counts with its own individual route planning, which, as every booking is assigned to a single vehicle, will not cause any conflicts during the operation.

5. Dynamic Subsystem

The dynamic side of our system deals with real-time (or online) travel requests. This type of request shares the attributes of a booking (Section 4); although its $T_{pickup}^b$ can be configured as “as soon as possible”. Real-time requests are issued by system users through the application and arrive at a pool of requests that is visible to every vehicle. Once again, the decision to serve a request of the pool is based on each individual vehicle’s self-interest, taking into account the necessary restrictions. The utility that serving a real-time request reports to a vehicle is computed in the same way a booking’s utility (see Equations (2)–(4) in Section 4).

The inclusion of an online request in the route planning of a vehicle implies new scheduling of the already accepted trips. In addition, this rescheduling is performed while the vehicle is most likely already serving one of their bookings. Therefore, such inclusion must not delay any of its already assigned requests or bookings past their threshold. When a new travel request is issued, the first step is to select as potential servers the vehicles that can add it to their route planning while respecting the time restrictions of their other bookings. For this, every vehicle in the fleet calculates a new scheduling that includes the new request. If the scheduling can not be computed, the vehicle will not be able to show interest in serving the request.

The assignment of the new request is done among the vehicles that passed the previous step. The computation of their new schedules gives the vehicles the information that defines how interested they are in serving the request, i.e., the expected benefit obtained from serving it. A distributed process takes place in which the interested vehicles bid for the request to decide who will serve it. The request will be assigned to the auction winner, who will update its schedule to the one it computed before. The time differences among schedules are informed to the corresponding users through the application. Similarly, the user that issued the new request will be informed of their expected pickup time.

Considering that new travel requests may appear at any time, the vehicles adapt their operation to maximise the number of requests they can serve. In this regard, the time between consecutive bookings or requests can be administered by each vehicle according to different waiting strategies [21]. If the Drive first strategy is followed, the vehicle will depart towards its following location immediately after the current request is served. In contrast, the Wait first strategy favours waiting for the longest possible time in the current location as long as the time restrictions of the following requests are preserved. Finally, the Modified dynamic wait consists in waiting at the current location for a concrete time, aiming to arrive at the location of the following request precisely at the beginning of its time window so that the customer is served without waiting. In our system, each vehicle could employ its preferred waiting strategy.

6. Discussion

Throughout this work, we have discussed the many configurations that demand-responsive mobility can have. From all those, our system is modelled with fully flexible routes, on-demand stops, a decentralised fleet of self-interested vehicles, each vehicle having the capacity to carry four to eight passengers, and offering trip reservations as well as real-time travel requests. The service we propose does not differ that much from on-demand transportation services like those of Uber or Cabify. However, from the shareability perspective, our system improves on traditional alternatives, although it can not be compared to public transport services. Regarding sustainability, the type of service we offer has the potential to reduce private vehicle usage in favour of shared vehicles [4]. Such a potential is increased if we consider the vehicles could run on electric power, thus avoiding carbon dioxide emissions during their operation. To draw any concrete conclusions, however, we need to gather specific data about our proposed fleet’s sustainability. We plan on doing this in the future by simulating the system and experimenting with different fleet sizes and vehicle capacities.

In terms of our proposal, the self-interest of the vehicles is defined in their utility function. The utility that serving a certain booking/request returns is equal to the benefit it produces minus the cost it involves. In turn, benefits relate to the distance travelled while the customer is on the vehicle, while costs derive from vehicle maintenance and empty movements, among others. With this modelling, certain requests may be unattractive to every transport of the fleet. Requests whose pickup or destination location are far away from any vehicle may be at risk of reporting more costs than benefits. To tackle this problem, we can follow many strategies.

On the one hand, we could incentivise the vehicles to serve unattractive requests by increasing their benefits. This, however, may involve an increment on the prices the user has to pay to be served, which would potentially negatively impact customer satisfaction. On the other hand, the vehicles might be forced to serve unattractive requests and later compensated. Possible compensations would be an increment on their benefits or, for instance, advantages during the distributed booking/request assignment processes. There is, of course, a third option which consists of enabling the system to reject unassigned requests. If after the assignment processes no vehicle has shown interest in a particular request, the issuing user would be informed, through the application, that the system can not serve them at the moment. This feature is currently implemented in most traditional transportation systems, which negate service if their operative capacity has been reached. This measure may worsen quality of service but reduce, at the same time, operational costs, as seen in [10]. To correctly assess the impact of this measure on our proposed system, however, we need experimentation.

Most of the reviewed literature points out the difficulty to have flexible transportation with a profitable operation. According to many works, the more flexible and responsive a system is, the higher tend to be its operation costs. It can therefore be inferred that in a system with the features we propose achieving economic viability of the service might be challenging. Although the current work is in an early stage, it is interesting to analyse the requirements to implement our proposal in a real setting. In that regard, our system may need some type of public subsidy to have an adequate quality. With that, users would pay lower prices for the services, which would motivate other users to make use of our system instead of a private vehicle or other less sustainable alternatives.

7. Conclusions

In this work, we have explored the particularities of demand-responsive shared transportation systems. Our contribution consists of a proposal for a partially dynamic system whose fleet is implemented by self-interested vehicles. On the one hand, our system can deal with trip reservations through its static subsystem and real-time travel requests through its dynamic part. On the other hand, using a distributed fleet enables private information to be retained and optimises service quality through vehicle competition. With our approach, the need for a central coordination entity that gives orders to the fleet is avoided. Finally, we propose the integration with the SimFleet simulator to set up and execute experiments.

Regarding the specific configuration of our DRST system, we model a fully responsive service with on-demand routes and stops. Nevertheless, we do not limit ourselves to this configuration and are eager to design and test others in the future. For the current work, we chose to focus the discussion on the differences among fully and partially dynamic systems, decentralisation of the fleet and the modelling with self-interested vehicles.

In contrast with the reviewed work, our proposal defines a decentralised operation of the system. In addition, we use self-interested agents to model autonomous vehicles or drivers. The use of self-interested agents supposes a novel approach in transportation modelling, where vehicles are generally assumed to follow orders of a manager entity. With them, we can reproduce an open fleet, a new approach to DRST systems. Our setup gives us the chance to explore the application of distributed techniques, such as the best-response algorithm or the Bertsekas auction algorithm, to coordinate the fleet’s operation. These techniques ensure that vehicles (or drivers) serve transportation requests according to their own interests. Furthermore, we could reproduce a system in which vehicles of different companies compete by serving clients of a single transportation platform. By introducing decentralised self-interested operation, we hope to improve both the vehicle’s benefits and the client’s satisfaction.

The natural future step for this proposal would be an implementation of the infrastructure. Concretely, we plan to: (1) specify the modelling refining the formulas for the costs, benefits and utility of the vehicles. In addition, define system performance indicators regarding economic viability, service quality and sustainability. (2) Implement and test the described system, assessing the use of the proposed distributed algorithms and testing also alternative ones. Finally, (3) overhaul the SimFleet simulator to enable the creation and execution of mobility scenarios to be resolved by our DRST fleet and visualise its operation.