The Static and Stochastic VRPTW with both random Customers and Reveal Times: algorithms and recourse strategies
Abstract
Unlike its deterministic counterpart, static and stochastic vehicle routing problems (SSVRP) aim at modeling and solving reallife operational problems by considering uncertainty on data. We consider the SSVRPTWCR introduced in SaintGuillain et al. (2017). Like the SSVRP 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 SSVRP variants, the SSVRPTWCR 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 SSVRPTWCR, together with their closedform 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 branchandcut 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 SSVRPTWCR, based on realworld data coming from the city of Lyon. We evaluate our two algorithms on this benchmark and empirically demonstrate the expected superiority of the SSVRPTWCR anticipative actions over a basic “waitandserve” policy.
keywords:
stochastic vehicle routing, ondemand transportation, optimization under uncertainty, recourse strategies, operations research1 Introduction
The Vehicle Routing Problem (VRP) aims at modeling and solving a reallife 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 realworld 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 firststage solution which is adapted online when random variables are realized.
Two different kinds of adaptations may be considered: Dynamic and Stochastic VRP(TW) (DSVRP(TW)) and Static and Stochastic VRP(TW) (SSVRP(TW)). In the DSVRP(TW), the solution is reoptimized at each timestep, and this reoptimization involves solving an hard problem. Therefore, it is usually approximated with metaheuristics as proposed, for example, in Ichoua et al. (2006); Bent and Van Hentenryck (2007); SaintGuillain et al. (2015).
In the SSVRP(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 SSVRP with random demands has been proposed by Yang et al. (2000). Biesinger et al. (2016) later introduced a variant for the Generalized SSVRP with random demands.
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 SSVRPs with random Customers (SSVRPC) assumes full knowledge on the presence of customers at the beginning of the operational period.
In this paper, we focus on the SSVRPTW with both random Customers and Reveal times (SSVRPTWCR) recently introduced in SaintGuillain et al. (2017). The SSVRPTWCR 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 firststage 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 firststage solution that minimizes the expected number of rejected requests.
An example of practical application of the SSVRPTWCR is an ondemand 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 firststage 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 SSVRPTWCR recently introduced in SaintGuillain 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 closedform expressions to efficiently compute expected costs for these two new recourse strategies. We also propose a stochastic integer programming formulation and an extended branchandcut algorithm for these recourse strategies.
Another contribution is to introduce a new public benchmark for the SSVRPTWCR, based on realword data coming from the city of Lyon. By comparing with a basic (yet realistic) waitandserve 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 SaintGuillain et al. (2017) not only gives nearoptimal 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 SSVRPTWCR 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 SSVRPTWCR with respect to them. Section 3 formally defines the general SSVRPTWCR. Section 4 describes the recourse strategy already introduced in SaintGuillain 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 branchandcut based solving method for solving the problem to optimality. Section 8 describes the heuristic algorithm of SaintGuillain 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 SSVRPTWCR 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 SSVRP may be found in Gendreau et al. (1996b), Bertsimas and SimchiLevi (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 SSVRPs are:

Stochastic customers (SSVRPC), where customer presences are described by random variables;
Since the SSVRPTWCR 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 (SSTSPC), 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 SSTSPC, using the integer Lshaped method for twostage stochastic programs proposed in Laporte and Louveaux (1993) to solve instances up to 50 customers. Heuristics for the SSTSPC 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 metaheuristics 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 SSTSPC. A Pickup and Delivery Traveling Salesman Problem with stochastic Customers is considered in Beraldi et al. (2005), as an extension of the SSTSPC in which each pickup and delivery request materializes with a given probability.
Particularly close to the SSVRPTWCR is the SSTSPC with Deadlines introduced by Campbell and Thomas (2008b). Unlike the SSVRPTWCR, 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 generalpurpose computing on graphics processing units. A recent literature review on the SSTSPC may be found in Henchiri et al. (2014).
The first SSVRPC has been studied by Jezequel (1985), Jaillet (1987) and Jaillet and Odoni (1988) as a generalization of the SSTSPC. Waters (1989) considered general integer demands and compared different heuristics. Bertsimas (1992) considered a VRP with stochastic Customers and Demands (SSVRPCD). 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, closedform 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 SSVRPCD for instances up to 70 customers, by means of an integer Lshaped 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 SSVRPC and assessed it on benchmarks with up to 483 customers and 38 vehicles.
Sungur and Ren (2010) considered a variant of the SSVRPTWC, 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 SSVRPTWCR, the set of customers is revealed at the beginning of the operations.
Heilporn et al. (2011) introduced the DialaRide 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 SSVRPTWCR 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 SSVRPTWCR
In this section, we recall the description of the SSVRPTWCR initially introduced in SaintGuillain 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 
First stage solution.
The firststage 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 SSVRPTWCR, 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 SSVRPTWCR 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.
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 :
(1) 
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 SSVRPTWCR minimizes the expected cost of the second stage solution:
(SSVRPTWCR)  (2)  
(3) 
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 :
(4) 
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 SaintGuillain 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 firststage 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 firststage 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 
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.
4.2 Expected cost of second stage solutions under
Provided a recourse strategy and a first stage solution to the SSVRPTWCR, 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.,
(5) 
where the righthand 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 :
(6) 
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:
(7) 
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:
(8) 
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:
(9) 
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 .
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.
(10) 
This probability is computed recursively, like for . The base case is:
(11) 
The general case is quite similar to the one of function .
We just consider the probability that does not reveal and replace by :
(12) 
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 2dimensional 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:
(13) 
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 SSVRPC, 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 :
(14) 
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 :
if  
(15) 
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:
if  
(16) 
Finally, the general case of a request which is not the first request of a waiting location depends on the time and