A matheuristic for a multimodal long haul routing problem

Abstract

We address a planning problem faced by logistics service providers who transport freight over long distances. Given a set of transportation requests, where the origin and the destination of each request are located far apart from each other, a logistics service provider must find feasible vehicle routes to fulfil those requests at minimum cost. When transporting freight over long distances, multimodal transportation provides a viable alternative to traditional unimodal road transportation. We introduce this new problem, which we call the multimodal long haul routing problem (MMLHRP), and present a mathematical formulation for it. Furthermore, we propose a matheuristic, using iterated local search within a column generation framework, for solving the MMLHRP. Results show that large cost savings can be achieved through multimodal transportation compared to unimodal road transportation.

1 Introduction

Long-distance transportation plays an increasingly important role in freight transportation in Europe. In 2015 more than 40% of freight volumes transported on the road within the European Union were carried on distances larger than 500 km. This ratio is expected to increase even further in the future (Eurostat 2016a).

A long-distance transport can be split up in three segments: first-mile (i.e., the pickup process), long haul (i.e., the long-distance transportation), and last-mile (i.e., the delivery process). Typically the first- and last-mile transports need to be conducted by road transportation as most companies do not have a direct connection to a rail network and are not located at a port. For the long haul, on the other hand, additional modes of transportation such as rail or water can be considered. The main advantages of combining several modes of transportation are both lower costs and a lower environmental impact compared to traditional unimodal road transportation (SteadieSeifi et al. 2014).

Although the rail network in Europe is well elaborated and maintained, and the Rhine-Main-Danube axis provides an excellent opportunity to include inland waterways in the transport chain (especially in Central and East Europe), freight transportation in Europe is currently still mainly done via road. The statistical office of the European Union reports a modal split of 75.4, 18, and 6.6% for road transportation, rail transportation, and inland waterway transportation, respectively, for the year 2014 (Eurostat 2016b).

In this article we consider an operational problem faced by logistics service providers who transport freight over long distances. That is, given a set of transport requests where the origin and the destination of each request are located far apart from each other, the logistics service providers must find feasible vehicle routes to fulfil those requests at minimum cost. We consider the full truck load version of this problem. That is, we consider only full truck loads in the first- and last-mile, and allow consolidation of requests only on long haul vehicles. This version of the problem arises in many industrial contexts such as transportation of raw materials or steel products, where more than one short haul vehicle is needed to transport a single request. We consider a heterogeneous fleet of long haul vehicles corresponding to different modes of transportation and assume that the logistics service providers do not operate a fleet of short haul vehicles themselves, but utilize carriers. A vehicle which conducts a long-distance transport might have to travel for several days. In many cases, labour regulations prohibit a vehicle (e.g. a truck with just one driver) from travelling such a long time non-stop. In order to take such constraints into account we consider a daily operation time limit for each vehicle. Furthermore, we assume that a request may be split among several long haul vehicles (possibly associated with different transportation modes). That is, we allow a request to be split into an arbitrary number of parts. Each of those parts may be transported on a different path from the origin to the destination.

Research in the area of multimodal freight transportation planning increased considerably in recent years (SteadieSeifi et al. 2014). An overview of the literature in the field of multimodal transportation planning can be found in the two most recent surveys of SteadieSeifi et al. (2014) and Caris et al. (2013).

A vast body of work deals with the Service Network Design Problem (SNDP), i.e., the (optimal) selection and scheduling of transportation services and choosing associated transportation modes, and determining the routing and flow of freight through the selected service network. A service is characterized by its origin, destination, and intermediate terminals (its route), its frequency and service capacity, and its transportation mode. A mode is characterized by its speed, loading capacity, and price. Additionally, services and modes are usually assumed to have fixed costs. Such tactical planning problems are typically modelled as fixed-cost capacitated multicommodity network design formulations on time-space networks. Recently, vehicle routing aspects have also been considered in SNDPs in the form of asset (e.g. vehicles) management. A limited number of vehicles is assigned to each terminal (to which they must return). Vehicle management is then mainly incorporated as “design-balance constraints” (Pedersen et al. 2009) requiring that the number of vehicles entering and leaving a terminal must be the same, or through the design of cycles (see, for instance, Andersen et al. 2009; Andersen and Christiansen 2009; Crainic et al. 2016).

However, these formulations do not consider the routing of first- and last-mile transportation. A very recent work which does consider it is by Medina et al. (2018), who essentially combine the SNDP with the Vehicle Routing Problem (VRP) and call this new problem the Service Network Design and Routing Problem (SNDRP). In this problem each supplier is assigned to a single terminal in a long haul consolidation network to which it sends goods, and each customer is assigned to a single terminal from which its shipments are delivered. Direct shipments from suppliers to terminals are assumed, but the problem allows for delivery routes that visit several customers. The first-mile together with the consolidation network are then modelled as a SNDP, while the delivery routes are modelled as a VRP. The authors present two formulations on a time-space network (one route-based and one arc-based) and solve both with a dynamic discretisation discovery algorithm.

The literature on operational multimodal transportation planning is still scarce, though (SteadieSeifi et al. 2014). Moreover, only a small part of those studies concern multimodal vehicle routing. Research on multimodal routing is mostly limited to commodity flow formulations. Such formulations usually assume an unlimited availability of first- and last-mile modes of transportation, and known fixed schedules and free capacities for long haul modes of transportation. Shipments are then routed through the multimodal network by deciding upon the usage of those predefined scheduled and unscheduled services (see for example Barnhart and Ratliff 1993; Ziliaskopoulos and Wardell 2000; Chang 2008; Moccia et al. 2011).

Bock (2010) studies a multimodal vehicle routing problem. The model integrates multiple modes of transportation, transshipments, dynamic disturbances, and partial or total outsourcing of transportation services. However, split loads are not considered and the end of every time window is considered as soft, i.e. late arrivals are allowed. The dynamic problem is modelled as a rolling horizon scheme and solved with a variable neighbourhood search algorithm.

Two relevant related problems are the Pickup and Delivery Problem with transshipment (PDPT) and the Pickup and Delivery Problem with split loads (PDPSL).

Regarding the PDPT Mitrovic-Minic and Laporte (2006) develop a two-phase heuristic solution method. They test it on small instances and show the usefulness of performing transshipments. Cortés et al. (2010) present an arc-based mixed-integer formulation for the problem which they solve by means of a branch-and-cut method. Qu and Bard (2012) solve the PDPT with a GRASP which uses an adaptive large neighbourhood search in the improvement phase. Masson et al. (2013) use a pure adaptive large neighbourhood search to tackle the PDPT in a passenger transportation application. Rais et al. (2014) propose a new mixed-integer formulation which they solve with a commercial solver on small instances. Recently, Neves-Moreira et al. (2016) proposed a fix-and-optimize matheuristic for the PDPT with additional side constraints. The authors test their solution approach on real-world instances of a long haul freight transportation problem.

Regarding split loads, Nowak et al. (2008) propose a heuristic algorithm for the PDPSL and solve several random large-scale instances. Andersson et al. (2011) and Stålhane et al. (2012) solve the maritime version of the problem. The former suggests a solution method based on a priori generation of single ship schedules and two path flow models that deal with the selection of ship schedules and assignment of quantities to the schedules. The latter solves the problem by means of a branch-and-price-and-cut method. Both test their methods on randomly generated instances.

The contribution of our paper is threefold. First, we introduce a new problem, which we call the multimodal long haul routing problem (MMLHRP). To the best of our knowledge, no previous work has combined the routing of long haul vehicles associated with different transportation modes with the scheduling of both first- and last-mile transportation, where requests are allowed to be split and vehicle operation time limits are considered. Second, we propose a matheuristic, using iterated local search within a column generation framework, for solving the MMLHRP. Third, we present managerial insights regarding both the logistics of multimodal transport and the potential cost savings through multimodal transport. These insights are based on results of computational experiments which are based on real data.

The remainder of this article is structured as follows: In Sect. 2, we give a formal description of the problem. In Sect. 3, a set covering formulation for the MMLHRP and a column generation algorithm to solve its linear relaxation are presented. In Sect. 4, we describe a matheuristic based on column generation for the MMLHRP, while computational experiments and a managerial discussion are presented in Sect. 5. Conclusions are reported in Sect. 6.

2 Problem description

We are given a set of requests R. Each request $r \in R$ is associated with a pickup location $r^+$, a delivery location $r^-$, a positive load $d_r$, and two time windows; one for the pickup location $\left( \left[ a_{r^+}, b_{r^+}\right] \right)$ and one for the delivery location $\left( [a_{r^-}, b_{r^-}]\right)$.

Furthermore, a heterogeneous fleet of vehicles K is given. Each vehicle $k \in K$ has a non-negative capacity $q_k$, a start depot $o_k$ at which it must start its tour, and an end depot $\eta _k$ at which it must end its tour. We consider two types of vehicles: short haul vehicles (e.g. trucks) and long haul vehicles (e.g. ships or trains). Long haul vehicles are further split up into active vehicles and passive vehicles. The difference between an active and a passive vehicle is, that an active vehicle can move on its own while a passive vehicle cannot. This means, that a passive vehicle must always move together with an active vehicle. The number of passive vehicles an active vehicle pulls/pushes may vary throughout its tour, but must not exceed a maximum number u at any given point in time. Each vehicle is subject to a limit $e_k$ on the amount of hours per day it is allowed to operate, which must not be exceeded.

To facilitate the transshipment of load from short haul vehicles to long haul vehicles, and vice versa, a set of transshipment locations T is given. We assume that there are neither waiting times nor capacity restrictions at transshipment locations. Furthermore, we assume site dependency, that is to say, only short haul vehicles are able to visit every location, while long haul vehicles may only visit their respective depots and transshipment locations.

The problem is defined on a directed graph $G = (V,A)$, where V and A are the vertex and arc sets, respectively. V is composed of the start and end depot for each vehicle, the set of pickup nodes, the set of delivery nodes, and the set of transshipment nodes. The set of arcs $A = \bigcup \nolimits _{k \in K} A^k$, where $A^k \subset V \times V$, defines the feasible movements of each vehicle $k \in K$ between the different nodes in V.

With each arc $(i,j) \in A$ and each vehicle $k \in K$ is associated a travel cost $c_{ijk}$ and a travel time $t_{ijk}$. Furthermore, with each transshipment node $i \in T$ is associated a transshipment cost $m_i$ per transferred unit. We assume that the triangle inequality holds for travel costs and travel times.

Service at a customer location must start within the prescribed time window. A vehicle may arrive prior to the beginning of the time window, but, in this case, must wait until the time window starts before starting the service. A time window is also associated with the depots. The time needed for service at any location depends on both the quantity to (un)load and the vehicle type. $h_{ik}$ denotes the time needed for vehicle $k \in K$ to (un)load one unit at vertex $i \in V$.

As already mentioned, we assume that the LSPs do not operate a fleet of short haul vehicles themselves, but utilize carriers. Consequently, only trips where a short haul vehicle carries load raise costs, and, therefore, only these trips need to be considered. Furthermore, we restrict short haul vehicle transportation to full truck loads and only allow consolidation of requests on long haul vehicles. The load of a single request may be split among several long haul vehicles or even transshipped to/from the same long haul vehicle at several transshipment locations. Each part of a request may thus be transported on a different path from the pickup location to the delivery location. Consequently, each split makes it more complicated for practitioners. That is, the number of routes, logistics operations, and administrative tasks increases with each split, as well as both the routes and the product flows become more complex. Therefore, practitioners try to avoid splitting the load of a request too often. To take this into account we assume the following transshipment policy (P1): always transship as much units of load of a request as possible. That is, in case of a transshipment to a long haul vehicle, transship units of load equal to either the free capacity of the long haul vehicle or the residual load of the request. In case of a transshipment from a long haul vehicle, unload the complete amount of units of load of the request currently on the long haul vehicle.

Following the idea of generating practical solutions, we assume that each unit of load may use at most one long haul vehicle. Thus, a unit of load can only be transported in one of two ways:

• 1. unimodal: using only a short haul vehicle to directly transport the unit of load from its pickup location to its delivery location

• 2. multimodal: using a short haul vehicle only for the first- and last-mile, and using one, and only one, long haul vehicle for the long-distance transportation in between

The objective is to find a set of feasible short haul vehicle trips and long haul vehicle routes that serves all requests, such that the sum of travel costs and transshipment costs is minimized.

A feasible trip for a short haul vehicle corresponds to an arc in the graph G, while a feasible route for a long haul vehicle corresponds to a path from the start depot to the end depot in the graph G. Both a trip and a path are feasible if the vehicle capacity and the limit on the amount of hours per day the vehicle is allowed to operate are never exceeded. For short haul vehicles, the time windows at the customer nodes must be respected and, in case a short haul vehicle performs a direct transport of a request from its pickup location to its delivery location, the pickup node must be visited before the delivery node. Similarly, for long haul vehicles the time windows at the start depot and end depot must be respected and a (partial load of a) request must always be loaded onto the vehicle before it is unloaded from the vehicle. Furthermore, if a transshipment takes place the vehicle which receives the load must start its service at the transshipment node after the vehicle which gives the load.

Figure 1 illustrates a small problem instance (Fig. 1a) together with a feasible solution (Fig. 1b). It consists of four requests (1, 2, 3, 4) and five transfer locations (a, b, c, d, e). The transfer locations with bold borders represent the depots. The long haul of requests 1 and 2 is performed by a water bound long haul vehicle (e.g. a ship), while the long haul of request 3 is performed by a rail bound long haul vehicle (e.g. a train). For all three requests only the first-/and last-mile transports are performed by short haul vehicles. Because the origin location of request 4 is too far away from any transfer location, it is transported from its origin location to its destination location exclusively with short haul vehicles. The route of the water bound long haul vehicle (dashed line) is: $a-b-c-a$, the route of the rail bound long haul vehicle (dotted line) is: $d-e-d$, and the short haul vehicle trips (solid lines) are: $1^+-a$, $2^+-b$, $3^+-d$, $4^+-4^-$, $c-1^-$, $c-2^-$, $e-3^-$.

Fig. 1

Small problem instance (a) consisting of four requests (1, 2, 3, 4) and five transfer locations (a, b, c, d, e) together with a feasible solution (b). The transfer locations with bold borders represent the depots

Using the above notation, we can model the MMLHRP without policy P1 as an arc flow formulation (see Appendix 1). However, this model is of limited use as even this simplified version of the problem is barely solvable with a commercial solver for tiny instances with respect to both solution time and memory usage. Figure 2 shows the increase in both the time until the root node is solved and the size of the process in the memory after the root node has been solved as a function of the number of requests. The depicted values are an average of five instances per number of requests. The number of locations in an instance ranges from seven in instances with one request to 29 in instances with six requests. In each instance one water bound long haul vehicle, one rail bound long haul vehicle, and a sufficient amount of short haul vehicles (between 38 and 363 vehicles) are available to transport all requests. From Fig. 2 it becomes clear that a more sophisticated solution technique, which performs better and allows us to implement policy P1, is required.

Fig. 2

Average time and memory consumption of the arc flow formulation using a commercial solver

3 A set covering formulation for the MMLHRP

Because the arc flow formulation is of limited use for generating lower bounds for the MMLHRP (see Fig. 2) we use a set covering formulation instead. Besides the fact that for vehicle routing, set covering formulations yield better lower bounds than compact formulations (Semet et al. 2014), using a set covering formulation allows us to effectively solve larger problem instances. First, let us introduce some additional notation. Let $\Omega$ be the set of all feasible short haul vehicle trips from the pickup location of a request to its delivery location. Such a trip corresponds to an arc in the graph G of the form $(r^+,r^-):r \in R$, and represents a direct unimodal transport of a request. In addition, $\Omega$ contains all feasible sets ${\mathscr {C}} = \left\{ {\mathscr {H}},{\mathscr {S}}\right\}$, where ${\mathscr {H}}$ is a long haul vehicle route and ${\mathscr {S}}$ is a set of first- and last-mile trips of short haul vehicles. ${\mathscr {H}}$ corresponds to a path in the graph G from the vehicle’s start depot to its end depot. A trip $s \in {\mathscr {S}}$ corresponds to an arc in the graph G either of the form $(r^+,t):r \in R, t \in T$ or of the form $(t,r^-):r \in R, t \in T$. The former type of a trip represents a first-mile transport, while the latter represents a last-mile transport. A set ${\mathscr {C}}$ is feasible if, and only if, ${\mathscr {H}}$ is feasible, all $s \in {\mathscr {S}}$ are feasible, and ${\mathscr {H}}$ and ${\mathscr {S}}$ together allow for a feasible flow of each request transported by the long haul vehicle from its origin to its destination. A set ${\mathscr {C}}$, thus, represents one long haul vehicle route together with the necessary first- and last-mile transports by short haul vehicles. Consequently, a column $j \in \Omega$ consists of at least one short haul vehicle trip, and at most one long haul vehicle route.

Let $P = \bigcup \nolimits _{r \in R} r^+$ be the set of pickup nodes, and $\delta _i$ be the demand of pickup node $i \in P$. Let ${\mathscr {K}}^{SHV}$ be the set of short haul vehicle types (e.g., truck), ${\mathscr {K}}^{AV}$ be the set of active long haul vehicle types (e.g., ship or train), and ${\mathscr {K}}^{PV}$ be the set of passive long haul vehicle types (e.g., barge). Then, ${\mathscr {K}} = {\mathscr {K}}^{SHV} \cup {\mathscr {K}}^{AV} \cup {\mathscr {K}}^{PV}$ is the set of all vehicle types. We denote with ${\mathscr {W}}_k$ the number of available vehicles of type $k \in {\mathscr {K}}$. For each column $j \in \Omega$ let $\hat{c}_j$ be the cost of the column. $\mu _{ij}$ denotes the quantity of pickup node $i \in P$ delivered in column $j \in \Omega$, while $\rho _{kj}$ is the number of vehicles of type $k \in {\mathscr {K}}$ used in column $j \in \Omega$. The non-negative integer variable $\theta _j$ indicates the number of times column $j \in \Omega$ is in the solution.

With the above notation, the MMLHRP can be formulated as follows:

$$\begin{aligned} \min ~~\sum _{j \in \Omega } \hat{c}_j\theta _j \end{aligned}$$

(1)

subject to

$$\begin{aligned} \sum _{j \in \Omega } \mu _{ij}\theta _j \ge \delta _i \quad&\forall \ i \in P\end{aligned}$$

(2)

$$\begin{aligned} \sum _{j \in \Omega } \rho _{kj}\theta _j \le {\mathscr {W}}_k \quad&\forall \ k \in {\mathscr {K}}\end{aligned}$$

(3)

$$\begin{aligned} \theta _j \in {\mathbb {N}} \quad&\forall \ j \in \Omega \end{aligned}$$

(4)

The objective function (1) aims at minimizing the total costs. Constraints (2) ensure that the demand of each request is satisfied, while constraints (3) restrict the number of used vehicles in a solution to the number of available vehicles. Constraints (4) impose integrality requirements on the decision variable $\theta _j$.

Due to the large size of $\Omega$, solving the problem defined by (1)–(4) explicitly is impractical. Instead, we solve its LP-relaxation, called Master Problem (MP), with a column generation approach. To obtain the LP-relaxation the integrality requirements (4) are replaced by

$$\begin{aligned} \theta _j \ge 0 \quad \forall \ j \in \Omega \end{aligned}$$

(5)

The aim of the column generation approach is to solve the MP by finding a subset $\Omega ' \subseteq \Omega$ of columns, such that solving MP($\Omega '$) also solves MP. MP($\Omega '$) is called the Restricted Master Problem (RMP).

The approach starts with an initial set of columns and then iteratively solves the RMP and a pricing subproblem to produce columns with negative reduced cost, using dual information from the RMP. In each iteration these new columns are added to the RMP to obtain new dual information. This procedure is repeated until no new columns can be found. At that point an optimal solution of the RMP, and therefore of MP, has been found, which represents a lower bound for the problem (1)–(4).

3.1 The pricing subproblem

The pricing subproblem aims at finding a variable $\theta _j$ that has the lowest reduced cost with respect to a given dual solution to the RMP. Let $\gamma _i$ and $\beta _k$ be the dual variables associated with constraints (2) and (3), respectively. The reduced cost $\overline{c}_j$ of a variable $\theta _j$ are given by

$$\begin{aligned} \overline{c}_j = \hat{c}_j - \sum _{i \in P} \mu _{ij} \gamma _i - \sum _{k \in {\mathscr {K}}} \rho _{kj} \beta _k \end{aligned}$$

(6)

The subproblem is defined on graph G and its formulation makes use of the variables and sets as defined in Appendix 1. Some of which we repeat here for the sake of clarity:

Variables

$$\begin{aligned} f_{ijrk} \quad&\text { amount of request } r \in R \text { transported by vehicle } k \in K \text { over arc } (i,j) \in A \\ w_{irkk'} \quad&\text { amount of request } r \in R \text { transshipped from vehicle } k \in K \\&\text { to vehicle } k' \in K \text { at node } i \in T \\ x_{ijk} \quad&{\left\{ \begin{array}{ll} \text {1 ~iff vehicle } k \in K \text { traverses arc } (i,j) \in A \\ \text {0 ~otherwise} \end{array}\right. } \\ \end{aligned}$$

Sets and parameters

$$\begin{aligned} B \quad&\text {set of short haul vehicles} \quad&c_{ijk} \quad&\text {cost of traversing arc } (i,j) \in A^k \text { for vehicle } k \in K \\ C \quad&\text {set of active vehicles} \quad&m_i \quad&\text {transshipment cost per unit at transship. node } i \in T \\ E \quad&\text {set of passive vehicles} \quad&r^+ \quad&\text {pickup node of request } r \in R \\ K \quad&B \cup C \cup E \quad&r^- \quad&\text {delivery node of request } r \in R \\ q_k \quad&\text {capacity of vehicle } k \in K \quad&o_k / \eta _k \quad&\text {start-/end-depot of vehicle } k \in K \\ \end{aligned}$$

Using these variables $\hat{c}_j$ can be given by

$$\begin{aligned} \hat{c}_j = \sum _{(i,j) \in A^k} \sum _{k \in K} c_{ijk} x_{ijk} + \sum _{i \in T} \sum _{r \in R} \sum _{k \in K} \sum _{k' \in K} m_i w_{irkk'} \end{aligned}$$

Consequently, the subproblem then is

$$\begin{aligned} \min ~ \sum _{(i,j) \in A^k} \sum _{k \in K} c_{ijk} x_{ijk}+ & {} \sum _{i \in T} \sum _{r \in R} \sum _{k \in K} \sum _{k' \in K} m_i w_{irkk'} \nonumber \\- & {} \sum _{r \in R} \sum _{j \in V} \sum _{k \in K} \gamma _{r^+} f_{r^+jrk} - \sum _{k \in {\mathscr {K}}} \beta _k \left( \sum _{\begin{array}{c} k' \in K:\\ type(k')=k \end{array}} \sum _{\begin{array}{c} j \in V {\setminus }\\ \left\{ \eta _{k'}\right\} \end{array}} x_{o_{k'}jk'} \right) \end{aligned}$$

(7)

subject to

$$\begin{aligned}&\text {route- and transshipment-feasibility constraints (26)--(44) ~~~~(see Appendix 1)}\end{aligned}$$

(8)

$$\begin{aligned}&\text {transshipment policy constraints} \end{aligned}$$

(9)

Constraints (9) ensure that transshipment policy P1 is satisfied. P1 says to always transship as much units of load of a request as possible. For a more detailed description of P1 see Sect. 2. The function type(x) returns the vehicle type $k \in {\mathscr {K}}$ of vehicle $x \in K$. The purpose of this function is purely notational, namely to establish a link between the set of vehicles K of the arc flow formulation and the set of vehicle types ${\mathscr {K}}$ of the set covering formulation.

Due to the property of a column that it contains at most one long haul vehicle route and because all vehicles of the same type are assumed to be identical, one subproblem for each vehicle type arises. Each subproblem can be solved independently from the others. Also, since passive vehicles cannot move on their own, no separate subproblem is required for them. Rather, passive vehicles are taken into account together with active vehicles in one subproblem. Thus, the set of vehicles K in each subproblem contains only short haul vehicles and at most one long haul vehicle.

3.2 Solving the pricing subproblem

We model each pricing subproblem which considers a long haul vehicle type as a Shortest Path Problem with Resource Constraints (SPPRC). The subproblem which considers only short haul vehicles, on the other hand, can be solved by generating for each request $r \in R$ a column j which contains only the arc $\left( r^+, r^- \right)$. The cost of such a column is $\hat{c}_j = c_{r^+r^-k'}$, where $k' \in B$. The quantity delivered in such a column is $\mu _{r^+j} = \min \left( q_{k'},\delta _{r^+}\right)$, while the number of vehicles used is $\rho _{kj} = 1$, where $k \in {\mathscr {K}}^{SHV}$. We use the set of all such columns as the initial set $\Omega '$ for the column generation approach.

Each SPPRC is defined on an auxiliary graph $G' = (V',A')$. The vertex set $V'$ contains the source vertex s and and the sink vertex z, representing the start and end depot. Additionally, $V'$ contains two sets of vertices $\Pi ^+$ and $\Pi ^-$. Each vertex $\pi _{ir}^+ \in \Pi ^+$ (called pickup-transfer-node, PTN) represents at least one (possibly several) short haul vehicle trip(s) $(r^+,i)$ plus a transshipment of request $r \in R$ from the short haul vehicle(s) to the long haul vehicle at transshipment location $i \in T$. Each vertex $\pi _{ir}^- \in \Pi ^-$ (called delivery-transfer-node, DTN) represents at least one (possibly several) short haul vehicle trips $(i,r^-)$ plus a transshipment of request $r \in R$ from the long haul vehicle to the short haul vehicle(s). With each vertex $v \in V'$ is associated a time window $[a_v,b_v]$. The time windows are generated during pre-processing in the following way:

• $a_s = a_{o_k}$, $b_s = b_{o_k}$, $a_z = a_{\eta _k}$, and $b_z = b_{\eta _k}$, where $k \in C \cup E$

• $a_{\pi _{ir}^+} = a_{r^+} + t_{r^+ik}$, where $k \in B$

• $b_{\pi _{ir}^+} = \max \limits _{j \in T}(b_{r^-} - t_{jr^-k} - t_{ijk'})$, where $k \in B$ and $k' \in C \cup E$

• $a_{\pi _{ir}^-} = 0$

• $b_{\pi _{ir}^-} = b_{r^-} - t_{ir^-k}$, where $k \in B$

The arc set $A'$ contains one arc from vertex s to each PTN, one arc for each feasible connection between and within all PTNs and DTNs, and one arc from each DTN to vertex z. In total, $A'$ contains 12 different types of arcs. Each arc type corresponds to a feasible action which the long haul vehicle can do. Table 1 gives a detailed description of each arc type.

Figure 3 gives an example of an auxiliary graph $G'$. It illustrates a small problem instance (Fig. 3a) together with the corresponding auxiliary graph for the water bound long haul vehicle (Fig. 3b). For the sake of clarity only one arc of each arc type is given as an example in Fig. 3b. The figure also indicates vertices which can be eliminated because they will never be part of an optimal solution (vertices with dashed borders). In general, every pair of a PTN and a DTN, where the travel cost of the corresponding first- and last-mile transports is larger than the travel cost of the direct transport from the pickup location to the delivery location of the request will not be part of any optimal solution. Consequently, every vertex which forms a part of only such non-eligible pairs will not be part of any optimal solution, and can therefore be eliminated.

Table 1 Description of arc types in $A'$

Fig. 3

Small problem instance (a) consisting of two requests (1, 2) and five transfer locations (a, b, c, d, e) together with an illustration of the corresponding auxiliary graph $G'$ for the water bound long haul vehicle (b). The transfer locations with bold borders represent the depots. For the sake of clarity only one arc of each arc type in $A'$ is given as an example. The numbers on the arcs indicate the arc type as given in Table 1. Dashed borders indicate vertices which can be eliminated, because they will never be part of an optimal solution

In the SPPRC one seeks to find a cheapest (shortest) path from the source vertex s to the sink vertex z. A common way to solve the SPPRC is to use a labelling algorithm (Feillet et al. 2004; Ropke and Cordeau 2009; Desaulniers 2010; Archetti et al. 2011). Such a dynamic programming algorithm builds feasible (partial) paths in $G'$ which start at the source vertex s and end at some vertex $i \in V'$. Each existing partial path is extended along the arcs leaving its end vertex. The algorithm starts with the partial path containing only vertex s and proceeds to create all feasible paths in $G'$. In order to speed up the algorithm, dominated paths can be discarded throughout the search. Path p dominates path $p'$ if both end at the same vertex, the cost of p is less then or equal to the cost of $p'$, and all feasible extensions of $p'$ to the sink vertex z are also feasible for p.

A feasible partial path from vertex s to any vertex $i \in V'$ is represented by a label associated with vertex i. A label ${\mathscr {L}} = (i, \zeta , {\mathfrak {R}})$ typically has one component $\zeta$ to represent the (reduced) cost of the path and a resource vector ${\mathfrak {R}}$. We define ${\mathfrak {R}} = \left( t,l,{\mathscr {O}},{\mathscr {U}},(d_1^+,\dots ,d_{|R|}^+),(d_1^-,\dots ,d_{|R|}^-), g \right)$. Each component of ${\mathfrak {R}}$ represents the consumption of a resource (e.g., time) along the path until vertex i. We adapt the label-setting algorithm from Ropke and Cordeau (2009) and consider labels of the form ${\mathscr {L}}_k = \left( i,\zeta ,t,l,{\mathscr {O}},{\mathscr {U}},(d_1^+,\dots ,d_{|R|}^+),(d_1^-,\dots ,d_{|R|}^-), g \right)$ where

• $k \in {\mathscr {K}}^{AV}$, indicates the type of long haul vehicle the label represents

• $i \in V'$ is the vertex of the label

• $\zeta$ is the accumulated cost

• t is the time when leaving vertex i

• l is the load of the vehicle when leaving vertex i

• ${\mathscr {O}} \subseteq R$ is the set of open requests. A request is considered to be open when the amount of its demand which has already been picked up is larger than the amount delivered.

• ${\mathscr {U}} \subseteq R$ is the set of unreachable requests. A request r is considered to be unreachable if either the whole load of it has already been picked up, or if every extension $(i,\pi _{jr}^+):j \in T$ would violate the time window at vertex $\pi _{jr}^+$.

• $d_r^+$, $r \in R$, indicates how many units of the load of request r have already been transshipped to the vehicle

• $d_r^-$, $r \in R$, indicates how many units of the load of request r have already been transshipped from the vehicle

• g gives the number of passive vehicles in use when leaving vertex i

In accordance with Ropke and Cordeau (2009) we use the notation $\zeta ({\mathscr {L}}_k)$ to refer to the cost of label ${\mathscr {L}}_k$ and consequently $i({\mathscr {L}}_k)$, $t({\mathscr {L}}_k)$, $l({\mathscr {L}}_k)$, ${\mathscr {O}}({\mathscr {L}}_k)$, ${\mathscr {U}}({\mathscr {L}}_k)$, $d_r^+({\mathscr {L}}_k)$, $d_r^-({\mathscr {L}}_k)$, and $g({\mathscr {L}}_k)$ for the resources. Additionally, let $q({\mathscr {L}}_k)$ denote the total capacity of the vehicle when leaving vertex i (including the capacity of all passive vehicles currently in use), $\tau ({\mathscr {L}}_k)$ denote the physical location of the label (i.e., the depot or transshipment location), r(i) refer to the request associated with vertex $i \in V'$, $\lambda _i$ denote the quantity of the request associated with vertex $i \in V'$ transferred to/from the vehicle at vertex i (note that $\lambda _i$ is a decision variable), h(i,k) denote the time needed by vehicle type $k \in {\mathscr {K}}$ for (un)loading one unit of load at node i, and $r^+(i)$ and $r^-(i)$ refer to the pickup location and the delivery location of request $r \in R$ associated with vertex $i \in V'$, respectively.

According to Ropke and Cordeau (2009), extending a label ${\mathscr {L}}_k$ along an arc $(i({\mathscr {L}}_k),j)$ is feasible only if one of the following three conditions is satisfied:

$$\begin{aligned}&j \in \Pi ^+ \wedge r(j) \notin {\mathscr {U}}({\mathscr {L}}_k)\end{aligned}$$

(10)

$$\begin{aligned}&j \in \Pi ^- \wedge r(j) \in {\mathscr {O}}({\mathscr {L}}_k)\end{aligned}$$

(11)

$$\begin{aligned}&j = z \wedge {\mathscr {O}}({\mathscr {L}}_k) = \emptyset \end{aligned}$$

(12)

Condition (10) states that if j is a PTN the respective request r is still reachable. Condition (11) states that if j is a DTN at least a part of the respective request r is currently on the vehicle. Condition (12) states that if j is the sink vertex then all load which has been picked up along the path has also been delivered.

The properties ensuring that the vehicle capacity and the time window are respected need to be adapted as follows:

$$\begin{aligned}&j \in \Pi ^- \vee \left( l \left( {\mathscr {L}}_k \right)< q \left( {\mathscr {L}}_k \right) \right) \vee \left( g \left( {\mathscr {L}}_k \right) < u \right) \end{aligned}$$

(13)

$$\begin{aligned}&\left( j \in \Pi ^- \wedge \left( t \left( {\mathscr {L}}_k \right) + t_{i \left( {\mathscr {L}}_k \right) ,jk} + h \left( j, k \right) \lambda _j \le b_j \right) \right) \vee \left( j \in \Pi ^+ \wedge t \left( {\mathscr {L}}_k \right) + t_{i \left( {\mathscr {L}}_k \right) ,jk} \le b_j \right) \end{aligned}$$

(14)

In order for a label extension to be feasible, properties (13) and (14) need to hold as well. Property (13) states that the vehicle capacity is respected if either j is a DTN, or the current load on the vehicle is less than the capacity of the vehicle, or the current number of passive vehicles in use is less than the maximum number of passive vehicles allowed. Property (14) states that in case j is a DTN, the time window at node j is respected if the time when leaving node i plus the travel time from node i to node j plus the service time at node j is less than or equal to the end of the time window at node j. Otherwise, in case j is a PTN, the time window is respected if the time when leaving node i plus the travel time from node i to node j is less than or equal to the end of the time window at node j. The difference in the calculation of the left hand side is a consequence of the different definitions of $b_j$ for a PTN and a DTN.

If the extension of label ${\mathscr {L}}_k$ along arc $(i({\mathscr {L}}_k),j)$ is feasible then a new label ${\mathscr {L}}'_k$ is created and the vertex of the label, the cost, and all resources must be updated as follows:

$$\begin{aligned}&i({\mathscr {L}}'_k) = j \end{aligned}$$

(15)

$$\begin{aligned}&\zeta \left( {\mathscr {L}}'_k \right) = \zeta \left( {\mathscr {L}}_k \right) + c_{i \left( {\mathscr {L}}_k \right) ,j} + g \left( {\mathscr {L}}_k \right) c_{i \left( {\mathscr {L}}_k \right) ,j} + {\left\{ \begin{array}{ll} - \beta _k \quad &{}\text {iff } j = z \\ \\ \left\lceil \frac{\lambda _j}{q_{k'}} \right\rceil c_{r^+ \left( j \right),\tau \left( j \right),k'} + \\ \quad \quad \lambda _j m_j - \left\lceil \frac{\lambda _j}{q_{k'}} \right\rceil \beta _{k''} - \\ \quad \quad \gamma _{r^+ \left( j \right)} \lambda _j - \\ \quad \quad {\operatorname{addlPV}} \left( {\mathscr {L}}'_k,{\mathscr {L}}_k \right) \beta _{k'''} \quad &{}\text {iff } j \in \Pi ^+ \\ \\ \left\lceil \frac{\lambda _j}{q_{k'}} \right\rceil c_{\tau \left( j \right),r^- \left( j \right),k'} + \\ \quad \quad \lambda _j m_j - \left\lceil \frac{\lambda _j}{q_{k'}} \right\rceil \beta _{k''}&{}\text {iff } j \in \Pi ^- \\ \\ k' \in B, k'' \in {\mathscr {K}}^{SHV} \\ k''' \in {\mathscr {K}}^{PV} \end{array}\right. } \end{aligned}$$

(16)

$$\begin{aligned}&t \left( {\mathscr {L}}'_k \right) = t \left( {\mathscr {L}}_k \right) + {\operatorname{addlTime}} \left( \max \left( a_j, t \left( {\mathscr {L}}_k \right) + {\operatorname{addlTime}} \left( t \left( {\mathscr {L}}_k \right) , t_{i \left( {\mathscr {L}}_k \right) ,j,k} \right) \right) ,h\left( i \left( {\mathscr {L}}_k \right) ,k \right) \lambda _j \right) \end{aligned}$$

(17)

$$\begin{aligned}&{\mathscr {U}} \left( {\mathscr {L}}'_k \right) = {\mathscr {U}} \left( {\mathscr {L}}_k \right) \cup \left \{ r \in R: \not \exists \pi _{ir}^+: t \left( {\mathscr {L}}'_k \right) + {\operatorname{addlTime}} \left( t \left( {\mathscr {L}}'_K \right) ,t_{j,\pi _{ir}^+ ,k} \right) \le b_{\pi _{ir}^+} \right \} \cup \left \{r(j): d_{r(j)}^+ = d_{r \left( j \right) } \right \}\end{aligned}$$

(18)

$$\begin{aligned}&l({\mathscr {L}}'_k) = {\left\{ \begin{array}{ll} l({\mathscr {L}}_k) + \lambda _j &{}\text {iff } j \in \Pi ^+ \\ l({\mathscr {L}}_k) - \lambda _j &{}\text {iff } j \in \Pi ^- \end{array}\right. } \end{aligned}$$

(19)

$$\begin{aligned}&{\mathscr {O}}({\mathscr {L}}'_k) = {\left\{ \begin{array}{ll} {\mathscr {O}}({\mathscr {L}}_k) \cup \{ r(j) \}&{}\text {iff } j \in \Pi ^+ \\ {\mathscr {O}}({\mathscr {L}}_k) {\setminus } \{ r(j) \}&{}\text {iff } j \in \Pi ^- \end{array}\right. } \end{aligned}$$

(20)

$$\begin{aligned}&d_r^+({\mathscr {L}}'_k) = {\left\{ \begin{array}{ll} d_r^+({\mathscr {L}}_k) + \lambda _j &{}\text {iff } j \in \Pi ^+ \wedge r = r(j) \\ d_r^+({\mathscr {L}}_k)\quad &{}\text {otherwise} \end{array}\right. } \end{aligned}$$

(21)

$$\begin{aligned}&d_r^-({\mathscr {L}}'_k)= {\left\{ \begin{array}{ll} d_r^-({\mathscr {L}}_k) + \lambda _j\quad &{}\text {iff } j \in \Pi ^- \wedge r = r(j) \\ d_r^-({\mathscr {L}}_k)\quad \quad \quad &{}\text {otherwise} \end{array}\right. } \end{aligned}$$

(22)

$$\begin{aligned}&g({\mathscr {L}}'_k) = {\left\{ \begin{array}{ll} \left\lceil \frac{l({\mathscr {L}}'_k)}{q_{k'}} \right\rceil \quad \quad \quad &{}\text {iff } j \in \Pi ^+, k' \in {\mathscr {K}}^{PV} \\ \\ g({\mathscr {L}}_k) \text { and create additional labels where } \\ \quad \quad g({\mathscr {L}}'_k) = x,\forall x\in {\mathbb {N}}: \left\lceil \frac{l({\mathscr {L}}'_k)}{q_{k'}} \right\rceil \le x < g({\mathscr {L}}_k)&{}\text {iff } j \in \Pi ^-, k' \in {\mathscr {K}}^{PV} \end{array}\right. } \end{aligned}$$

(23)

Updating rule (15) sets j as the vertex of the new label. Rule (16) updates the cost ($\zeta$). The cost of the new label is equal to the cost of the old label plus the travel cost of the active vehicle and the passive vehicles along arc $(i({\mathscr {L}}_k),j)$. Furthermore, if j is the sink vertex z the dual variable for the active vehicle needs to be deducted. If $j \in V' {\setminus } \left\{ s,z\right\}$, additionally the travel cost of each short haul vehicle used for the corresponding first-/last-mile transportations and the transshipment cost must be added, as well as the dual variable for each used short haul vehicle deducted. Finally, if j is a PTN (i.e. if a request is transshipped onto the vehicle) the dual variable of both the pickup node and any additional passive vehicle must be deducted from the cost of the new label. To determine the number of additional passive vehicles we use the function ${\operatorname{addlPV}}(x,y)$, which returns the number of additional passive vehicles used in label x compared to label y. It is defined as

$$\begin{aligned} {\operatorname{addlPV}} \left( x,y \right) = \max \left( g \left( x \right) - g \left( y \right) ,0 \right) \end{aligned}$$

The departure time (t) of the new label is set according to rule (17). It is equal to the departure time of the old label plus the travel time of the vehicle along arc $(i({\mathscr {L}}_k),j)$, plus the waiting time at j, plus the service time at j, plus the appropriate mandatory resting time. The appropriate amount of resting time depends on both the current time and the duration of the performed activity (i.e., (un)loading a request or traversing an arc). Therefore, the calculation of the new departure time needs to be done in two steps. First, the arrival time at node j is calculated. Then, given the arrival time, the start of the time window at j, and the service time, the departure time of the new label can be calculated. In both steps we use the function ${\operatorname{addlTime}}(x,y)$, which returns the amount of additional time needed to perform an activity with duration y, given the current time x. It takes the limit on the operation time of the vehicle into account and is defined as

$$\begin{aligned} {\operatorname{addlTime}} \left( x,y \right) = {\left\{ \begin{array}{ll} \omega + \aleph + \left\lfloor \frac{y}{e_k} \right\rfloor \xi + \left( y - \left\lfloor \frac{y}{e_k} \right\rfloor e_k \right) &{}\text {iff } \omega< 0 \\ \omega + \aleph + \left\lfloor \frac{y - \omega }{e_k} \right\rfloor \xi + \left( y - \omega - \left\lfloor \frac{y - \omega }{e_k} \right\rfloor e_k \right) &{}\text {iff } 0 \le \omega < y \\ y&{}\text {otherwise}, \end{array}\right. } \end{aligned}$$

where $\aleph$ denotes the amount of time units per day the vehicle must rest, $\xi$ denotes the total amount of time units per day, and $\omega$ is the residual time the vehicle may still work on the current day given by

$$\begin{aligned} \omega = e_k - \left( \left\lfloor x \right\rfloor \mod \xi \right) - \left( x - \left\lfloor x \right\rfloor \right) \end{aligned}$$

Rule (18) updates the set of unreachable requests (${\mathscr {U}}$) of the new label. It is equal to the union of the set of unreachable requests of the old label and the set of requests for which there is no time feasible extension from node j to any of their corresponding PTNs. Additionally, if all of the demand of the request which is associated with node j has already been picked up, then the set of unreachable requests of the new label also contains this request. Rules (19)–(22) update the load of the vehicle (l), the set of open requests (${\mathscr {O}}$), and the amount of each request which has already been transshipped to/from the vehicle ($d_r^+$/$d_r^-$), respectively. Rule (23) updates the number of passive vehicles in use (g). If j is a PTN, the number of passive vehicles in use is equal to the minimum number of passive vehicles required to carry the total load of the vehicle. If j is a DTN, the number of passive vehicles in use of the new label is equal to the number of passive vehicles in use of the old label. Furthermore, in this case, we create one additional label for each possible value of g between the minimum number of passive vehicles required and $g({\mathscr {L}}_k)$. Each of those labels is identical to the new label except for the value of g. Creating those additional labels is necessary in order to cover all feasible active-passive-vehicle combinations with which the new label can be extended further.

The amount of request $r \in R$ transshipped to/from a long haul vehicle at node $i \in V'$ (i.e., $\lambda _i$) is determined as follows:

$$\begin{aligned} \lambda _i = {\left\{ \begin{array}{ll} \min \left( \left( d_{r(i)} - d_{r(i)}^+ \right) , \left( q\left( {\mathscr {L}}_k \right) + \min \left( u-g, {\mathscr {W}}_k -g\right) q_{k'} - l \left( {\mathscr {L}}_k\right) \right) \right) \quad &{}\text {iff } i \in \Pi ^+ \\ d_{r(i)}^+ - d_{r(i)}^- \quad &{}\text {iff } i \in \Pi ^- \end{array}\right. } \end{aligned}$$

$\lambda _i$ is determined in accordance with transshipment policy P1. That is, if i is a PTN the amount of the corresponding request transshipped to the long haul vehicle is equal to the minimum of the amount of the request which has not yet been transshipped to the vehicle and the remaining capacity of the vehicle. The remaining capacity of the vehicle is equal to the current capacity of the vehicle, plus a possible increase of the capacity through addition of passive vehicles, minus the current load on the vehicle. If i is a DTN, the amount of the corresponding request transshipped from the vehicle is equal to the amount of the request which is currently on the vehicle.

In order to discard dominated labels during the search we use the following dominance conditions. Label ${\mathscr {L}}_k$ dominates label ${\mathscr {L}}'_k$ if all of the following conditions hold:

$$\begin{aligned} \tau ({\mathscr {L}}_k) &= \tau ({\mathscr {L}}'_k), \quad &\zeta ({\mathscr {L}}_k) &\le \zeta ({\mathscr {L}}'_k), \quad &t({\mathscr {L}}_k) &\le t({\mathscr {L}}'_k), \\ {\mathscr {O}}({\mathscr {L}}_k) &\subseteq {\mathscr {O}}({\mathscr {L}}'_k), \quad &\forall r \in R : d_r^+({\mathscr {L}}_k) &\le d_r^+({\mathscr {L}}'_k), \quad &{\mathscr {U}}({\mathscr {L}}_k) &\subseteq {\mathscr {U}}({\mathscr {L}}'_k), \text {and} \\ g({\mathscr {L}}_k) &= g({\mathscr {L}}'_k). \end{aligned}$$

3.3 The column generation algorithm

As already mentioned above, we initialize the RMP with a set of columns which contains one column for each request $r \in R$, corresponding to direct full truck load trips from their pickup location $r^+$ to their delivery location $r^-$. Whenever the label-setting algorithm finds at least one column with negative reduced cost, we add them to the RMP and re-solve it in order to obtain new dual information before we solve the next subproblem. Furthermore, we do not solve the subproblems to optimality in each iteration of the column generation algorithm, but stop after a sufficient amount of columns has been found by the label-setting algorithm. When the label-setting algorithm cannot find new columns with negative reduced cost, the column generation algorithm stops and we have obtained a lower bound for the MMLHRP.

4 Matheuristic

With the column generation algorithm presented in the previous section we are able to compute lower bounds for small sized instances in a reasonable amount of time (see Sect. 5). For medium, large, or even real-world sized instances the algorithm is not applicable, though. Due to the large amount of labels generated by the label-setting algorithm, the column generation algorithm becomes impractical in terms of both run time and memory consumption. Therefore, we substitute the label-setting algorithm with an iterated local search (ILS) algorithm to solve the subproblem (i.e. to generate negative reduced cost columns). When using the ILS algorithm to solve the subproblem, the column generation algorithm is not exact any more.

Due to the fact that it is not guaranteed that the optimal solution of the MP will be found when using the ILS algorithm, we refrain from using a branch-and-price procedure for obtaining an integer solution. Instead, we use the columns generated by the column generation algorithm for the MP to solve the problem defined by (1)–(4).

4.1 Iterated local search algorithm

ILS is a metaheuristic generating a sequence of local optima. It is an iterative method which works on an incumbent solution y and considers different neighbourhoods of y in each iteration (for an elaborate description of ILS see Lourenço et al. (2010)). A solution, in our case, is a path in $G'$ which starts at the source vertex s and ends at the sink vertex z. The pseudo code for the ILS is depicted in Algorithm 1.

We initialize the algorithm with the path (s, z) in line 1. Line 4 is the interesting part of the algorithm. First, the (current) incumbent solution is perturbed and then local search is applied to the perturbed solution. Both the Perturbation phase and the LocalSearch phase consider the following two neighbourhoods:

• 1. Insertion–adding a new request to the path

• 2. Removal–removing a request from the path

Because the dual variables from the MP are associated with the PTNs, it is likely that some arcs entering a PTN have a negative cost. Therefore, both types of moves can yield cost reductions.

In the Perturbation phase the method performs n random moves with equal probability of a move being an insertion or a removal of a request ($n=5$ in practice). In case of an insertion, we first randomly choose a request which is not yet fully served. Then, we randomly choose a corresponding PTN and a corresponding DTN. After this, we insert the PTN at a randomly chosen position in the path. We insert the DTN at the first feasible position in the path after the PTN. In case of a removal, we randomly choose a PTN in the path and remove it together with the corresponding DTN.

In the local search the method employs a steepest descent on both neighbourhoods, i.e. in each iteration we perform the move which brings the best improvement of the path cost, be it an insertion or a removal of a request. For this purpose we first calculate for all not yet fully served requests the change in the path cost incurred by inserting the corresponding PTN-DTN-pairs at every feasible position in the path. Then, we calculate for each request which is already served on the path (i.e. PTN-DTN-pair) the change in the path cost incurred by removing it from the path. Finally, we perform the move which yields the highest cost reduction. The local search stops when no improving neighbour can be found, i.e. when the change in the path cost of every feasible move is greater than or equal to zero.

In line 5 we determine if the new solution should be accepted. We use the so-called random walk as acceptance criterion, where a new local optimum is always accepted as a new incumbent solution. Furthermore, in each iteration we check if the new solution has negative reduced cost, and store it if it does (lines 8 and 9).

In line 11 we check if a stopping criterion is met. We apply the adaptive stopping criterion proposed by Cacchiani et al. (2014). It automatically adapts the number of iterations to the difficulty of the problem and works as follows: if a negative cost path has been found after n iterations, then the algorithm stops; else, the total number of iterations is increased by the factor $\psi$, in order to allocate more time to the algorithm. Additionally, it is necessary to define a total limit on the number of iterations $n_{MAX}$ which can never be exceeded. We set $n = 10$, $\psi = 10$, and $n_{MAX} = 1000$ in our implementation.

At the end of the algorithm (line 12) all paths with reduced cost within 10% of the best solution found are returned to the RMP.

4.2 Hybrid label-setting/ILS algorithm

Additionally, we implemented a hybrid version of the algorithm which combines the label-setting algorithm and the ILS (ILS/Lbl) to solve the subproblem. It starts with ILS to solve each subproblem. If ILS does not find a negative reduced cost column for at least one subproblem, we switch to the label-setting algorithm. As soon as the label-setting algorithm finds a new column we switch back to ILS. The algorithm stops when the label-setting algorithm cannot find new columns. Note that this is an exact algorithm.

5 Computational experiments

In this section, we summarize the computational experiments performed to assess both the performance of our solution method and the potential savings achievable through multimodal transport. The algorithm was implemented in C++ using CPLEX 12.7 as MIP-solver. All experiments were performed on an Intel Xeon 2.6 GHz CPU with a run time limit of 8 h. Because ILS is stochastic, we perform five runs whenever we use a subproblem algorithm involving ILS.

In the following three subsections we first present the instances which we use for the computational experiments (Sect. 5.1). In Sect. 5.2 we present computational results with respect to the performance of our solution method. Finally, in Sect. 5.3 we present managerial findings.

5.1 Test instances

We generated a set of test instances mimicking real-world long-distance transportation within and between countries along the Danube. For this purpose we created a set of customer locations and a set of transshipment locations. The set of customer locations contains 55 locations, where each location corresponds to a random address within the industrial area of a major city from the following six countries: Austria, Slovakia, Hungary, Romania, Serbia, and Bulgaria. Five locations were selected from Serbia and ten locations from each of the other countries. The set of transshipment locations contains the location of the train station in each of the selected cities as well as the locations of nine major ports along the Danube.

The pickup and the delivery location for each request are randomly selected from the set of customer locations. The demand of a request is randomly generated as well, with $d \sim U(20,1500)$ and $d \in {\mathbb {N}}$. Each instance considers a time horizon of 30 days. The time windows of a request were randomly placed within this interval. The width of each time window is either 8, 72, or 120 h, which was chosen randomly with an equal probability for each width-size. We created ten sets of requests for each of the following size categories (= number of requests): 2, 5, 10, 30, 50, 100, and 200. In order to analyse if it is beneficial to consider more transshipment locations than just the closest one for each customer, we generated from each set of requests an instance which contains only the closest train station and the closest port for each customer location (named “closest”), and another instance which contains all 64 transshipment locations (named “all”).

We consider the following vehicle types in our instances: truck, ship, push craft, barge, train, and single wagon. Trucks represent the short haul vehicles, and the rest represent the long haul vehicles. We consider ships, push crafts, trains, and single wagons as active vehicles, and barges as passive vehicles. However, we only allow push crafts to push barges. Furthermore, push crafts are special vehicles in the sense that they have no capacity ($q_k = 0$) and are only used to push barges. In the real world it is often possible that a logistics service provider attaches a single wagon to someone else’s train which travels to the desired destination train station. This is why we consider single wagons in addition to complete trains. Table 2 summarizes the parameters used for each vehicle type. All costs and parameters were determined based on real world data in collaboration with an Austrian logistics service provider.

Table 2 Parameters used in test instances

We used a travel cost of 0.73 €/km and a capacity of 20 tons for a truck in our experiments. The daily maximum operation time was assumed to be 10 h, which corresponds to the current labour regulations for commercial drivers in Austria. The distance- and travel time-matrices were calculated with the software MS MapPoint 2013. We used the following average velocities:

• Motorway: 65 km/h

• Highway: 60 km/h

• City: 20 km/h

The duration for a complete (un)loading of a truck was set to 24 min (= 50 tons/h). For both the train and the wagon we assumed a daily maximum operation time of all of the 24 h. The capacity of a wagon was set to 50 tons. An Austrian logistics service provider advised us to assume a length of 26 wagons for a train, as this was the most common length in their experience. Thus, we set the capacity of a train to 1300 tons (= 26 wagons). We used travel costs of 6.95 and 0.32 €/km for a train and a wagon, respectively. The distance matrix was constructed by using the online train-kilometre calculator http://jizdenka.idos.cz. In practice, freight trains are often time constrained due to the higher priority accorded to passenger trains. In order to avoid an over-estimation of the rail capacity, or respectively, an under-estimation of the delivery time we assumed a very low average velocity for trains of just 15 km/h, which we then used to create the travel time matrix. For a ship we assumed a daily maximum operation time of 14 h, because freight ships on the Danube typically have only one captain. For the push craft (and barge) we assumed a limit of 24 h, because they usually have two captains and can therefore be operated around the clock. The capacity of both a ship and a barge was set to 1000 tons, while a push craft has no capacity. We set the maximum number of barges a push craft may push at the same time to six, which corresponds to the smallest maximum number of barges a push craft can push along all segments of the Danube considered in our test instances. It is customary to express travel cost for water vehicles in monetary units per time unit (as opposed to per distance unit). Thus, we assumed travel cost for ships, push crafts, and barges of 43.76, 35.67, and 10.45 €/h, respectively. The travel time matrices were constructed by using the online travel time calculator http://www.danube-logistics.info/travel-time-calculator/. We assumed transshipment cost of 3 €/ton at all ports and train stations, and an (un)loading speed of 125 tons/h for all long haul vehicles.

From each of the above described instances we created 11 versions which differ with respect to the availability of long haul vehicles:

• 1. no long haul vehicles available (named “N”)

• 2. only one ship available (named “S”)

• 3. only one push craft with six barges available (named “P”)

• 4. only one train available (named “T”)

• 5. only 26 wagons available (named “G”)

• 6. the available capacity of water-bound long haul vehicles equals 30% of the total demand, no rail-bound long haul vehicles available (named “W30”)

• 7. the available capacity of rail-bound long haul vehicles equals 30% of the total demand, no water-bound long haul vehicles available (named “R30”)

• 8. the available capacity of both water-bound and rail-bound long haul vehicles each equals 30% of the total demand (named “WR30”)

• 9. no restriction on the availability of water-bound long haul vehicles, no rail-bound long haul vehicles available (named “W”)

• 10. no restriction on the availability of rail-bound long haul vehicles, no water-bound long haul vehicles available (named “R”)

• 11. no restriction on the availability of long haul vehicles (named “$\infty$”)

A sufficient number of short haul vehicles is always available in each instance in order to guarantee feasibility. In total we created 1,540 instances. We use the following naming convention for the instances: $a-b-c-d$

• $a \in \{2,5,10,30,50,100,200\}$: size category

• $b \in \{0,1,\dots ,9\}$: set of requests

• $c \in \{\text {closest},\text {all}\}$: available transshipment locations

• $d \in \{\text {N},\text {S},\text {P},\text {T},\text {G},\text {W30},\text {R30},\text {WR30},\text {W},\text {R},\infty \}$: available long haul vehicles

The wild card “$*$” refers to all instances in a category, while “[!x]” refers to all instances in a category except for “x”, e.g. “2-$*$-all-[!N]” refers to all instances of size 2, where all transshipment locations are present, and long haul vehicles are available.

All instances are available at: http://plis.univie.ac.at/research/test-instances/

5.2 Computational results

In the first set of experiments we evaluate the stability of the ILS. For that purpose we calculate for each instance the percentage gap between the objective function value of the best run and the worst run. Figure 4 shows boxplots of the percentage gaps regarding the MP solutions (Fig. 4a) and the integer solutions (Fig. 4b) for each instance size. The number in brackets under the instance names represents the total number of instances in this size category. In order to obtain a better visual representation of the boxplots we truncated the y-axis at 5 and 10%, respectively. This cut off three outliers of Fig. 4a (max. outlier = 8.34%) and ten outliers of Fig. 4b (max. outlier = 21.13%). The ILS appears to be quite stable. For more than 90% of the instances the gap between the best and the worst run is less than 1% regarding MP solutions and less than 2% regarding integer solutions. Using the hybrid ILS/Lbl algorithm decreases the gaps even further. However, due to the involvement of the label-setting algorithm we could only solve instances with up to ten requests. Because the gap is equal to 0% for more than 75% of the instances regarding both MP solutions and integer solutions, we do not present the data as boxplots but only report the minimum, average, and maximum gap for each instance size in Tables 3 and 4, respectively.

In the following, whenever results involving ILS are reported they correspond to the best of five runs regarding the objective function value, and to the worst of five runs regarding the run time. In the practical case computers have multiple cores, which means that multiple runs can be performed in parallel. Thus, we believe it reasonable to use the solution with the best objective function value, since this is obviously the solution a practitioner would implement. Furthermore, we believe it is reasonable to use the slowest run time instead of the actual run time of the run which produced the best solution, because it is only possible to determine the best solution after the slowest run has finished.

Fig. 4

Boxplots of the percentage gaps (y-axis) between the objective function value of the best run and the worst run when ILS is used as the subproblem algorithm; one boxplot for each instance size (x-axis). The numbers in brackets represent the number of instances per instance size

Table 3 Stability of the ILS/Lbl algorithm: MP solutions

Table 4 Stability of the ILS/Lbl algorithm: integer solutions

Now we evaluate the performance of the subproblem algorithms. For that purpose we solve only the linear relaxation of the problem (i.e., the MP) and then compare both the computing times and the quality of the (approximation of the) lower bound. Table 5 shows, for each subproblem algorithm, the average computing times and solution quality. The first column gives the instance names (and the number of instances in brackets). Columns CPU give the average computing time in seconds to solve an instance using the label-setting algorithm, the ILS, or the ILS/Lbl combination, respectively. Columns Min, Avg, and Max give the minimum, average, and maximum percentage gap between the objective value obtained when using the ILS (ILS/Lbl combination) and the objective value obtained when using the label-setting algorithm. The ILS performs well in terms of both run time and solution quality. For all instance sizes the average gap is close to 0% and the average computation time is only a fraction of the computation time of the label-setting algorithm. The negative gap in the last row is explained by the fact that the label-setting algorithm could not solve 19 of the instances of size 10 within the run time limit. The ILS and the ILS/Lbl combination found better solutions for 13, respectively 15, of those instances.

Table 5 Comparison: computing times and solution quality

We now evaluate the impact of the width of the time windows and the length of the time horizon on the performance of the subproblem algorithms. For that purpose we created new instances based on the $\infty$-instances. We kept everything the same except the width of the time windows, the position of the time windows, and the length of the time horizon. In each new instance all time windows have the same length. In total we created six new versions from each $\infty$-instance: one version where the width of the time windows is equal to 8, 120, and 240 h, respectively; combined with a length of the time horizon of 30 and 60 days. We again solve only the MP and then compare the computing times. Tables 6, 7, and 8 show, for each subproblem algorithm, the average computing times in seconds. Columns 30 day period and 60 day period give the average computing time to solve the MP for instances with a time horizon of 30 and 60 days, respectively. Columns 8h, 120h, and 240h refer to instances where each time window has a width of 8, 120 and 240 h, respectively. Wider time windows and longer time horizons correlate with larger solutions spaces. Therefore, it is not surprising that both the width of the time windows and the length of the time horizon have a considerable impact on the performance of all three subproblem algorithms. What is interesting, however, is that the width of the time windows has a noticeably larger impact on the label-setting algorithm than on the ILS, while for the length of the time horizon it is the other way around. An increase of the time window width from 8 to 120 h, from 120 to 240 h, and from 8 to 240 h, results in 3.8, 1.9, and 9.0 times longer computation times on average for the label-setting algorithm. For the ILS the computation times increase by a factor of only 1.8, 1.4, and 2.5 on average, respectively, for the same increases of the time window width. The computation times of the hybrid ILS/Lbl-setting algorithm increase by a factor of 3.3, 2.5, and 12.1 on average, respectively. Increasing the time horizon from 30 to 60 days almost doubles the run time on average for the label-setting algorithm and the ILS/Lbl-setting algorithm, while it more than doubles the run time on average for the ILS. If we consider all seven size categories of the instances (not just the smallest three), then the run time of the ILS almost triples on average.

Table 6 Label-setting: impact time window width and period length

Table 7 ILS: impact time window width and period length

Table 8 ILS/Lbl-setting: impact time window width and period length

In the following, all analyses compare only integer solutions and are based on results obtained with ILS as the subproblem algorithm.

5.3 Managerial discussion

Now we address the question of whether it can be beneficial to consider more potential transshipment locations than just the closest one of each customer. For that purpose we compare the objective function values of the solutions of the “closest” instances with the “all” instances. Table 9 gives the average and maximum percentage gap between those solutions, whereby the solution values of the “closest” instances are the reference values. For all instance sizes, the solutions where all transshipment locations are considered are on average less than 0.25% better. The maximum difference of $\sim$7.5% is achieved at an instance of size 10 and decreases to less than 1% for larger instances. However, this is to be expected as the number of additional ‘non-closest’ transshipment locations decreases with an increasing number of requests. Table 9 also shows that on average the number of requests transshipped at a location which is not the closest one is less than one. Additionally, Table 9 shows that the moderate decrease in costs is achieved through a comparatively large increase in computation time. It takes on average 2–3 times longer to solve larger instances which contain all transshipment locations.

The negative value of the average percentage gap for instances of size 100 can be explained as follows. In general, given two sets of columns, A and B, it is possible that set A yields a better LP solution than set B, but a worse integer solution than set B. This is what happens here. For some “all” instances, the column generation approach produces a set of columns that yields a better LP solution than the set of columns produced for the corresponding “closest” instance, but a worse integer solution.

Table 9 Comparison: “closest”–“all”

We now evaluate the increase in the delivery time of a request when it is transported multimodally compared to unimodally. For that purpose, we compare for each request its delivery times in the solutions of the different vehicle availabilities. Table 10 shows the average percentage increase of the delivery time of a request for selected multimodal cases compared to the unimodal case. In order to be able to make comparisons between the different vehicle types, Table 10 only includes requests which are transported by a long haul vehicle in every multimodal case. The delivery time of requests which are transported by a ship increases by roughly 86% on average compared to when they are delivered by a direct unimodal transport. Using a push craft the delivery time increases only by 64% on average. The smaller increase of the delivery time by a push craft is because it can operate 24 h per day as opposed to the ship which can only operate for 14 h per day. Looking at trains and single wagons, the table shows that both cause an even smaller average increase in delivery time; namely $\sim$55 and $\sim$62%. In general, water transportation causes an average increase in the delivery time roughly 1.3 times larger than rail transportation (see “W” vs. “R”).

Table 10 Average delivery time increase: unimodal–multimodal

We now want to determine the potential cost savings through multimodal transport. For that purpose we compare, for each set of requests, the objective function values of the solutions of the different vehicle availabilities. Table 11 presents the average percentage cost reduction for each of the ten multimodal cases compared to the unimodal case ($*$-$*$-$*$-N). Using a single ship leads to a cost reduction of roughly 7% on average. With a single push craft (and six barges) the cost reduction can be doubled, which is, of course, a direct consequence of the larger capacity. Both a single train and 26 wagons achieve an even larger decrease in costs, with savings of $\sim$20 and $\sim$26%, respectively.

Furthermore, rail transportation achieves average cost reductions more than twice as high as water transportation (see “W30” vs. “R30” and “W” vs. “R”). This large difference in potential cost savings is partially due to time restrictions: water transportation is slower than rail transportation (see Table 10). Also, for most customer locations the closest port is further away than the closest train station, which increases the travel time in the first- and last-mile. Therefore, because of time windows, some requests cannot be transported by water, but can be transported by rail. Furthermore, the larger distance to the next port not only increases the travel time of the short haul, but also its cost. Thus, for some requests it is not worthwhile to transport them by water, due to the high short haul costs, while it is worthwhile with rail transportation. On average, 98.1% of requests (or 98.4% of total demand) may be transported by rail in each of our instances, while only 71.7% of requests (or 71.3% of total demand) may be transported by water. The remaining 1.9% (1.6%), respectively 28.3% (28.7%), can or should not be transported by rail, respectively water, because of time restrictions or too large short haul costs.

Table 11 shows further that when there is no restriction on the amount of available long haul vehicles, cost reductions of more than 50% can be achieved. However, almost identical cost savings can be achieved when there is no restriction on the availability of rail-bound long haul vehicles (see “R”). The same conformity in cost reductions can be observed between “R30” and “WR30”. Water transportation, it seems, is only of interest if rail transportation is not possible. Table 12 provides further insights on this issue. It shows, for cases “R30”, “WR30”, “R”, and “$\infty$”, the proportion of the total demand which is transported on each mode of transportation. Rail transportation accounts, on average, for more than two-thirds of the total demand transported on the long haul, while water transportation amounts to only 2.4–3.4%. In fact, facilitating water transportation in addition to rail transportation leads to only a slight increase (“R30” vs. “WR30”) or even no increase at all (“R” vs. “$\infty$”) of the amount of demand transported in a multimodal fashion.

Table 11 Average cost reduction: unimodal–multimodal

Table 12 Transportation mode and long haul vehicle type split

Tables 11 and 12 additionally show that wagons are heavily used and have a large impact on costs in the above presented solutions. Using wagons in the way we propose relies on a strong assumption. Attaching a single wagon to someone else’s train which travels to the desired destination train station might in fact not be possible in some real world cases, at least not all the time. Therefore, we reran all experiments again without the possibility of using wagons. Table 13 presents again the average percentage cost reduction for the multimodal cases compared to the unimodal case, but without the usage of wagons in cases “R30”, “WR30”, “R”, and “$\infty$”. The average cost reductions decrease by roughly five percentage points in all four cases. The level of conformity in cost reductions between “R30” and “WR30”, as well as between “R” and “$\infty$, stays the same, though. Regarding the proportions of total demand transported on each mode of transportation, Table 14 shows that there is only a slight shift towards water transportation. The majority of the demand previously transported by wagons is now covered by trains. Nonetheless, this shift constitutes a doubling of water transportation. Approximately 5% of total demand cannot be absorbed by any other long haul vehicle and is, therefore, transported by road.

Table 13 Average cost reduction (without wagons): unimodal–multimodal

Table 14 Transportation mode and long haul vehicle type split (without wagons)

6 Conclusion

In this article we present a new problem called the multimodal long haul routing problem (MMLHRP). We propose both an arc flow formulation and a set-covering formulation for this problem. For the set-covering formulation we further propose a column generation algorithm to solve its linear relaxation, i.e., to obtain lower bounds. We solve the subproblem in this approach with both a label-setting algorithm and an ILS. In order to obtain feasible integer solutions we propose a matheuristic which is based on the column generation framework. Computational experiments show that the ILS as the subproblem algorithm performs well compared to the label-setting algorithm. Indeed, using ILS as the subproblem algorithm made the MMLHRP tractable for large instances.

Additional computational experiments show that it is not beneficial to consider more transshipment locations than just the closest one of a customer. Furthermore, we find that considerable cost reductions can be achieved through multimodal transport compared to unimodal transport. In our computational studies, cost reductions of more than 50% could be achieved in the most extreme cases, depending on both the number of requests and the number of available long haul vehicles. The experiments further show that water transportation hardly contributes in terms of both transported demand and cost reductions if rail transportation is available as well. In general, rail transportation achieves average cost reductions more than twice as high as water transportation.

Further research regarding the investigated problem may analyse the cost of the introduced policies and assumptions which aim at generating more practical solutions. Allowing a unit of load to use several long haul vehicles in succession is likely to further reduce overall costs. The same is true for not regulating the number of splits. Indeed, the solutions will probably not be as practical, but the trade-off might be worth it. Another interesting research direction would be to consider an additional “green” objective, such as minimizing $CO_2$ emissions. Especially in multimodal vehicle routing, minimizing costs and minimizing emissions of pollutants are conflicting objectives. For example, trucks typically have significantly higher routing costs than ships but are at the same time significantly less polluting than ships.

Appendix 1: Arc flow formulation

The MMLHRP can be modelled by means of an arc flow formulation using the following variables:

$$\begin{aligned} s_{ik} \quad&\text { Start time of service of vehicle } k \in K \text { at node } i \in V \\ z_{ik} \quad&\text { Number of rests of vehicle } k \in K \text { until node } i \in V \\ \nu _{ik} \quad&\text { Sum of travel- and service times of vehicle } k \in K \\&\text { until node } i \in V \\ f_{ijrk} \quad&\text { Amount of request } r \in R \text { transported by vehicle } k \in K \\&\text { over arc } (i,j) \in A \\ w_{irkk'} \quad&\text { Amount of request } r \in R \text { transshipped from vehicle } k \in K \\&\text { to vehicle } k' \in K \text { at node } i \in \overline{T} \\ \sigma _{ik} \quad&\text { Service time of vehicle } k \in K \text { at node } i \in V \\ x_{ijk} \quad&{\left\{ \begin{array}{ll} \text {1 ~iff vehicle } k \in K \text { traverses arc } (i,j) \in A \\ \text {0 ~otherwise} \end{array}\right. } \\ y_{irkk'} \quad&{\left\{ \begin{array}{ll} \text {1 ~iff request } r \in R \text { is transshipped from vehicle } k \in K \\ \text { ~~to vehicle } k' \in K \text { at node } i \in \overline{T} \\ \text {0 ~otherwise} \end{array}\right. } \\ \alpha _{ijkk'} \quad&{\left\{ \begin{array}{ll} \text {1 ~iff active vehilce } k \in C \text { pushes passive vehicle } k' \in E \text { over arc } (i,j) \in A \\ \text {0 ~otherwise} \end{array}\right. } \end{aligned}$$

Tables 15 and 16 provide a summary of the used notation.

Table 15 Sets for the arc flow formulation

Table 16 Parameters for the arc flow formulation

For modelling purposes we define for variables x, f, and $\alpha$:

$x_k(F) \equiv \sum \nolimits _{(i,j) \in F} x_{ijk}$, $f_{rk}(F) \equiv \sum \nolimits _{(i,j) \in F} f_{ijrk}$, and $\alpha _{kk'}(F) \equiv \sum \nolimits _{(i,j) \in F} \alpha _{ijkk'}$

With the above notation the MMLHRP can be formulated as follows:

$$\begin{aligned} \min ~ \sum _{i \in V} \sum _{j \in V} \sum _{k \in K} c_{ijk} x_{ijk} + \sum _{i \in \overline{T}} \sum _{r \in R} \sum _{k \in K} \sum _{k' \in K} m_i w_{irkk'} \end{aligned}$$

(24)

subject to

$$\begin{aligned} \sum _{k \in K} f_{rk}(\delta _k^+(r^+)) = \sum _{k \in K} f_{rk}(\delta _k^-(r^-)) = d_r& \quad \forall r \in R \end{aligned}$$

(25)

$$\begin{aligned} x_k(\delta ^+_k(o_k)) = x_k(\delta ^-_k(\eta _k)) = 1& \quad \forall k \in K {\setminus } B \end{aligned}$$

(26)

$$\begin{aligned} x_k(\delta ^+_k(i)) - x_k(\delta ^-_k(i)) = 0& \quad \forall i \in \overline{T}, \quad \forall k \in K {\setminus } B \end{aligned}$$

(27)

$$\begin{aligned} \sum _{k \in K} f_{rk}(\delta _k^+(i)) - \sum _{k \in K} f_{rk}(\delta _k^-(i)) = 0& \quad \forall i \in \overline{T}, \forall r \in R \end{aligned}$$

(28)

$$\begin{aligned} \nu _{jk} \ge \nu _{ik} + \sigma _{ik} + t_{ijk} - M(1 - x_{ijk}) \quad \forall (i,j) \in A^k, \forall k \in K \end{aligned}$$

(29)

$$\begin{aligned} z_{ik} \ge \frac{\nu _{ik}}{e_k} \quad \forall i \in V, \forall k \in K \end{aligned}$$

(30)

$$\begin{aligned} s_{ik} \ge \nu _{ik} + (g_k z_{ik})\quad \forall i \in V, \forall k \in K \end{aligned}$$

(31)

$$\begin{aligned} s_{jk} \ge s_{ik} + t_{ijk} + (g_k z_{jk} - g_k z_{ik}) + \sigma _{ik} - M (1 - x_{ijk})\quad \forall (i,j) \in A^k, \forall k \in K \end{aligned}$$

(32)

$$\begin{aligned} \sum _{r \in R} f_{ijrk} \le q_k x_{ijk}\quad \forall (i,j) \in A^k, \forall k \in K \end{aligned}$$

(33)

$$\begin{aligned} s_{ik} + \sigma _{ik} - M(1 - y_{irkk'}) \le s_{ik'}\quad \forall i \in \overline{T}, \forall r \in R, \forall k,k' \in K \end{aligned}$$

(34)

$$\begin{aligned} \sum _{r \in R} w_{irkk'} \le min\{q_k, q_k'\} \cdot y_{irkk'}\quad \forall i \in \overline{T}, \forall k,k' \in K\end{aligned}$$

(35)

$$\begin{aligned} f_{rk}(\delta _k^+(i)) = f_{rk}(\delta _k^-(i)) + \sum _{k' \in K} w_{irk'k} - \sum _{k' \in K} w_{irkk'}\quad \forall i \in \overline{T}, \forall r \in R, \forall k \in K \end{aligned}$$

(36)

$$\begin{aligned} \sigma _{ik} \ge \sum _{r \in R} \sum _{k' \in K}(w_{irkk'} + w_{irk'k}) h_{ik}\quad \forall i \in \overline{T}, \forall k \in K \end{aligned}$$

(37)

$$\begin{aligned} \sigma _{r^+,k} \ge f_{rk}(\delta _k^+(r^+)) h_{r^+,k}\quad \forall r \in R, \forall k \in B \end{aligned}$$

(38)

$$\begin{aligned} \sigma _{r^-,k} \ge f_{rk}(\delta _k^-(r^-)) h_{r^-,k}\quad \forall r \in R, \forall k \in B \end{aligned}$$

(39)

$$\begin{aligned} a_i \le s_{ik} \le b_i\quad \forall i \in P \cup D \cup \{o_k, \eta _k\}, \forall k \in K \end{aligned}$$

(40)

$$\begin{aligned} x_{ijk} = \sum _{k \in C} \alpha _{ijkk'}\quad \forall (i,j) \in A^{k'}, \forall k' \in E \end{aligned}$$

(41)

$$\begin{aligned} \sum _{k' \in E} \alpha _{ijkk'} \le x_{ijk} u\quad \forall (i,j) \in A^k, \forall k \in C \end{aligned}$$

(42)

$$\begin{aligned} s_{jk} - s_{jp} \le M(1 - \alpha _{ijkk'})\quad \forall (i,j) \in A^k, \forall k \in C, \forall k' \in E \end{aligned}$$

(43)

$$\begin{aligned} s_{jp} - s_{jk} \le M(1 - \alpha _{ijkk'})\quad \forall (i,j) \in A^k, \forall k \in C, \forall k' \in E \end{aligned}$$

(44)

$$\begin{aligned} x_{k+1}(\delta _k^+(o_k)) \le x_k(\delta _k^+(o_k))\quad \forall k \in B {\setminus } \{|B|\} \end{aligned}$$

(45)

$$\begin{aligned} x_{k+1}(\delta _k^+(o_k)) \le x_k(\delta _k^+(o_k))\quad \forall k \in C {\setminus } \{|C|\} \end{aligned}$$

(46)

$$\begin{aligned} x_{k+1}(\delta _k^+(o_k)) \le x_k(\delta _k^+(o_k))\quad \forall k \in E {\setminus } \{|E|\} \end{aligned}$$

(47)

$$\begin{aligned} x_k(\delta _k^-(i'+1)) \le x_k(\delta _k^-(i'))\quad \forall i \in T, \forall i' \in T'(i) {\setminus } \{|T'(i)|\}, \forall k \in C \end{aligned}$$

(48)

$$\begin{aligned} s_{ik} \in {\mathbb {R^+}}\quad \forall i \in V, \forall k \in K \end{aligned}$$

(49)

$$\begin{aligned} z_{ik} \in {\mathbb {N}}\quad \forall i \in V, \forall k \in K \end{aligned}$$

(50)

$$\begin{aligned} \nu _{ik} \in {\mathbb {R^+}}\quad \forall i \in V, \forall k \in K \end{aligned}$$

(51)

$$\begin{aligned} \sigma _{ik} \in {\mathbb {R^+}}\quad \forall i \in V, \forall k \in K \end{aligned}$$

(52)

$$\begin{aligned} x_{ijk} \in \{0,1\}\quad \forall (i,j) \in A^k, \forall k \in K \end{aligned}$$

(53)

$$\begin{aligned} f_{ijrk} \in {\mathbb {R^+}}\quad \forall (i,j) \in A^k, \forall k \in K, \forall r \in R \end{aligned}$$

(54)

$$\begin{aligned} w_{irkk'} \in {\mathbb {R^+}}\quad \forall i \in \overline{T}, \forall r \in R, \forall k,k' \in K \end{aligned}$$

(55)

$$\begin{aligned} y_{irkk'} \in \{0,1\}\quad \forall \ i \in \overline{T}, \forall r \in R, \forall k,k' \in K \end{aligned}$$

(56)

$$\begin{aligned} \alpha _{ijkk'} \in \{0,1\}\quad \forall \ (i,j) \in A^k, \forall k \in C, \forall k' \in E \end{aligned}$$

(57)

The objective function (24) aims at minimizing the total cost. Constraints (25) guarantee that every request is fully satisfied. Constraints (26) make sure, that every long haul vehicle leaves its start depot and returns to its end depot. This constraint is not necessary for short haul vehicles, since we only consider trips where a short haul vehicle carries load. Constraints (27) guarantee the flow conservation of long haul vehicles. Again, this constraint is not necessary for short haul vehicles, because we are not looking for a path for short haul vehicles but for single trips (which correspond to single arcs). Constraints (28) make sure that the same amount of load of a request which arrives at a transshipment node also leaves the transshipment node. Constraints (29)–(32) keep track of time and guarantee that a vehicle never exceeds the amount of hours per day it is allowed to operate. Constraints (29) keep track of the sum of travel- and service times of a vehicle until a node, while constraints (30) determine the number of rests a vehicle has to make until a node based on this sum. Constraints (31) determine the arrival time of a vehicle at a node. Finally, constraints (32) together with constraints (31) keep track of time overall by determining the start time of service of a vehicle at a node, taking the travel-, service-, and rest-times until this node into account. Constraints (33) ensure that the capacity of a vehicle is never exceeded. Constraints (34) ensure time synchronization at transshipment. That is, the vehicle receiving load must start its service after the vehicle giving the load. Constraints (35) guarantee that the amount transferred from one vehicle to another does not exceed the capacity of either vehicle. Constraints (36) make sure that a vehicle leaves a transshipment node with the same amount of a request it arrived with, plus the amount of the request it received from other vehicles, minus the amount it gave to other vehicles. Constraints (37)–(39) determine the service time at each node. Constraints (40) ensure that the time windows are respected. Constraints (41) guarantee that a passive vehicle never moves on its own, but always together with an active vehicle. Constraints (42) ensure that the maximum number of passive vehicles per active vehicle is never exceeded. Constraints (43)–(44) regulate time synchronization between active and passive vehicles. Constraints (45)–(47) break the symmetry in the model with respect to the vehicles. Constraints (48) break the symmetry in the model with respect to the node duplicates of transfer locations. Constraints (49)–(57) give the domain of the decision variables.