Fleet management for autonomous vehicles: Online PDP under special constraints

The VIPAFLEET project consists in developing models and algorithms for man- aging a fleet of Individual Public Autonomous Vehicles (VIPA). Hereby, we consider a fleet of cars distributed at specified stations in an industrial area to supply internal transportation, where the cars can be used in different modes of circulation (tram mode, elevator mode, taxi mode). One goal is to develop and implement suitable algorithms for each mode in order to satisfy all the requests under an economic point of view by minimizing the total tour length. The innovative idea and challenge of the project is to develop and install a dynamic fleet management system that allows the operator to switch between the different modes within the different periods of the day according to the dynamic transportation demands of the users. We model the underlying online transportation system and propose a correspond- ing fleet management framework, to handle modes, demands and commands. We consider two modes of circulation, tram and elevator mode, propose for each mode appropriate on- line algorithms and evaluate their performance, both in terms of competitive analysis and practical behavior.


Introduction
The project VIPAFLEET aims at contributing to sustainable mobility through the development of innovative urban mobility solutions by means of fleets of Individual Public Autonomous Vehicles (VIPA) allowing passenger transport in closed sites like industrial areas, medical complexes, campuses, business centers, big parkings, airports and train stations. A VIPA is an "autonomous vehicle" that does not require a driver nor an infrastructure to operate, it is developed by Easymile and Ligier [9,10] thanks to innovative computer vision guidance technologies developed by researchers at Institut Pascal [13,14]. This innovative project involves different partners in order to ensure the reliability of the transportation system [11]. A long-term experimentation [14] has been performed on the industrial site "Ladoux" of Michelin at Clermont-Ferrand as part of the FUI VIPAFLEET project. A fleet of VIPAs shall be used in an industrial site to transport employees and visitors e.g. between parkings, buildings and from or to the restaurant at lunch breaks. The fleet is distributed at specified stations to supply internal transportation, and a VIPA can operate in three different transportation modes: -Tram mode: VIPAs continuously run on predefined lines or cycles in a predefined direction and stop at a station if requested to let users enter or leave. -Elevator mode: VIPAs run on predefined lines and react to customer requests by moving to a station to let users enter or leave, thereby changing their driving direction if needed. -Taxi mode: users book their transport requests (from any start to any destination station within the network with a start and an arrival time) in real time.
This leads to a Pickup-and-Delivery Problem (PDP) where a fleet of servers shall transport goods or persons from a certain origin to a certain destination. If persons have to be transported, we usually speak about a Dial-a-Ride Problem (DARP). Many variants are studied including the Dial-a-Ride Problem with time windows [7,8]. In our case, we are confronted with an online situation, where transportation requests are released over time [2,3,6].
In a practical context, different objective functions can be considered. We focus on the economic aspect where the objective is to minimize costs by minimizing the total tour length. In a VIPAFLEET system, users can either call a VIPA directly from a station with the help of a call-box or can book their request in real time by mobile or web applications. Since the customer requests are released over time, the classical PDP does not reflect the real situation of this project. Therefore we are interested in its online version. Our aim is to develop and install a Dynamic Fleet Management System that allows the operator to switch between different network designs, transportation modes and appropriate online algorithms within the different periods of the day in order to react to changing demands evolving during the day, with the objective to satisfy all demands in a best possible way. For that we model the underlying online transportation system and propose an according fleet management framework, to handle modes, demands and commands (see Section 2). In Section 3 we develop suitable online algorithms for tram and elevator mode and analyse them in terms of competitive analysis w.r.t minimizing the total tour length. In Section 4, we provide computational results showing that the practical behavior of the algorithms is much better than their worst case behavior captured by their competitive factors. This enables us to cluster the demands into subproblems in such a way that, for each subproblem, a suitable subnetwork and a suitable algorithm can be proposed leading to a globally good solution (transportation schedule).

Problem description and model
We embed the VIPAFLEET management problem in the framework of a metric task system. We encode the closed site where the VIPAFLEET system is running as a metric space M = (V, d) induced by a connected network G = (V, E), where the nodes correspond to stations, arcs to their physical links in the closed site, and the distance d between two nodes v i , v j ∈ V is the length of a shortest path from v i to v j . In V , we have a distinguished origin v o ∈ V , the depot of the system where all k VIPAs are parked when the system is not running, i.e., outside a certain time horizon [0, T ].
A Dynamic Fleet Management System shall allow the operator to switch between different transportation modes within the different periods of the day in order to react to changing customer demands evolving during the day. For that, for a certain period [t, t ] ⊆ [0, T ], we define a metric subspace M = (V , d ) induced by a subnetwork G = (V , E ) of G, where a subset of nodes and arcs of the network is active (i.e. where the VIPAs have the right to perform a move on this arc or pass by this node during [t, t ]). An operator has to decide when and how to move the VIPAs in the subnetworks, and to assign customer requests to VIPAs.
Any customer request r j is defined as a 4-tuple r j = (t j , x j , y j , z j ) where t j ∈ [0, T ] is the release date, -x j ∈ V is the origin node, -y j ∈ V is the destination node, -z j specifies the number of passengers.
The operator monitors the evolution of the requests and the movement of VIPAs over time and creates tasks to move the VIPAs to go to some station and pick up, transport and deliver users. More precisely, a task can be defined as τ j = (t j , x j , y j , z j , G ). This task is sent at time t j to a VIPA operating in the subnetwork G containing stations x j and y j , indicating that z j passengers have to be picked up at x j and delivered at y j . In order to fulfill the tasks, we let a fleet of VIPAs (one or many, each having a capacity for Cap passengers) circulate in the network inducing the metric space.
More precisely we determine a feasible transportation schedule S for (M, T ) consisting of a collection of tours {Γ 1 , . . . , Γ k } where: each of the k VIPAs has exactly one tour, each request r j is served not earlier than the time t j it is released, each tour starts and ends in the depot.
If each user is transported from its start station to its final destination by only one VIPA, then S is called non-preemptive, otherwise preemptive. In particular, if start and destination station of a user do not lie on the same subnetwork G , the user has to change VIPAs on one or more intermediate stations. As this typically leads to inconveniences, the design of subnetworks has to be done in such a manner that preemption can be mostly avoided.
In addition, depending on the policy of the operator of such a system, different technical side constraints have to be obeyed. If two or many VIPAs circulate on the same (sub)network, the fleet management has to handle e.g. the meeting of two vehicles on a station or an arc, blocking the route of a VIPA by another one waiting at a station (if two VIPAs are not allowed to enter the same node or arc at the same time), and has to take into account the events of breakdown or discharge of a vehicle, technical problems with the server, the data base or the communication network between the stations, VIPAs and the central server.
Our goal is to construct transportation schedules S for the VIPAs respecting all the above constraints w.r.t minimizing the total tour length. This will be addressed by dividing the time horizon [0, T ] in different periods according to the volume and kind of the requests, and by providing specific solutions within each period. The global goal is to provide a feasible transportation schedule over the whole time horizon that satisfies all requests and minimizes the total tour length (Dynamic Fleet Management Problem). For each period, we partition the network G = (V, E) into a set of subnetworks G = (V , E ). The aim of this partition is to solve some technical side constraints for autonomous vehicles, and to solve the online PDP using different algorithms at the same time on different subnetworks. To gain precision in solutions by applying a suitable algorithm to a certain subnetwork, the choice of the design of the network in the industrial site where the VIPAs will operate is dynamic and will change over time according to the technical features and properties.
In a metric space we partition the network into subnetworks G that are either unidirected cycles, called circuits G c , or bidirected paths, called lines G . This partition is motivated by two of the operation modes for VIPAs, tram mode and elevator mode, that we will consider in the sequel of the paper.

Scenarios: combinations of modes and subnetworks
Based on all the above technical features and properties that have an impact on the feasibility of the transportation schedule, we can cluster the requests into subproblems, apply to each subproblem a certain algorithm, and check the results in terms of feasibility and performance.
The choice of the design of the network in the industrial site where the VIPAs will operate is dynamic and will change over time according to the technical features and properties. We consider four typical scenarios that occurred while operating a fleet in an industrial site 1 based on some preliminary studies of the transport requests within the site.
Morning/evening: The transport requests are between parkings and buildings. For this time period we propose the following: • Design a collection of subnetworks (lines and circuits) s.t.
-all buildings and parkings are covered, -each subnetwork contains one parking p and all the buildings where p is the nearest parking (to ensure that for each request, origin (the parking) and destination (a building) lie in the same subnetwork). • Depending on the number of employees in the served buildings, assign one VIPA (in elevator mode) to every line and one or several VIPAs (in tram mode) to each circuit.
Lunch time: The transport requests are between buildings and the restaurant of the industrial complex. For this time period, we propose the following: • Design a collection of lines s.t.
-all buildings are covered, -each line contains the station of the restaurant (to ensure that for each request, to or from the restaurant, origin and destination lie in the same line). • Depending on the number of employees in the served buildings, assign one VIPA (in elevator mode) or one or several VIPAs (in tram mode) to the lines.
Emergency case: In the case of a breakdown of the central servers, the database or the communication system, transports between all possible origin/destination pairs have to be ensured without any decision by the operator. For that we propose to use one Hamilton cycle through all the stations as subnetwork and to let half of the fleet of VIPAs operate in each direction on the cycle (all in tram mode).
Other periods: There are mainly unspecified requests without common origins or common destinations. The operator can use all VIPAs in his fleet in taxi mode on the complete network or design lines and circuits s.t. all stations are covered and the chosen subnetworks intersect (to ensure transports between all possible origin/destination pairs). E.g., this can be done by using one Hamilton cycle through all stations where half of the fleet operates (in tram mode) in each direction, 1 A long-term experimentation [14] has been performed in the industrial site "Ladoux" of Michelin at Clermont-Ferrand where a fleet of VIPAs was operating for several months (October 2014 -February 2015).
a spanning collection of lines and circuits meeting in a central station where one VIPA (in elevator mode) operates on each line, one or several VIPAs (in tram mode) on each circuit.
Remark 1. One of these combinations of subnetworks has been used in a long duration experimentation [14] on the industrial site "Ladoux" of Michelin at Clermont-Ferrand. VIPAs were operating using the tram mode on a unidirected circuit where some of the buildings and parkings of the industrial site were covered.

Online algorithms and competitive analysis
Recall that the customer requests are released over time s.t. the studied PDP has to be considered in its online version. A detailed introduction to online optimization can be found e.g. in the book by Borodin and El-Yaniv [5]. It is standard to evaluate the quality of online algorithms with the help of competitive analysis. This can be viewed as a game between an online algorithm ALG and a malicious adversary who tries to generate a worst-case request sequence σ which maximizes the ratio between the online cost ALG(σ) and the optimal offline cost OP T (σ) knowing the entire request sequence σ in advance. ALG is called c-competitive if ALG produces for any request sequence σ a feasible solution with for some given c ≥ 1. The competitive ratio of ALG is the infimum over all c such that ALG is c-competitive. Here, we are interested in designing and analyzing online algorithms for two possible operating modes of a VIPA, tram mode and elevator mode.

Tram mode
The tram mode is the most restricted operation mode where VIPAs run on predefined circuits in a predefined direction and stop at stations to let users enter or leave. We consider circuits C with one distinguished node, the origin of the circuit 2 .
Optimal offline solution via colorings of interval graphs: An interval graph G(I) is obtained as intersection of a set I of intervals within a line segment, where the nodes of G(I) represent the intervals in I, the edges of G(I) represent their conflicts in terms of overlaps (i.e. two nodes are adjacent if the corresponding intervals have a non-empty intersection).
The clique number w(G(I)) corresponds to the largest number of pairwise intersecting intervals in I, a coloring corresponds to an assignment of colors to intervals such that no two intersecting intervals receive the same color. In all graphs, the clique number is a lower bound on the minimum number X (G(I)) of required colors. For interval graphs it was shown in [12] that the following Greedy coloring algorithm always produces an w(G(I))-coloring of G(I): sort all intervals in I according to their left end points. 2 Circuits can also be lines where one end is the origin and the VIPA can change its direction only in the two ends of the line.
color the nodes of G(I) in this order: starting with the first node, assign to each node the smallest color that none of its already colored neighbors has.
We next interpret the offline solution for VIPAs operating in tram mode on a circuit in this context. We have given a circuit C = {v o , v 1 , . . . , v n } and a sequence σ of m requests r j = (t j , x j , y j , z j ) with origin/destination pairs (x j , y j ) ∈ C × C. W.l.o.g. we may assume that the origin v 0 of the circuit does not lie in the interior of (x j , y j ) for any r j ∈ σ. We transform C into a path P = {v 0 , v 1 , . . . , v n , v 0 } having the origin v 0 of C as start and end node (as the line segment), and we split each request r j into z j many uniform requests (resp. single passengers), interpreted as subpaths (x j , y j ) ⊆ P (to obtain the (multi) set I of intervals). By construction, we have for the resulting interval graph G σ = G(I): the clique number w(G(I)) corresponds to the maximum number of requests r j in σ (counted with their multiplicities z j ) traversing a same edge of P , a coloring of G σ corresponds to an assignment of places in the VIPA(s) to passengers.
Clearly one VIPA can serve all (uniform) requests from up-to Cap color classes in a single subtour traversing C. We can, thus, turn any coloring of G σ into a feasible transportation schedule by waiting until time t m in the origin v 0 ( to ensure that all requests are released before they are served) selecting up to Cap many color classes and assigning the corresponding uniform requests (i.e. single passengers) to one VIPA, to be served within the same subtour traversing C, until all requests are served.
This leads to the following algorithm to compute optimal offline solutions for the tram mode: OPT-TRAM Input: σ = {r 1 , r 2 , . . . , r m }, C = {v o , v 1 , . . . , v n }, Cap and k Output: transportation schedule 1. for each r j = (t j , x j , y j , z j ) ∈ σ: create z j many intervals (x j , y j ) to obtain I, 2. sort all intervals in I according to their left end points, 3. create the interval graph G(I) and apply the Greedy algorithm to color it, 4. wait until t m (the release date of the last request), 5. as long as there are unserved requests: select Cap many (or all remaining) color classes, assign the corresponding passengers to a VIPA and perform one subtour traversing C to serve them.
with origin a and one unit-speed server with capacity Cap = 2 (i.e. a VIPA that travels 1 unit of length in 1 unit of time), and a sequence σ of 6 requests: 1. for each r j ∈ σ we create z j many intervals (x j , y j ) to obtain I: We sort all intervals in I according to their left end points: I 5 , I 2 , I 41 , I 42 , I 6 , I 11 , I 12 , I 3 .
3. We create the interval graph G(I): 4. We apply the Greedy algorithm to color it: 5. As long as there are unserved requests, we select 2 random color classes, assign the corresponding passengers to a VIPA and perform one subtour traversing C to serve them, for instance: first VIPA, first round: color 1 and 2 (r 5 , r 2 , r 41 , r 11 , r 3 ) second VIPA, or second round of first VIPA: color 3 and 4 (r 42 , r 12 , r 6 ) Theorem 1. Algorithm OPT-TRAM provides a load-preemptive optimal offline solution w.r.t. minimizing the total tour length for VIPAs operating in tram mode on a circuit.
Proof. By construction, splitting the requests r j from σ according to their multiplicities z j gives a (multi)set I of intervals where each of them stands for a uniform request of a single passenger. Accordingly, the clique number w(G(I)) of the resulting interval graph G(I) corresponds to the maximum number of passengers traversing a same edge e of the circuit C, that is On the other hand, a coloring of G(I) corresponds to an assignment of places in the VIPA(s) to passengers, and subtours for the VIPA(s) can be easily created by repeatedly choosing Cap color classes and assigning the passengers colored that way to the Cap places of one VIPA. Clearly, at least w(G(I)) Cap many such subtours are needed to serve all requests. The transportation schedule obtained is feasible because, by waiting until t m to start any subtour, we ensure that all requests have been released before. As the Greedy coloring algorithm provides an optimal w(G(I))coloring of G(I), we can guarantee to obtain a feasible transportation schedule performing the minimal number of subtours by always choosing Cap colors (except for the last subtour where we choose all remaining ones) so that the minimal total tour length equals The resulting solution is a load-preemptive transportation schedule because it cannot be ensured that all z j passengers coming from the same request r j are served by the same VIPA (even if z j ≤ Cap holds).

Remark 2.
• The minimal total tour length does not depend on the number of VIPAs used to serve all requests. • Algorithm OPT-TRAM is clearly polynomial because all the steps of the algorithm can be computed in polynomial time. • By not selecting Cap color classes randomly to create subtours, it is possible to: -reduce load-preemption, -minimize the number of stops performed to let passengers leave/enter a VIPA, -handle the case of more than one VIPA, but the so modified algorithm is not necessarily polynomial anymore.
Online algorithms: For the online situation, we propose the following simple algorithm for VIPAs operating in tram mode on a circuit C: each VIPA waits in the origin of C; as soon as a request is released, a VIPA starts a full subtour in a given direction, thereby it stops at a station when a user requests to enter/leave.
In fact, in tram mode, the possible decisions of the VIPA are either to continue its tour or to wait at its current position for newly released requests. This can be used by the adversary to "cheat" an online algorithm, in order to maximize the ratio between the online and the optimal costs. Here, the strategy of the adversary is to force SIR to serve only one uniform request per subtour, whereas the adversary only needs a single subtour traversing C to serve all requests.
Example 2. Consider a circuit C = (v 0 , v 1 , . . . , v n ) with origin v 0 , a unit distance between v i and v i+1 for each i, and one unit-speed server with capacity Cap. The adversary releases a sequence σ of Cap · n uniform requests that force SIR to perform one full round (subtour) of length |C| = n + 1 for each uniform request, whereas the adversary is able to serve all requests in a single subtour (fully loaded on each edge): SIR starts its VIPA at time t = 0 to serve r 1 = (0, v 0 , v 1 , 1) and finishes the first subtour of length |C| without serving any further request. When the VIPA operated by SIR is back to the origin v 0 , the second request r 2 = (|C|, v 0 , v 1 , 1) is released and SIR starts at t = |C| = n + 1 a second subtour of length |C| to serve r 2 , without serving any further request in this subtour. This is repeated for each request yielding SIR(σ) = Cap · |C| · |C|.
The adversary waits at the origin v 1 until t = (Cap−1)|C| and serves all requests r 1 , . . . , r Cap from v 0 to v 1 . Then he waits until t = (2Cap−1)|C| at v 1 and serves all requests r Cap+1 , . . . , r 2Cap from v 1 to v 2 . This is repeated for all Cap requests from v i to v i+1 , yielding OP T (σ) = |C|. The tours performed by SIR and OPT are illustrated in Fig 1. Therefore, we obtain as a lower bound for the competitive ratio of SIR. In the special case of the lunch scenario, we may consider VIPAs operating in tram mode on circuits, where each circuit has the restaurant as its distinguished origin. A sequence σ containing the first Cap and the last Cap requests from the sequence presented in Example 2 shows that 2Cap is a lower bound on the competitive ratio of SIR, see Figure 2 for an illustration. As for the morning resp. evening scenario, we consider VIPAs operating in tram mode on a circuit C where the parking is the distinguished origin of C. A sequence σ containing the first Cap resp. last Cap requests from the sequence presented in Example 2 shows that Cap is a lower bound on the competitive ratio of SIR, see Figure 3 and We can prove that the previously presented examples are indeed worst cases for SIR: Theorem 2. For one or several VIPAs with capacity Cap operating in tram mode on a circuit C with length |C|, SIR is w.r.t the objective of minimizing the total tour length -Cap · |C|-competitive in general, -2 · Cap-competitive during the lunch scenario, -Cap-competitive during the morning scenario resp. the evening.
Proof. Recall that a transportation schedule is based on a coloring of the interval graph G σ , whose nodes stand for passengers from σ, i.e. to the requests r j ∈ σ counted with their multiplicities z j . The worst coloring of G σ is to assign different colors to all nodes, i.e. using |G σ | = rj ∈σ z j many colors. The worst transportation schedule results if, in addition, each VIPA performs a separate subtour of length |C| for each color (i.e. serving a single uniform request only per subtour), yielding |G σ | · |C| as total tour length.
SIR can indeed be forced to show this behavior by releasing the requests accordingly (i.e. by using uniform requests with z j = 1 each and with sufficiently large delay between t j and t j+1 ), in general: using the sequence σ from Example 2, during lunch: using the sequence σ restricted to the first Cap and the last Cap requests (t j , v 0 , v 1 , 1) and (t j , v n , v 0 , 1) from the sequence σ presented in Example 2 as in Figure 2, during morning/evening: using the sequence σ restricted to the first Cap requests (t j , v 0 , v 1 , 1) (resp. the last Cap requests (t j , v n , v 0 , 1)) from the sequence σ presented in Example 2, as Figure 3 (resp. Figure 4) shows.
Furthermore, to maximize the ratio between this total tour length obtained by SIR and the optimal offline solution, we need to ensure that all requests in σ can be served with as few subtours of length |C| as possible. This is clearly the case if all requests have length 1 and there are Cap many requests traversing the same edge of C s.t. a single subtour suffices to serve all of them (see again Example 2). This leads to -|G σ | = |σ| = Cap · |C| and w(G(I)) = Cap s.t.
is the maximum possible ratio between SIR(σ) and OP T (σ) taken over all possible sequences during the morning or evening.
Moreover, SIR can be adapted to follow the strategy of the adversary. For that, we propose two other algorithms for VIPAs operating in tram mode in the morning resp. evening: SIF M ("Start if fully loaded") for the morning scenario each VIPA waits in the parking until Cap passengers have entered, it starts a full round (as soon as it is fully loaded) and stops at stations where passengers request to leave.
SIF E ("Start if fully loaded") for the evening scenario each VIPA waits in the parking until enough requests are released to reach Cap, it starts a full round and stops at stations where passengers request to enter and returns (fully loaded) to the parking.
We can ensure optimality for these two strategies: r.t minimizing the total tour length for one or several VIPAs operating in tram mode on a circuit during the morning (resp. evening).
Proof. Both variants of SIF are optimal, because due to the special request structure during the morning resp. evening, all requests traverse the first (resp. last) edge of P in the morning (resp. evening) s.t. G σ becomes a clique. In other words, no two passengers can share a same place in a VIPA s.t. starting fully loaded from the origin (resp. returning fully loaded to the origin) indeed provides the optimal solution w.r.t. minimizing the total tour length.
The two previous algorithms SIF E and SIF M can be merged together to obtain a version for the lunch scenario:  Proof. Due to the special request structure during the lunch, all requests start and end in the restaurant and, thus, traverse the first and the last edge of P s.t. G σ consists of two cliques Q 1 and Q 2 resulting from all uniform requests traversing the first and the last edge, respectively. The worst transportation schedule of SIF L results if the requests are released in a way that SIF L never serves a request from Q 1 with one from Q 2 together, therefore by each subtour of length |C| performed by SIF L Cap requests are served either from the clique Q 1 or from Q 2 , yielding SIF L (σ) = |Gσ| Cap · |C| as total tour length. In order to maximize the ratio, OPT needs to serve as many requests as possible using the least total tour length possible. OPT always combines Cap requests from Q 1 with Cap requests from Q 2 and serves them together by performing a subtour of length |C|. In addition, to avoid not fully loaded moves for OPT, the adversary choses |Q 1 | = |Q 2 | and as a multiple of Cap which leads to OP T (σ) = |Gσ| 2Cap · |C|, therefore is the maximum possible ratio between SIF L (σ) and OP T (σ) taken over all possible sequences on a circuit of length |C| during the lunch.

Elevator mode
The elevator mode is a less restricted operation mode where one VIPA runs on a predefined line and can change its direction at any station of this line to move towards a requested station. One end of this line is distinguished as origin O (say, the "left" end).
Optimal offline solution: In order to obtain the optimal offline solution OP T (σ) w.r.t. minimizing the total tour length, we compute a min cost flow in a suitable network. Given a line L = (v 0 , . . . , v n ) with origin v 0 as a subnetwork, capacity Cap of a VIPA, and a request sequence σ with requests r j = (t j , x j , y j , z j ).
In the sequel, we distinguish in which direction an edge v i v i+1 of L is traversed and speak of the up arc (v i , v i+1 ) and the down arc (v i+1 , v i ). In order to construct the network, we proceed as follows: • Neglect the release dates t j and only consider the loads of the requests z j , their origins x j and their destinations y j . • Partition the requests into two subsets: -U of "up-requests" r j ∈ σ with x j < y j , -D of "down-requests" r j ∈ σ with x j > y j . • Determine the loads of all up arcs (v i , v i+1 )) or down arcs (v i+1 , v i ) of the line L as a weighted sum of the load of all request-paths (x j , y j ) containing this arc: Cap times. In case the multiplicity m (i,i+1) resp. m (i+1,i) is equal to zero, then the corresponding up resp. down arc is removed.

Now we build a network
Accordingly, the objective function considers costs d(a) = d(u, v) for the flow f on all arcs a = (u, v) in A E , where d(u, v) is the length of a shortest path from u to v in the line L. To correctly initialize the system, we use the source node s as source for the flow and the sink node t as its destination. For all internal nodes, we use normal flow conservation constraints. We require a flow on all up/down arcs f (a) = m(a) for all a ∈ {A U ∪ A D }, see constraint (1e). We finally add the constraint (1d) to eliminate all possible isolated cycles that the flow may contain (since the network contains directed cycles).
This leads to a Min-Cost Flow Problem, whose output is a subset of arcs needed to form a transportation schedule for a metric task system, whose tasks are induced by the requests. The corresponding integer linear program is as follows: where δ − (v, t) denotes the set of outgoing arcs of v, δ + (v) denotes the set of incoming arcs of v and δ(W ) denotes the set of incoming or outgoing arcs (u, v) of W s.t. u ∈ W and v / ∈ W or u / ∈ W and v ∈ W . The time required to compute the integer linear program grows in proportion to 2 |V | due to the constraint (1d) that eliminates all possible isolated cycles, and, hence, it may grow exponentially. However, this integer linear program can be computed in reasonable time provided that the number V of nodes in the original network (the line) is small. Remark 3. The family of constraints (1d) can be generated and then each inequality is separated to verify if it is violated or not. However, due to their exponential number, the process of separation in order to verify if a solution satisfies all constraints is exponential. Since the number of subtour elimination constraints is exponential, we may firstly compute the integer linear program without the constraints (1d). Then we check if there is an isolated cycle in the solution obtained, if yes, we add only the constraint (1d) using the nodes of this isolated cycle. This procedure is repeated until a solution without isolated cycles is found.
Finally, the flow in the time-expanded network is interpreted as a transportation schedule. The tracks of the VIPA over time can be recovered from the flow f (a) on the arcs by standard flow decomposition, see [1]. Hereby, a flow f (a) on an arc a = (u, v) corresponds to a move of a VIPA on this arc. Based on the flow values, one can construct a unique path from source s to sink t traversing all arcs a with positive flow exactly f (a) times. This shows that the optimal solution of system (1) corresponds to a transportation schedule with minimal total tour length for the offline problem behind the elevator mode.
Example 3. Consider a line L = (v 0 , . . . , v n ) with origin v 0 , a unit distance between v i and v i+1 for each i, with a set σ of 9 requests shown in Figure 5, and a VIPA with capacity Cap = 2. The resulting network G E = (V E , A E ) of the line presented in this example is illustrated in Figure 6. The optimal offline solution, the transportation schedule of the VIPA with a minimal total tour length, is obtained by computing the presented integer linear program for a min-cost flow problem in the constructed network Online algorithm: An algorithm MRIN ("Move Right If Necessary") has been proposed for the Online-Traveling Salesman Problem (where no transports have to be performed, but only points to be visited) on a line and analyzed w.r.t. minimizing the makespan [4], giving a competitive ratio of 3/2. We generalize MRIN to the Pickup and Delivery Problem and analyze it w.r.t. minimizing the total tour length. In elevator mode, the server (VIPA) has the choice to continue its tour in the current direction, to wait at its current position or to change its driving direction. Accordingly, we propose the algorithm MAIN. The adversary can again "cheat" the strategy of MAIN as the following example shows.
Example 4. Consider a line L = (v 0 , . . . , v n ) with origin v 0 , a unit distance between v i and v i+1 for each i, and one unit-speed server with capacity Cap. The adversary releases a sequence σ of uniform requests that force MAIN to leave the origin of the line and perform a subtour of a certain distance for each request, whereas the adversary is able to serve all requests in a single subtour of length 2|L|: The first block σ 1 of n · Cap requests: The second block σ 2 of 2 · Cap requests r j = (t j−1 + 2d(v 0 , v n ), v n , v n−1 , 1) for nCap + 1 ≤ j ≤ (n + 1)Cap The third block σ 3 of n · Cap requests: r j = (t j−1 + 2d(v 0 , v n ), v n , v n−1 , 1) for (n + 2 + 1)Cap + 1 ≤ j ≤ (n + 2 + 2)Cap MAIN starts its VIPA at time t = 0 to serve r 1 = (0, v 0 , v 1 , 1) and finishes the first subtour of length 2d(v 0 , v 1 ) = 2 without serving any further request. When the VIPA operated by MAIN is back to the origin v 0 , the second request r 2 = (2, v 0 , v 1 , 1) is released and MAIN starts at t = 2 a second subtour of length 2 to serve r 2 , without serving any further request in this subtour. This is repeated for each request until serving the first block of n · Cap requests yielding Then at t = t nCap+1 MAIN starts to serve r nCap+1 from v n to v n−1 and performs a subtour of length 2d(v 0 , v n ) = 2|L|. When the VIPA operated by MAIN is back to the origin v 0 , the request r nCap+2 is released and MAIN performs a new subtour of length 2|L| to serve it. This is repeated for each request until serving the second block of · 2Cap requests yielding Finally in order to serve the third block MAIN has the same behavior as to serve the first block of requests yielding M AIN (σ 3 ) = 2 · Cap 1≤i≤n i = Cap · |L| · (|L| + 1).
The adversary waits at the origin v 0 until t = t Cap and serves all requests r 1 , . . . , r Cap from v 0 to v 1 . Then he waits until t = t 2Cap at v 1 and serves all requests r Cap+1 , . . . , r 2Cap from v 1 to v 2 . This is repeated for all Cap requests from v i to v i+1 until the adversary arrives to v n . OPT served the first block of n · Cap requests with a total tour length equal to |L|. Then the adversary begins to oscillate his VIPA between v n and v n−1 and serves each time Cap requests, this is repeated 2 times leading to a total tour length for σ 2 equal to 2 . Finally the adversary follows the other direction and waits each time until Cap requests are released to serve them, for all Cap requests from v i to v i−1 until reaching v 0 , yielding OP T (σ) = 2|L| + 2 . Therefore, we obtain M AIN (σ) OP T (σ) = 2 · Cap · |L| · (|L| + 1) + ( · 2 · Cap · 2|L|) 2(|L| + ) = 2 · Cap · |L| · (|L| + 1 + 2 ) 2(|L| + ) as a lower bound for the competitive ratio of MAIN. We can determine an upper bound for the competitive ratio of MAIN close to the ratio obtained by the previous example: Theorem 5. MAIN is 2Cap · |L|-competitive w.r.t minimizing the total tour length for one VIPA operating in elevator mode on a line L with length |L|.
Proof. The worst transportation schedule results if all requests are uniform and the VIPA operated by MAIN performs a separate subtour serving a single request r j = (t j , x j , y j , 1) each time the VIPA leaves the origin v 0 of the line, yielding rj ∈σ 2 max(d(v 0 , x j ), d(v 0 , y j )) as total tour length. To maximize the ratio between the total tour length obtained by MAIN and the optimal offline solution, we need to ensure that we do not have a move with a load less than the capacity Cap of the VIPA in the transportation schedule of OP T ; all requests in σ can be served with as few and as short subtours as possible in OPT.
The worst ratio of subtours can be obtained when -OPT oscillates fully loaded between two neighbored nodes of L, -MAIN is forced to traverse the whole line twice per passenger, i.e. oscillates between v 0 and v n .
For that, v n needs to be either origin or destination of each request, and the delay between the release dates needs to be sufficiently large. This can be achieved with subsequence σ 2 from Example 4, with blocks each consisting of -Cap consecutive uniform requests from v n to v n−1 , alternated by -Cap consecutive uniform requests from v n−1 to v n , always with a delay 2|L| between the release dates of any two requests r j and r j+1 . We obtain OP T (σ 2 ) = 2 and M AIN (σ 2 ) = · 2 · Cap · 2 · |L| which leads to the studied subtour ratio of However, this ratio so far neglects the initial and final server position v 0 for the VIPA operated by OPT. The requirement of starting and ending the tour in v 0 leads to a total tour length for OPT of OP T (σ) = |L| · 2 · |L|.
In order to maximize the ratio of the complete tours, the adversary releases more requests to ensure that the VIPA operated by -OPT can arrive at v n (resp. return from v n to v 0 ) fully loaded on each arc, -MAIN is forced to oscillate between v 0 and the destination y j (resp. the origin x j ) of each uniform request r j .
This can be achieved with the subsequences σ 1 and σ 3 from Example 4 with -Cap consecutive uniform requests from v i to v i+1 for each 0 ≤ i < n and -Cap consecutive uniform requests from v i to v i−1 for each n ≥ i ≥ 1, always with delay 2 · d(v 0 , y j ) resp. 2 · d(x j , v 0 ) between the release dates of any two requests r j and r j+1 within these subsequences. We obtain (as in Example 4) that This finally leads to M AIN (σ) OP T (σ) = 2 · Cap · |L| · (|L| + 1) + ( · 2 · Cap · 2|L|) 2(|L| + ) = 2 · Cap · |L| · (|L| + 1 + 2 ) 2(|L| + ) as the maximum possible ratio between M AIN (σ) and OP T (σ) taken over all possible sequences on a line L.
Concerning the lunch scenario, we may consider VIPAs operating in elevator mode on lines, where each line has the restaurant as its distinguished origin. A sequence σ containing the first Cap requests of the first block σ 1 and the last Cap requests from the third block σ 3 from the sequence presented in Example 4 shows that 2 · Cap is a lower bound on the competitive ratio of MAIN. As for the morning resp. evening scenario, we may consider VIPAs operating in elevator mode on lines, where each line has a parking as its distinguished origin. A sequence σ containing the first Cap requests of the first block σ 1 resp. the last Cap requests from the third block σ 3 from the sequence presented in Example 4 shows that Cap is a lower bound on the competitive ratio of MAIN. We can show that these examples are the worst cases for MAIN during lunch, morning and evening: Theorem 6. For one VIPA with capacity Cap operating in elevator mode on a line, MAIN is w.r.t. the objective of minimizing the total tour length -2 · Cap-competitive during the lunch scenario, -Cap-competitive during the morning resp. the evening scenario.
Proof. The worst transportation schedule results if the VIPA operated by MAIN performs a separate subtour serving a single uniform request r j = (t j , v 0 , v 1 , 1) or r j = (t j , v 1 , v 0 , 1) each time the VIPA leaves the origin v 0 of the line, yielding rj ∈σ 2d(v 0 , v 1 ) as total tour length. MAIN can indeed be forced to show this behavior by releasing the requests accordingly (i.e. by using requests with z j = 1 each and with sufficiently large delay between t j and t j+1 ). In order to maximize the ratio between the total tour length obtained by MAIN and the optimal offline solution, we need to ensure that • we do not have a move from or to the origin with a load less than the capacity Cap of the VIPA in the transportation schedule of OP T . For that, the adversary releases -during the lunch Cap many requests traversing the same arc. Whereas MAIN traverses d(v 0 , v 1 ) twice to serve a request r j = (t j , v 0 , v 1 , 1) or r j = (t j , v 1 , v 0 , 1), OPT travels d(v 0 , v 1 ) once to serve the request and can share it with Cap − 1 others.
-during the morning/evening Cap many requests traversing the same arc. Whereas MAIN traverses d(v 0 , v 1 ) twice to serve a request r j = (t j , v 0 , v 1 , z j ) resp. r j = (t j , v 1 , v 0 , z i ), OPT travels the same distance to serve the request but can share it with Cap − 1 others. • all requests in σ can be served with as few and as short subtours as possible in OPT. For that, the adversary releases -during the lunch a sequence σ of 2Cap requests: Cap many requests v 0 → v 1 followed by Cap many requests v 1 → v 0 . Therefore we obtain is the maximum possible ratio between M AIN (σ) and OP T (σ) taken over all possible sequences on a line during the lunch.
-during the morning/evening a sequence σ of Cap requests: Cap many requests v 0 → v 1 resp. Cap many requests v 1 → v 0 . Therefore we obtain is the maximum possible ratio between M AIN (σ) and OP T (σ) taken over all possible sequences on a line during the morning resp. evening.

Computational results
This section deals with computational experiments for the proposed online algorithms. In fact, due to the very special request structures of the previously presented worst case instances, we can expect a better behavior of the proposed online algorithms in average. The computational results presented in Table 1 and 2 support this expectation, they compare the total tour length T T L computed by the online algorithms with the optimal offline solution. The computations use instances based on the network from the industrial site of Michelin and randomly generated request sequences resembling typical instances that occurred during the experimentation [14].The computations are performed with the help of a simulation tool developed by Yan Zhao [15]. The instances use subnetworks as a circuit or a line depending on the mode and the algorithm with 1 to 5 VIPAs, 5-200 requests, 1-12 as the maximum load z j of a request. For every parameter set we created 6 test instances. In these tables, the instances are grouped by the number of requests and the capacity of the VIPA. The average results of the instances are shown. The operating system for all tests is Linux (CentOS with kernel version 2.6.32). The algorithms SIR, SIF L , MAIN and OPT-TRAM have been implemented in Java. For solving the integer linear program to get the optimal solution for the elevator mode, we use Gurobi 8.21. Table 1. This table shows the computational results for several test instances of the algorithms SIR and SIFL in comparison to the value of the optimal solution. In this table, the instances are grouped by the number of requests (1st column) and the capacity (2nd column). Furthermore the values of the total tour length T T L found by SIR with morning, evening and lunch instances are shown in comparison with the optimal solution OP T and the ratio between them. Then the values of the total tour length T T L found by SIFL with lunch instances are shown in comparison with the optimal solution OP T and the ratio between them. Finally, the results for instances respecting the general scenario are shown: the total tour length T T L found by SIR, the optimal solution OP T and the ratio between them. The competitive ratio c is shown for each of the scenarios, it is always greater than T T L OP T unless c = T T L OP T = 1. In these test instances the length of the circuit used is equal to |C| = 25

Concluding Remarks
Vehicle routing problems integrating constraints on autonomy are new in the field of operational research but are important for the future mobility. Autonomous vehicles, which are intended to be used as a fleet in order to provide a transport service, need to be effective also considering to their management. We summarize the results of competitive analysis presented in this paper in Table 3. Competitive analysis has been one of the main tools for deriving worst-case bounds on Table 2. This table shows the computational results for several test instances of the algorithm M AIN in comparison to the value of the optimal solution. In this table, the instances are grouped by number of requests (1st column) and the capacity (2nd column). First the values of the total tour length T T L found by M AIN for the instances respecting the morning scenario are shown, the optimal solution OP T and the ratio between them. Then the results for instances respecting the evening scenario are shown: the total tour length T T L found by M AIN and, the optimal solution OP T and the ratio between them. Finally, the values of the total tour length T T L found by MAIN with general instances are shown in comparison with the optimal solution OP T and the ratio between them. The competitive ratio c is shown for each of the scenarios, it is always greater than T T L OP T unless c = T T L OP T = 1. In these test instances the length of the line used is equal to |L| = 32  Table 3. This table shows the competitive ratios obtained in this paper. For each case we show the competitive ratio for the algorithm on which type of graphs, using which mode. Cap Cap the performance of algorithms but an online algorithm having the best competitive ratio in theory may reach the worst case more frequently in practice with a certain topology. That is the reason why we are not only interested in the "worst-case" but also in the "best-case" performance of the algorithms, thus we need to determine properties which govern the behavior of each chosen algorithm and define the cases where it can be applied and give the best results in terms of performance. So far, we can suggest the following: -Morning/evening: partition the network into disjoint circuits as subnetworks such that each subnetwork contains one parking p, assign one or several VIPA to every circuit operating in tram mode using SIF M resp. SIF L . The future works are to analyze the proposed scenarios and algorithms further, e.g., by providing competitive ratios w.r.t. the objective of minimizing the makespan, studying also the quality of service aspect by minimizing the waiting time for customers, providing solution approaches for the taxi mode.