A Computing y(r) and v(r) under \mathcal{R}^{q+}

The Static and Stochastic VRPTW with both random Customers and Reveal Times: algorithms and recourse strategies


Unlike its deterministic counterpart, static and stochastic vehicle routing problems (SS-VRP) aim at modeling and solving real-life operational problems by considering uncertainty on data. We consider the SS-VRPTW-CR introduced in Saint-Guillain et al. (2017). Like the SS-VRP introduced by Bertsimas (1992), we search for optimal first stage routes for a fleet of vehicles to handle a set of stochastic customer demands, i.e., demands are uncertain and we only know their probabilities. In addition to capacity constraints, customer demands are also constrained by time windows. Unlike all SS-VRP variants, the SS-VRPTW-CR does not make any assumption on the time at which a stochastic demand is revealed, i.e., the reveal time is stochastic as well. To handle this new problem, we introduce waiting locations: Each vehicle is assigned a sequence of waiting locations from which it may serve some associated demands, and the objective is to minimize the expected number of demands that cannot be satisfied in time. In this paper, we propose two new recourse strategies for the SS-VRPTW-CR, together with their closed-form expressions for efficiently computing their expectations: The first one allows us to take vehicle capacities into account; The second one allows us to optimize routes by avoiding some useless trips. We propose two algorithms for searching for routes with optimal expected costs: The first one is an extended branch-and-cut algorithm, based on a stochastic integer formulation, and the second one is a local search based heuristic method. We also introduce a new public benchmark for the SS-VRPTW-CR, based on real-world data coming from the city of Lyon. We evaluate our two algorithms on this benchmark and empirically demonstrate the expected superiority of the SS-VRPTW-CR anticipative actions over a basic “wait-and-serve” policy.

stochastic vehicle routing, on-demand transportation, optimization under uncertainty, recourse strategies, operations research

1 Introduction

The Vehicle Routing Problem (VRP) aims at modeling and solving a real-life common operational problem, in which a set of customers must be visited using a fleet of vehicles. Each customer comes with a certain demand. In the VRP with Time Windows (VRPTW), each customer must be visited within a given time window. A feasible solution of the VRPTW is a set of vehicle routes, such that every customer is visited exactly once during its time window and that sum of the demands along each route does not exceed the corresponding vehicle’s capacity. The objective is then to find an optimal feasible solution, where optimality is usually defined in terms of travel distances.

The classical deterministic VRP(TW) assumes that all input data are known with certainty before the computation of the solution. However, in real-world applications some input data may be uncertain when computing a solution. For instance, only a subset of the customer demands may be known before online execution. Missing demands hence arrive in a dynamic fashion, while vehicles are on their route. In such a context, a solution should contain operational decisions that deal with current known demands, but should also anticipate potential unknown demands. Albeit uncertainty may be considered for various input data of the VRP (e.g., travel times), we focus on situations where the customer data are unknown a priori, and we assume that we have some probabilistic knowledge on missing data (e.g., probability distributions computed from historical data). This probabilistic knowledge is used to compute a first-stage solution which is adapted online when random variables are realized.

Two different kinds of adaptations may be considered: Dynamic and Stochastic VRP(TW) (DS-VRP(TW)) and Static and Stochastic VRP(TW) (SS-VRP(TW)). In the DS-VRP(TW), the solution is re-optimized at each time-step, and this re-optimization involves solving an -hard problem. Therefore, it is usually approximated with meta-heuristics as proposed, for example, in Ichoua et al. (2006); Bent and Van Hentenryck (2007); Saint-Guillain et al. (2015).

In the SS-VRP(TW), no expensive reoptimization is allowed during online execution. When unknown information is revealed, the first stage solution is adapted online by applying a predefined recourse strategy whose time complexity is polynomial. In this case, the goal is to find a first stage solution that minimizes its total cost plus the expected extra cost caused by the recourse strategy. For example, in Bertsimas (1992), the first stage solution is a set of vehicle tours which is computed offline with respect to probability distributions of customer demands. Real customer demands are revealed online, and two different recourse strategies are proposed, as illustrated in Fig. 1: In the first one (strategy a), each demand is assumed to be known when the vehicle arrives at the customer place, and if it is larger than or equal to the remaining capacity of the vehicle, then the first stage solution is adapted by adding a round trip to the depot to unload the vehicle; In the second recourse strategy (strategy b), each demand is assumed to be known when leaving the previous customer and the recourse strategy is refined to skip customers with null demands. More recently, a preventive restocking strategy for the SS-VRP with random demands has been proposed by Yang et al. (2000). Biesinger et al. (2016) later introduced a variant for the Generalized SS-VRP with random demands.

Figure 1: Two examples of recourse strategies taken from Bertsimas (1992), designed for the SS-VRP with stochastic customers and demands. The vehicle has a capacity of 3. Based on stochastic information, the first stage solution (left) states the a priori sequence of customer visits. When applying strategy a to adapt this solution (middle), we add a return to the depot D between customers c and d to unload the vehicle. When applying strategy b (right), we also skip customers a, d and f as their demands are null.

In recent review Gendreau et al. (2016), the authors argue for new recourse strategies: With the increasing use of ICT, customer demand (and by extension presence) information is likely to be revealed on a very frequent basis. In this context, the chronological order in which this information is transmitted no longer matches the planned sequences of customers on the vehicle routes. In particular, the authors consider as paradoxical the fact that the existing literature on SS-VRPs with random Customers (SS-VRP-C) assumes full knowledge on the presence of customers at the beginning of the operational period.

In this paper, we focus on the SS-VRPTW with both random Customers and Reveal times (SS-VRPTW-CR) recently introduced in Saint-Guillain et al. (2017). The SS-VRPTW-CR does not make strong assumptions on the moment at which customer requests are revealed during the operations, contrary to most existing work that assume that customer requests are known either when arriving at the customer place, or when leaving the previous customer. To handle uncertainty on reveal times, waiting locations are introduced when computing first-stage solutions: The routes computed offline visit waiting locations and a waiting time is associated with each waiting location. When a customer request is revealed, it is either accepted (if it is possible to serve it) or rejected. The recourse strategy then adapts routes in such a way that all accepted requests are guaranteed to eventually be served. The goal is to compute the first-stage solution that minimizes the expected number of rejected requests.

An example of practical application of the SS-VRPTW-CR is an on-demand health care service for elderly or disabled people. Health care services are provided directly at home by mobile medical units. Every registered person may request a health care support at any moment of the day with the guarantee to be satisfied within a given time window. From historical data, we know the probability that a request appears for each customer and each time unit. Given this stochastic knowledge, we compute a first-stage solution. When a request appears (online), the recourse strategy is used to decide whether the request is accepted or rejected and to adapt medical unit routes. When a request is rejected, the system must rely on an external service provider in order to satisfy it. Therefore, the goal is to minimize the expected number of rejected requests.

Contributions Up to our knowledge, previous static and stochastic VRP’s studies all assume that requests are revealed at the beginning of the day, and all fail at capturing the following property: Besides the stochasticity on request presence, the moment at which a request is received is stochastic as well. The SS-VRPTW-CR recently introduced in Saint-Guillain et al. (2017) is the first one that actually captures this property. However, the recourse strategy proposed in this paper does not take capacity constraints into account. Hence, a first contribution is to introduce a new recourse strategy that handles these constraints. We also introduce an improved recourse strategy that optimizes routes by skipping some useless parts. We introduce closed-form expressions to efficiently compute expected costs for these two new recourse strategies. We also propose a stochastic integer programming formulation and an extended branch-and-cut algorithm for these recourse strategies.

Another contribution is to introduce a new public benchmark for the SS-VRPTW-CR, based on real-word data coming from the city of Lyon. By comparing with a basic (yet realistic) wait-and-serve policy which does not exploit stochastic knowledge, computational experiments on this benchmark show that the models we propose behave better in average. While the exact algorithm fails at scaling to realistic problem sizes, we show that the heuristic local search approach proposed in Saint-Guillain et al. (2017) not only gives near-optimal solutions on small instances, but also leads to promising results on bigger ones. Improved variants of the heuristic method are then described and their efficiency demonstrated on the bigger instances. Experiments indicate that using a SS-VRPTW-CR model is particularly beneficial as the number of vehicles increases and when the time windows impose a high level of responsiveness. Eventually, all the experiments show that allowing the vehicles to wait directly at potential customer locations lead to better expected results than using separated relocation vertices.

Organization In section 2, we review the existing studies on VRPs that imply stochastic customers, and clearly position the SS-VRPTW-CR with respect to them. Section 3 formally defines the general SS-VRPTW-CR. Section 4 describes the recourse strategy already introduced in Saint-Guillain et al. (2017), which applies when there is no constraint on the vehicle capacities. Sections 5 and 6 introduce two new recourse strategies to deal with limited vehicle capacities and more clever vehicle operations. Section 7 introduces a stochastic integer programming formulation and a branch-and-cut based solving method for solving the problem to optimality. Section 8 describes the heuristic algorithm of Saint-Guillain et al. (2017) to efficiently find solutions of good quality. Experimental results are analyzed in section 9. Further research directions are finally discussed in section 10.

2 Related work

By definition, the SS-VRPTW-CR is a static problem. In this section we hence do not consider dynamic VRPs and rather focus on existing studies that have been carried on static and stochastic VRPs. Specific literature reviews on the SS-VRP may be found in Gendreau et al. (1996b), Bertsimas and Simchi-Levi (1996), Cordeau et al. (2007), Campbell and Thomas (2008a) and recently in Toth and Vigo (2014), Berhan et al. (2014), Kovacs et al. (2014) and Gendreau et al. (2016). According to Pillac et al. (2013), the most studied cases in SS-VRPs are:

  • Stochastic customers (SS-VRP-C), where customer presences are described by random variables;

  • Stochastic demands (SS-VRP-D), where all customers are present but their demands are random variables (see for instance Dror et al. (1989, 1993), Laporte et al. (2002), Morales (2006), Christiansen and Lysgaard (2007), Mendoza et al. (2010, 2011), Secomandi (2000, 2009) and Gauvin et al. (2014));

  • Stochastic times (SS-VRP-T), where either travel and/or service times are random variables (see for instance Laporte et al. (1992), Kenyon and Morton (2003), Verweij et al. (2003) and Li et al. (2010)).

Since the SS-VRPTW-CR belongs to the first category, we focus this review on customers uncertainty only.

The Traveling Salesman Problem (TSP) is a special case of the VRP with only one uncapacitated vehicle. The first study on static and stochastic vehicle routing is due to Bartholdi III et al. (1983), who considered a priori solutions to daily food delivery. Jaillet (1985) formally introduced the TSP with stochastic Customers (SS-TSP-C), a.k.a. the probabilistic TSP (PTSP) or TSPSC in the literature, and provided mathematical formulations and a number of properties and bounds of the problem (see also Jaillet, 1988). In particular, he showed that an optimal solution for the deterministic problem may be arbitrarily bad in case of uncertainty. Laporte et al. (1994) developed the first exact solution method for the SS-TSP-C, using the integer L-shaped method for two-stage stochastic programs proposed in Laporte and Louveaux (1993) to solve instances up to 50 customers. Heuristics for the SS-TSP-C have then been proposed by Jezequel (1985), Rossi and Gavioli (1987), Bertsimas (1988), Bertsimas and Howell (1993), Bertsimas et al. (1995), Bianchi et al. (2005) and Bianchi and Campbell (2007) as well as meta-heuristics such as simulated annealing (Bowler et al. (2003)) or ant colony optimization (bianchi2002aco, 2002). Braun and Buhmann (2002) proposed a method based on learning theory to approximate SS-TSP-C. A Pickup and Delivery Traveling Salesman Problem with stochastic Customers is considered in Beraldi et al. (2005), as an extension of the SS-TSP-C in which each pickup and delivery request materializes with a given probability.

Particularly close to the SS-VRPTW-CR is the SS-TSP-C with Deadlines introduced by Campbell and Thomas (2008b). Unlike the SS-VRPTW-CR, authors assume that customer presences are not revealed at some random moment during the operations, but all at once at the beginning of the day. However, Campbell and Thomas showed that deadlines are particularly challenging when considered in a stochastic context, and proposed two recourse strategies to address deadline violations. Weyland et al. (2013) later proposed heuristics for the later problem based on general-purpose computing on graphics processing units. A recent literature review on the SS-TSP-C may be found in Henchiri et al. (2014).

The first SS-VRP-C has been studied by Jezequel (1985), Jaillet (1987) and Jaillet and Odoni (1988) as a generalization of the SS-TSP-C. Waters (1989) considered general integer demands and compared different heuristics. Bertsimas (1992) considered a VRP with stochastic Customers and Demands (SS-VRP-CD). A customer demand is assumed to be revealed either when the vehicle leaves the previous customer or when it arrives at the customer’s own location. Two different recourse strategies are proposed, as illustrated in Figure 1. For both strategies, closed-form mathematical expressions are provided to compute the expected total distance, provided a first stage solution. Gendreau et al. (1995) and Séguin (1994) developed the first exact algorithm for solving the SS-VRP-CD for instances up to 70 customers, by means of an integer L-shaped method. Gendreau et al. (1996a) later proposed a tabu search to efficiently approximate the solution. Experimentations are reported on instances with up to 46 customers. Gounaris et al. (2014) later developed an adaptive memory programming metaheuristic for the SS-VRP-C and assessed it on benchmarks with up to 483 customers and 38 vehicles.

Sungur and Ren (2010) considered a variant of the SS-VRPTW-C, i.e., the Courier Delivery Problem with Uncertainty. Potential customers have deterministic soft time windows but are present probabilistically, with uncertain service times. Vehicles are uncapacitated and share a common hard deadline for returning to the depot. The objective is to construct an a priori solution, to be used every day as a basis for adapting to daily customer requests. Unlike the SS-VRPTW-CR, the set of customers is revealed at the beginning of the operations.

Heilporn et al. (2011) introduced the Dial-a-Ride Problem (DARP) with stochastic customer delays. The DARP is a generalization of the VRPTW that distinguishes between pickup and delivery locations and involves customer ride time constraints. Each customer is present at its pickup location with a stochastic delay. A customer is then skipped if it is absent when the vehicle visits the corresponding location, involving the cost of fulfilling the request by an alternative service (e.g., a taxi). In a sense, stochastic delays imply that each request is revealed at some uncertain time during the planning horizon. That study is thus related to our problem, although in the SS-VRPTW-CR only a subset of the requests are actually revealed. Similarly, Ho and Haugland (2011) studied a probabilistic DARP where a priori routes are modified by removing absent customers at the beginning of the day, and proposed local search based heuristics.

3 Problem description: the SS-VRPTW-CR

In this section, we recall the description of the SS-VRPTW-CR initially introduced in Saint-Guillain et al. (2017).

Input data.

We consider a complete directed graph and a discrete time horizon , where interval denotes the set of all integer values such that . To every arc is associated a travel time (or distance) . The set of vertices is composed of a depot , a set of waiting locations and a set of customer locations . We note and . The fleet is composed of vehicles of maximum capacity .

We consider the set of potential requests such that an element represents a potential request revealed at time for customer location . To each potential request is associated a deterministic demand , a deterministic service duration and deterministic time window with . We note the probability that appears on vertex at time , and assume independence between request probabilities.

To simplify notations, a request may be written in place of its own location . For instance, the distance may also be written . Furthermore, we use to denote the reveal time of a request and for its customer location. The main notations are summarized in Table 1.

Complete directed graph Potential req. associated
Set of vertices (depot is ) to time and loc.
Waiting vertices Reveal time of request
Customer locations Cust. loc. hosting req.
Travel time of arc Service time of request
Number of vehicles Time window of request
Vehicle capacity Demand of request
Discrete time horizon Prob. associated with req.
Set of potential requests
Table 1: Notation summary: graph and potential requests.

First stage solution.

The first-stage solution is computed offline, before the beginning of the time horizon. It consists in a set of vehicle routes visiting a subset of the waiting vertices, together with time variables denoted indicating how long a vehicle should wait on each vertex. More specifically, we denote a first stage solution to the SS-VRPTW-CR, where:

  • defines a set of sequences of waiting vertices of . Each sequence is such that starts and ends with , i.e., , and each vertex of occurs at most once in . We note the set of waiting vertices visited in .

  • associates a waiting time to every waiting vertex .

  • for each sequence , the vehicle is back to the depot before the end of the time horizon, i.e.,

In other words, defines a Team Orienteering Problem (TOP, see Chao et al. (1996)) to which each visited location is assigned a waiting time by .

Given a first stage solution , we define for each vertex such that (resp. ) is the arrival (resp. departure) time on . In a sequence in , we then have and for and assume . Figure 2 (left) illustrates an example of first stage solution on a basic SS-VRPTW-CR instance.

Recourse strategy and second stage solution.

A recourse strategy states how a second stage solution is gradually constructed as requests are dynamically revealed. In this paragraph, we define the properties of a recourse strategy. Three recourse strategies are given in Sections 4, 5 and 6.

Let be the set of requests that reveal to appear by the end of the horizon . The set is also called a scenario. We note the set of requests appearing at time , i.e., . We note the set of requests appeared up to time .

A second stage solution is incrementally constructed at each time unit by following the skeleton provided by the first stage solution . At a given time of the horizon, we note the current state of the second stage solution:

  • defines a set of vertex sequences describing the route operations performed up to time . Unlike , we define on a graph that also includes the customer locations. Sequences of must satisfy the time window and capacity constraints imposed by the VRPTW.

  • is the set of accepted requests up to time . Requests of that do not belong to are said to be rejected.

We distinguish between requests that are accepted and those that are both accepted and satisfied. Up to a time , an accepted request is said to be satisfied if it is visited in by a vehicle. Accepted requests that are no yet satisfied must be guaranteed to be eventually satisfied according to their time window.

Figure 2 (right) illustrates an example of second stage solution being partially constructed at some moment of the time horizon.

Figure 2: On the left: Example of first stage solution with vehicles. The depot, waiting vertices and customer locations are represented by a square, circles and crosses, respectively. Arrows represent the three vehicle routes: , and . Integers at waiting locations indicate waiting times defined by . Waiting vertices , and are not part of the first stage solution and . For vehicle 1, we have , , , , , etc.
On the right: Example of partial second stage solution (plain arrows). Filled crosses are accepted requests. Some accepted requests, such as , have been satisfied (or the vehicle is currently traveling towards the location, e.g., ), while some others are not yet satisfied (e.g., ).

Before starting the operations (at time ), is a set of sequences that only contain vertex , and . At each time unit , given a first stage solution , a previous state of the second stage solution and a set of requests appearing at time , the new state is obtained by applying a specific recourse strategy :


A necessary property of a recourse strategy is to avoid reoptimization. We consider that avoids reoptimization if the computation of is achieved in polynomial time.

We note the final cost of a second stage solution with respect to a scenario , given a first stage solution and under a recourse strategy . This cost is the number of requests that are rejected at the end of the time horizon.

Optimal first stage solution.

Given strategy , an optimal first stage solution to the SS-VRPTW-CR minimizes the expected cost of the second stage solution:


The objective function , which is nonlinear in general, is the expected number of rejected requests, i.e., requests that fail to be visited under recourse strategy and first stage solution :


where defines the probability of scenario . Since we assume independence between requests, we have .

4 Recourse strategy with infinite capacity:

In this section, we recall the recourse strategy introduced in Saint-Guillain et al. (2017) and denoted . It considers the case where vehicles are not constrained by the capacity. In other words, it assumes . We first describe the recourse strategy , and then describe the closed form expression that allows us to compute the expected cost of the second stage solution obtained when applying this recourse strategy to a first stage solution.

4.1 Description of

In order to avoid reoptimization, each potential request is assigned to exactly one waiting vertex (and hence, one vehicle) in . Informally, the recourse strategy accepts a request revealed at time if it is possible for the vehicle associated to its corresponding waiting vertex location to adapt its first stage tour to visit the customer, given the set of requests that have been already accepted. The vehicle will then travel from the waiting location to the customer and return to the waiting location. Time window constraints should be respected, and the already accepted requests should not be perturbed.

Request ordering.

In order to avoid reoptimization, the set of potential requests must be ordered. This ordering is defined before computing first-stage solutions. Different orders may be considered, without loss of generality, provided that the order is total, strict, and consistent with the reveal time order, i.e., , if the reveal time of is smaller than the reveal time of (), then must be smaller than in the request order.

In this paper, we order by increasing reveal time first, end of time window second and lexicographic order to break further ties. More precisely, we consider the order such that , iff or ( and ) or (, and is smaller than according to the lexicographic order defined over ).

Request assignment according to a first stage solution.

Given a first-stage solution , we assign each request of either to a waiting vertex visited in , or to to denote that is not assigned. We note this assignment. It is computed for each first stage solution before the application of the recourse strategy. To compute this assignment, we first compute for each request the set of waiting locations which are feasible for :

where and are defined as follows:

  • is the earliest time for leaving waiting location to satisfy request . Indeed, a vehicle cannot handle before (1) the vehicle is on , (2) is revealed, and (3) the beginning of the time window minus the time needed to go from to .

  • is the latest time at which a vehicle can handle (which also involves a service time ) from waiting location and still leave it in time .

Given the set of feasible waiting locations for , we define the waiting location associated with as follows:

  • If , then ( is always rejected as it has no feasible waiting vertex);

  • If there is only one feasible vertex, i.e., , then ;

  • If there are several feasible vertices, i.e., , then is set to the feasible vertex of that has the least number of requests already assigned to it (break further ties w.r.t. vertex number). This heuristic rule aims at evenly distributing potential requests upon waiting vertices.

Once finished, the request assignment ends up with a partition of , where is the set of requests assigned to the waiting vertices visited by vehicle and is the set of unassigned requests (such that ). We note the set of requests assigned to a waiting vertex . We note and the first request of and , respectively, according to order . For each request such that we note the request of that immediately precedes according to order .

Table 2 summarizes the main notations introduced in this section. Remember that they are all specific to a first stage solution :

Waiting vertex of to which is assigned (or if is not assigned)
Potential requests assigned to vehicle , i.e.     
Potential requests assigned to wait. loc. ,     
Smallest request of according to .
Smallest request of according to .
Request of which immediately precedes according to , if any
Minimum time from which a vehicle can handle request from
Maximum time from which a vehicle can handle request from
Table 2: Notations summary: material for recourse strategies.

Using to adapt a first stage solution at a current time .

At each time step , the recourse strategy is applied to compute the second stage solution , given the first stage solution , the second stage solution at the end of time , and the incoming requests . Recall that is likely to contain some requests that have been accepted but are not yet satisfied.

Availability time Besides vehicle operations, a key point of the recourse strategy is to decide, for each request that reveals to appear at time , whether it is accepted or not. Let be the vehicle associated with , i.e., . The decision to accept or not depends on the time at which will be available to serve . By available, we mean that it has finished to serve all its accepted requests that precede (according to ), and it has reached waiting vertex . This time is denoted . It is defined only when we know all accepted requests that are assigned to and that must be served before . As the requests assigned to are ordered by increasing reveal time, we know for sure all these accepted requests when . In this case, is recursively defined by:

Request notifications is the set of appeared requests accepted up to time . It is initialized with as all requests previously accepted must still be accepted at time . Then, each incoming request is considered, taken by increasing order with respect to . is either accepted (added to ) or rejected (not added to ) by applying the following decision rule:

  • If or then is rejected;

  • Else is accepted and added to ;

Vehicle operations Once has been computed, vehicle operations for time unit must be decided. Vehicles operate independently to each other. If vehicle is traveling between a waiting location and a customer location, or if it is serving a request, then its operation remains unchanged; Otherwise, let be the current waiting location (or the depot) of vehicle :

  • If , the operation for is “travel from to the next waiting vertex (or the depot), as defined in the first stage solution”;

  • Otherwise, let be the set of requests of that are not yet satisfied and that are either accepted or with unknown revelation.

    • If , then the operation for is “travel from to the next waiting vertex (or the depot), as defined in the first stage solution”;

    • Otherwise, let be the smallest element of according to

      • If , then the operation for is “wait until ″;

      • Otherwise, the operation is “travel to , serve it and come back to ″.

Figure 3 shows an example of second stage solution at a current time , from an operational point of view.

Figure 3: Example of second stage solution at time , under strategy . A filled cross represents a request that appeared, an empty one a request that is either still unknown (e.g., ) or revealed as being absent (i.e., did not appear, e.g., ). Here is the sequence of requests assigned to the vehicle, according to . We assume . represents, for a request , the time at which gets satisfied.

4.2 Expected cost of second stage solutions under

Provided a recourse strategy and a first stage solution to the SS-VRPTW-CR, a naive approach for computing would be to literally follow equation (4), therefore using the strategy described by in order to confront to each and every possible scenario . Because there is an exponential number of scenarios with respect to , this naive approach is not affordable in practice. In this section, we show how the expected number of rejected requests under the recourse strategy may be computed in using closed form expressions.

Let us recall that we assume that the potential request probabilities are independent from each other such that, for any couple of requests , the probability that both requests appear is given by .

is equal to the expected number of rejected requests, which in turn is equal to the expected number of requests that reveal to appear minus the expected number of accepted requests. The expected number of revealed requests is given by the sum of all request probabilities, whereas the expected number of accepted requests is equal to the sum, for every request , of the probability that it belongs to , i.e.,


where the right-hand side of the equation comes from the independence hypothesis.

Given a request , the probability depends on (1) whether reveals to appear or not, and (2) the time at which vehicle leaves to satisfy if condition (1) is satisfied. It may be computed by considering all time units for which vehicle can leave to satisfy request :


Computation of probability is the probability that has been revealed and vehicle leaves at time to serve . Let us note the time at which vehicle actually leaves the waiting vertex in order to serve (the vehicle may have to wait if is smaller than the earliest time for leaving to serve ). The probability is defined by:

This probability is computed only when . In this case, the reveal time of is passed (i.e., ).

Since depends on previous operations on waiting location , we compute recursively starting from the first request assigned to , up to the last request assigned to . The second stage solution strictly respects the first stage schedule when visiting the waiting vertices, that is, vehicle first reaches at time and last leaves it at time .

The base case to compute is:


Indeed, if the first request assigned to a waiting vertex appears then it is necessarily accepted and vehicle leaves to serve either at time , or at time if the time window for serving begins after .

The general case of a request which is not the first request assigned to (i.e., ) depends on the time at which vehicle becomes available for . Whereas is deterministic when we know the set of previously accepted requests, it is not anymore in the context of the computation of probability . We are thus interested in its probability distribution . The computation of is detailed below. Given , the general case to compute is:


Indeed, if , then vehicle leaves to serve as soon as it becomes available. If , the probability that vehicle leaves at time is null since is the earliest time for serving from location . Finally, at time , we must consider the possibility that vehicle was waiting for serving since an earlier time . In this case, the probability that vehicle leaves for serving at time is times the probability that vehicle was actually available from a time .

Computation of probability Let us now define how to compute which is the probability that vehicle becomes available for at time , i.e.,

is computed only when is not the first request assigned to , according to the order , and its computation depends on what happened to the previous request . We have to consider three cases: (1) appeared and got satisfied, (2) appeared but wasn’t satisfiable, and (3) didn’t appear.

For conciseness let us denote by the amount of time needed to travel from to , serve and travel back to . Let also return iff request is satisfiable from time and vertex , i.e., if , and otherwise. Then:


where is the probability that did not appear and is discarded at time (the computation of is detailed below). The first term in the summation of the right hand side of equation (9) gives the probability that request actually appeared and got satisfied (case 1). In such a case, must be the current time , minus delay needed for serving . The second and third terms of equation (9) add the probability that the vehicle was available time , but that request did not consume any operational time. There are only two possible reasons for that: either actually appeared but was not satisfiable (case 2, corresponding to the second term), or did not appear at all (case 3, corresponding to the third term). Figure 4 shows how the -probabilities of a request depend on those of .

Figure 4: Cell dependencies in a -matrix, assuming , , and . Cell a represents , whereas cell c8 represents . Since and at cell a, depends directly and exclusively on cells c8 for its first term of eq. (9), and c11 for the second and third ones. Since cell b has and , it does not depend on another cell as its probability must be zero. Cell c has and , so the first term of eq. (9) is zero and the second and third depend on probabilities at cells c1 to c4. Cell d has , so it only depends on cell c7. Finally, since cell e has first term of eq. (9) depends on cells c1 to c6, whereas makes second and third terms depend on cell c9 only.

Computation of probability Let us finally define how to compute , which is the probability that a request did not appear () and is discarded at time . Let us note the time at which the vehicle becomes available for whereas does not appear.


This probability is computed recursively, like for . The base case is:


The general case is quite similar to the one of function . We just consider the probability that does not reveal and replace by :


A note on implementation.

Since we are interested in computing for each request separately, by following the definition of , we only require the -probability associated to to be already computed. This suggests a dynamic programming approach. Computing all the -probabilities can then be incrementally achieved while filling up a 2-dimensional matrix containing all the -probabilities. By using an adequate data structure while filling up such a sparse matrix, substantial savings can be made on the computational effort.

Computational complexity.

The time complexity of computing the expected cost is equivalent to the one of filling up a matrix for each visited waiting location , in order to store all the probabilities. By processing incrementally on each waiting location separately, each matrix cell can be computed in constant time using equation (9). In particular, once the probabilities in cells are known, the cell such that may be computed in according to equations (8) - (12). Given customer locations and a time horizon of length , we have at most potential requests. It then requires at most constant time operations to compute .

5 Recourse strategy with bounded capacity:

In this section we show how to generalize in order to handle capacitated vehicles in the context of integer customer demands.

5.1 Description of

The recourse strategy only differs from in the way requests are either accepted or rejected. The request notification phase (described in Section 4.1) is modified by adding a new condition that takes care of the current vehicle load. Under , a request is therefore accepted if and only if:


In Section 5.2, we show how to adapt the closed form expressions described in Section 4.2 in order to compute the exact expected cost when vehicles have limited capacity. In section 5.3, we show how the resulting equations, when specialized to the special case of the SS-VRP-C, naturally reduce to the ones proposed in Bertsimas (1992).

5.2 Expected cost of second stage solutions under

Contrary to strategy , under strategy a request may be rejected if the corresponding vehicle is full. Recall that is the set of potential requests in route , ordered by . We note the load of vehicle at time . The probability now depends on what happened earlier, not only on the current waiting location, but also on previous waiting locations (if any). To describe , we need to consider every possible time and load configurations for :


Computation of probability is the probability that has been revealed, and vehicle leaves at time with load to serve , i.e.,

The base case for computing is now concerned with the very first potential request on the entire route, , which must be considered as soon as the vehicle arrives at , that is at time except if :


For any , function must be equal to zero as the vehicle necessarily carries an empty load when considering .

Like under strategy , the first potential request of a planned waiting location which is not the first of the route (i.e., ) is special as well. As the arrival time on is fixed by the first stage solution, is necessarily . Unlike , is not deterministic but rather depends on what happened on the previous waiting location . Hence, we extend the definition of probability to handle this special case: When , is the probability that vehicle finishes to serve at time with load . The complete definition and computation of is detailed in the next paragraph. Given this probability , the probability that vehicle carries a load is obtained by summing these probabilities for every time unit during which vehicle may serve , i.e. . Therefore, for every request which is the first of a waiting vertex, but not the first of the route, we have:


Finally, the general case of a request which is not the first request of a waiting location depends on the time and