Keywords

1 Introduction

Transportation of goods and people via different inland waterways such as rivers, lakes and canals, is commonly referred as Inland Waterway Transport (IWT). Compared to road and railway transportation, IWT offers competitive advantages including lower transportation costs, reduced greenhouse gas emissions as well as noise pollution [1]. For this reason, more and more transportation stakeholders want to increase the share of water transportation in their operations. According to the Port of Rotterdam, a total of 100,000 inland barges arrived in 2019 [2]. To handle the subsequent container flows in the future, the Port of Rotterdam aims to raise the utilization of waterborne transport to have the largest modal share over the next 20 years [3]. The EU Transport White Paper (European Commission, 2011) targeted for freight transport to shift from road to rail and IWT by more than 50% by 2050 [4].

Barge operators are the key carriers when it comes to IWT and they usually work with fixed timetables [5]. However, it might be beneficial to adapt the routes during operations, e.g., serve a new transportation request halfway, in order to reduce costs and/or serve additional requests. In this situation, the optimization problem for the barge carrier/operator can be regarded as a pickup and delivery problem (PDP) [6], especially for big transportation companies, that operate over multiple terminals in a river. A representative example of such a company is Contargo [7], which operates barges in the Rhine-Alpine corridor.

In transport operations, it is shown that the shipment of goods to an intermediate destination before they reach their intended destination (i.e., transshipment) can reduce costs and emissions [8, 9]. In case of IWT, one barge drives the request to a predetermined terminal, called transshipment terminal. The second barge picks up the request at the transshipment terminal and transports it to the delivery terminal. In this way, several requests can share a barge as long as capacity is not exceeded, the number of used barges can be minimized and the capacity of barges is utilized better. A real-world example is shown in Sect. 3. To the best of our knowledge, no study focused on the PDP with transshipment for intermodal freight transportation involving IWT. Moreover, most barge operators adopt the fixed timetable and routes for barges, which may lead to loss of flexibility. In this paper, the flexible barges, i.e., barges without predefined timetable and routes, are considered.

In this paper, we study the PDP with transshipment over an intermodal transportation network including inland waterways. To formulate this optimization problem, we propose a Mixed Integer Programming (MIP) model. The objective is to determine the routes of barges that minimize the overall cost, under several practical constraints that realize the transshipment between barges. Given that for real size networks, the studied problem cannot be solved to optimality in reasonable times, we additionally propose an adaptive large neighborhood search algorithm. Based on real-world data including barge timetables and technical specifications (speed profiles, capacities), a series of instances with different sizes and diverse characteristics are generated. An extensive experimental evaluation is conducted that demonstrates the efficiency of the proposed approach under various configurations and across different problem instances.

The remainder of this paper is structured as follows: Sect. 2 presents a brief literature review. The proposed MIP model is described in Sect. 3, while the solution methodology is given in Sect. 4. The experimental settings and results are reported in Sect. 5. The paper concludes and provides directions for future research in Sect. 6.

2 Literature Review

In this section, we briefly review the literature related to the role of transshipment in transportation. Also, we outline several research studies that investigate the use of inland barges in waterway transport operations, including transport routes optimization and service network optimization.

2.1 Transshipment in Transportation Domain

Transshipment is a common practice in various transportation operations and considered in various modeling approaches, including vehicle routing problem with trailers and transshipment (VRPTT), vehicle routing problem with cross-docking (VRPCD), and pickup and delivery problem with transshipment (PDPT).

The VRPTT considers a set of non-autonomous vehicles (trailers), which can only move when pulled by a lorry [10]. In the VRPTT, the trailers can be parked at transshipment locations, where the load is transferred from lorries to trailers. The VRPCD is concerned with defining a set of routes that satisfy transportation requests among different pickup and delivery points. In the VRPCD, the vehicles bring goods from pickup locations to a cross-docking platform, where the items may be consolidated for efficient delivery [11]. The PDPT is a variant of the PDP, where requests can change vehicle at transshipment points during their trip [12]. In the PDP, the pickup and delivery points of a request should be serviced by the same vehicle. By relaxing related constraints, a request can be transported by more than one vehicle. There is a common characteristic in the above problems due to transshipment: synchronization among different vehicles. These problems are Vehicle Routing Problems (VRPs) which exhibit additional synchronization requirements with regard to spatial, temporal, and load aspects [9]. The model proposed in this paper belongs to PDPT.

Some studies proposed heuristics to reduce computation time. To determine the benefits of transshipment in a daily route planning problem at a regional air carrier, a greedy randomized adaptive search procedure (GRASP) was developed to find optimal routes efficiently [14]. A branch-and-price algorithm was proposed for the VRPTT, using problem specific enhancements in the pricing scheme and alternative lower bound computations [15]. In this study, an adaptive large neighborhood search (ALNS) algorithm was additionally used to obtain good initial columns. To solve PDPT efficiently, a heuristic capable of efficiently inserting requests through transfer points was proposed and it was embedded into an ALNS algorithm [12].

Besides freight transportation, some scholars solve similar problems in passenger transportation. For example, a pickup and delivery problem with transfers is formulated and the proposed model is applied to passenger transport [13]. There are three differences between the approach in [13] and this research: a) From the mathematical model perspective, the transfer node in [13] is regarded as two separate nodes (start node and finish node) to model the transshipment. In this research, vehicle flow and request flow are modeled to achieve container transshipment between barges. b) From the solution methodology perspective, a branch-and-cut solution method is used in [13] and there are up to 6 requests, 2 vehicles, and 2 transshipment terminals. In this research, ALNS is used to improve the scalability so that large instances can be handled. c) From the application perspective, the model in [13] and the model proposed in this research are applied to passenger transport and IWT separately, and different transport characteristics are considered. For example, this research takes upstream/downstream speed into account.

2.2 Optimization Challenges for Inland Barges

Barge route optimization is mainly studied by focusing on the waterway transport itself. The optimal values of parameters, which influence the efficient utilization of barges, were investigated in [16]. Several years later, the barge routing problem was studied with the objective of maximizing the profit for a shipping company [17]. In the same study, the upstream and downstream calling sequence as well as the number of loaded and empty containers were also determined. To generate rotation plans for inland barges, an approach was developed on the integration of mixed-integer programming (MIP) and constraint programming (CP) [18]. To address long waiting times and congestion of inland barges in the port, a two-phase approach for planning inter-terminal transport of inland barges was proposed in the presence of several practical constraints [3].

Table 1. Comparison on models in literature.
Full size table

The service network design for barges can be related to intermodal transport. The relations between barge network design, transport market, and the performance of intermodal barge transport is typically the central issue [19]. A general framework that describes design variables of barge networks and identifies their connection to the performance indicators of intermodal barge transport is presented in [20]. There are additional studies on the service network of barges that consider regional characteristics. A hub-and-spoke network was designed for a shipping company that is consistent with the characteristics of the Yangtze River [21]. The subset of ports needs to be called and the amount of containers need to be shipped are determined in [22]. In order to save possible leasing or storage costs of empty containers at the respective ports, the repositioning of empty containers is explored in [22].

Although the VRP with transshipment and waterway transport optimization are well studied, only a few research studies have been devoted to the VRP with barges, and the benefits of transshipment have been rarely exploited. Table 1 provides a detailed comparison among different studies of the relevant literature considering several aspects.

3 Optimization Model for Inland Barges

We formulate the optimization problem for the barge carrier as a PDPT. Compared with traditional modelling approaches for barges, such as network flow optimization, the proposed model can reduce the cost due to its flexibility and transshipment benefits, as in Fig. 1. In Fig. 1a, a barge named Nova picks up two requests (0 and 1) at Antwerp, then delivers request 1 and picks up request 2 at Rotterdam, finally deliveries requests 0 and 2 at Neuss terminal. If the barge Nova has a fixed shuttle from Antwerp to Neuss, requests 1 and 2 can only be served by other barges, a choice that induces unnecessary costs. In Fig. 1b, request 0 needs to be transported from Frankfurt-Ost terminal to Rotterdam, and request 1 needs to be transported from Mannheim terminal to Rotterdam. As they share the same route segment, request 1 is transferred from barge Michigan to barge So Long at transshipment terminal Koblenz, which avoids extra travel for Michigan and makes full use of So Long’s capacity.

The proposed model allows containers to be transferred from one barge to another at transshipment terminals, as shown in Fig. 2. Therefore, different from traditional PDP, the routes of requests and routes of barges need to be considered separately.

Fig. 1.
figure 1

Illustration of the flexibility and transshipment of the model.

Full size image

The loading/unloading time is called service time for pickup/delivery, and it is called transshipment time in case of transshipment. Figure 2 also shows how the time is added in the model. The time from the arrival time till the service start time is the waiting time, and departure happens after service time or transshipment time is completed. There are three situations that lead to waiting time. The first one is when the barge arrives before the pickup/delivery time window, and so needs to wait for containers. The other two situations take place in the transshipment terminal. Assuming barge l will pickup containers and barge k will deliver containers at transshipment terminal. The second situation is that barge l arrives at the transshipment terminal before barge k completes the unloading, and l needs to wait for k. The last situation is that barge k arrives before barge l, and k needs to wait for l. For the first and second situations, the waiting time is necessary. For the last situation, as the reviewer suggested, barge k can unload container directly and doesn’t need to wait for barge l. However, this paper doesn’t consider the storage in the terminals, and the waiting time is used. Figure 2 shows the first and second situations.

Fig. 2.
figure 2

Transshipment and time in the model.

Full size image
Table 2. Notation used in the model.
Full size table

The notation used in the mathematical model is provided in Table 2. A request consists of pickup and delivery time windows, and number of containers (TEU). The barge set includes barges’ name, capacity, and speed. Terminals and arcs form the transport network of the carrier or barge operator. In the terminal set, there are some special terminals, including transshipment terminals, initial/final depots of barges and pickup/delivery terminals of requests. Each barge may start from different depot.

The objective of the model is to minimize cost, which consists of transportation cost of containers, fuel cost, transshipment cost, and cost associated with waiting, service, and transshipment time, defined as follows:

$$\begin{aligned} \begin{aligned}&Minimize \text { } F = \sum _{k \in K} \sum _{(i,j) \in A} \sum _{r \in R} (c_k^1 d_{ij}+c_k^2 \tau _{ij}) y_{ij}^{kr} q_r\\ {}&+\, \sum _{k \in K} \sum _{(i,j) \in A} (c_k^3 d_{ij} x_{ij}^{k} + c_k^4 (\overline{t}_i^k - t_i^k)) + \sum _{k,l \in K, k\ne l} \sum _{r \in R}\sum _{i \in T} c_k^5 q_r s_{ir}^{kl} \end{aligned} \end{aligned}$$
(1)

Subject to:

$$\begin{aligned}&\sum \limits _{j \in N} x_{ij}^{k} \leqslant 1 \quad \forall k \in K,\text { }\forall i = o(k)&\end{aligned}$$
(2)
$$\begin{aligned}&\sum \limits _{j \in N} x_{ij}^{k} = \sum \limits _{j \in N} x_{jl}^{k} \quad \forall k \in K,\text { }\forall i = o(k), \text { }\forall l=o'(k)&\end{aligned}$$
(3)
$$\begin{aligned}&\sum \limits _{k \in K}\sum \limits _{j \in N} y_{ij}^{kr}=1 \quad \forall r \in R, \text { } \forall i=p(r)&\end{aligned}$$
(4)
$$\begin{aligned}&\sum \limits _{k \in K}\sum \limits _{j \in N} y_{ji}^{kr}=1 \quad \forall r \in R, \text { } \forall i=d(r)&\end{aligned}$$
(5)
$$\begin{aligned}&\sum \limits _{j \in N} x_{ij}^{k} - \sum \limits _{j \in N} x_{ji}^{k}=0 \quad \forall k \in K, \text { } \forall i \in N\setminus {o(k),o'(k)}&\end{aligned}$$
(6)
$$\begin{aligned}&\sum \limits _{k \in K}\sum \limits _{j \in N} y_{ij}^{kr} - \sum \limits _{k \in K}\sum \limits _{j \in N} y_{ji}^{kr} = 0 \quad \forall r \in R, \text { } \forall i \in T \setminus p(r), d(r)&\end{aligned}$$
(7)
$$\begin{aligned}&\sum \limits _{j \in N} y_{ij}^{kr} - \sum \limits _{j \in N} y_{ji}^{kr} = 0 \quad \forall k \in K, \text { } \forall r \in R, \text { } \forall i \in N\setminus T, p(r), d(r)&\end{aligned}$$
(8)
$$\begin{aligned}&y_{ij}^{kr} \leqslant x_{ij}^{k} \quad \forall (i,j) \in A,\text { } \forall k \in K,\text { } \forall r \in R&\end{aligned}$$
(9)
$$\begin{aligned}&\sum \limits _{j \in N} y_{ji}^{kr} + \sum \limits _{j \in N} y_{ij}^{lr} \leqslant s_{ir}^{kl} +1 \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K,\text { } k \ne l&\end{aligned}$$
(10)
$$\begin{aligned}&s_{ir}^{kl} \leqslant \sum \limits _{j \in N}y_{ji}^{kr} \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K,\text { } k \ne l&\end{aligned}$$
(11)
$$\begin{aligned}&s_{ir}^{kl} \leqslant \sum \limits _{j \in N} y_{ij}^{lr} \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K,\text { } k \ne l&\end{aligned}$$
(12)
$$\begin{aligned}&t_i^k \leqslant {t'}_i^k \quad \forall i \in N, \text { } \forall k \in K&\end{aligned}$$
(13)
$$\begin{aligned}&{t'}_i^k \leqslant \overline{t}_i^k \quad \forall i \in N, \text { } \forall k \in K&\end{aligned}$$
(14)
$$\begin{aligned}&\overline{t}_i^k+\tau _{ij}^k-t_j^k \leqslant M(1-x_{ij}^{k}) \quad \forall (i,j) \in A, \text { } \forall k \in K&\end{aligned}$$
(15)
$$\begin{aligned}&a_{p(r)}\leqslant {t'}_{p(r)}^k,\text { } \overline{t}_{p(r)}^k \leqslant b_{p(r)} \quad \forall r \in R, \text { } \forall k \in K&\end{aligned}$$
(16)
$$\begin{aligned}&a_{d(r)}\leqslant {t'}_{d(r)}^k,\text { } \overline{t}_{d(r)}^k \leqslant b_{d(r)} \quad \forall r \in R, \text { } \forall k \in K&\end{aligned}$$
(17)
$$\begin{aligned}&{t'}_{p(r)/d(r)}^k + {t'''}_{p(r)/d(r)}^k = \overline{t}_{p(r)/d(r)}^k \quad \forall r \in R, \text { } \forall k \in K&\end{aligned}$$
(18)
$$\begin{aligned}&\overline{t}_i^k-{t'}_i^l \leqslant M(1-s_{ir}^{kl}) \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K, \text { } k \ne l&\end{aligned}$$
(19)
$$\begin{aligned}&\overline{t}_i^k - {t'}_i^k = {t''}_i^k s_{ir}^{kl} \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K, \text { } k \ne l&\end{aligned}$$
(20)
$$\begin{aligned}&\overline{t}_i^l - {t'}_i^l = {t''}_i^k s_{ir}^{kl} \quad \forall r \in R, \text { } \forall i \in T, \text { } \forall k,l \in K, \text { } k \ne l&\end{aligned}$$
(21)
$$\begin{aligned}&x_{ij}^{k} \leqslant z_{ij}^{k} \quad \forall i,j \in N,\text { } \forall k \in K&\end{aligned}$$
(22)
$$\begin{aligned}&z_{ij}^{k}+z_{ji}^{k}=1\quad \forall i,j \in N,\text { } \forall k \in K&\end{aligned}$$
(23)
$$\begin{aligned}&z_{ij}^{k}+z_{jl}^{k}+z_{li}^{k} \leqslant 2 \quad \forall i,j,l \in N,\text { } \forall k \in K&\end{aligned}$$
(24)
$$\begin{aligned}&\sum \limits _{r \in R}q_r y_{ij}^{kr} \leqslant u_k x_{ij}^{k} \quad \forall (i,j) \in A,\text { } \forall k \in K&\end{aligned}$$
(25)
$$\begin{aligned}&x_{ij}^{k} \in \{0,1\} \quad \forall (i,j) \in A,\text { } \forall k \in K&\end{aligned}$$
(26)
$$\begin{aligned}&y_{ij}^{kr} \in \{0,1\} \quad \forall (i,j) \in A,\text { } \forall k \in K, \text { } \forall r \in R&\end{aligned}$$
(27)

Constraints (2) and (3) ensure that a barge begins and ends at its begin and end depot, respectively. Constraints (4) and (5) ensure that containers for each request must be picked and delivered at its pick up and delivery terminal, respectively. Constraints (6) represent flow conservation for vehicle flow and (7)–(8) represent flow conservation for request flow. Constraints (7) are for transshipment terminals, and constraints (8) are for normal terminals. Constraints (9) link y and x variables in order to guarantee that for a request to be transported by a barge, that barge needs to be traversing the associated arc. Constraints (10)–(12) facilitate transshipment. (10) ensures that the transshipment occurs only once in the transshipment terminal. Furthermore, (11) and (12) let the transshipment only when the request is transported by both barges k and l. Constraints (13)–(15) are the time related constraints. Constraints (13) guarantee that the arrival time of barge is earlier than service start time. Constraints (14) maintain that the departure happens only after the service is completed. Constraints (15) ensure that the time on route is consistent with the distance travelled and speed, and M is a large enough positive number. Constraints (16) and (17) take care of the time windows. These constraints give possibility of waiting at terminals when barge arrives earlier. Constraints (18) add service time of pickup and delivery. Constraints (19)–(21) include time constraints for transshipment. If there is a transshipment from barge k to barge l, but barge l arrives before barge k departs, (19) allows barge l to wait until barge k completes its unloading. Constraints (20) and (21) add transshipment time at the transshipment terminal. Constraints (22)–(24) are the subtour elimination constraints, which provide tight bounds among several polynomial-size versions of subtour elimination constraints [23]. Constraints (25) are the capacity constraints. Constraints (26) and (27) set variables x and y as binary variables.

A MIP model for the PDPT in IWT is thus given by the objective function (1) and constraints (2)–(27) described above.

4 Solution Methodology

For the studied PDPT problem, we consider two main solution methodologies: (i) an exact solution by a solver, Gurobi [24], to the MIP, (ii) an ALNS. Section 5 presents comparative results for both approaches.

The ALNS was proposed in 2006 based on an extension of the large neighborhood search (LNS) heuristic [25], and ALNS adopted an adaptive mechanism to make it robust in different scenarios. ALNS has already been used for VRP problems successfully and it performs well on large-scale instances. There are other different approaches. But this adaptive nature of ALNS, i.e., choosing operators according to their past performances, is a significant advantage over other approaches which do not use it. The pseudocode of the ALNS in the paper is shown in Algorithm 1. X means the solution. For instance, \(X_{initial}\) means initial solution, which is generated by Greedy Insertion proposed in Sect. 4.1. \(R_{pool}\) is a set of active requests, and it includes requests need to be inserted to routes.

figure a

The ALNS is composed of a number of competing sub-heuristics, i.e., insertion and removal operators. An insertion operator is concerned with inserting requests to the routes of barges. In contrast, a removal operator is used for removing requests from a route. The combination of insertion and removal operators is called operations. The process of using an operation until all requests are served is called an iteration. After each iteration, the algorithm will assign to the used insertion operator and removal operator the same score based on the operation’s performance. The score criteria are reported in [25].

The entire search is divided into disjoint parts, henceforth called segments. A segment assumes a fixed number of iterations, and the number of iterations is denoted as s. The weights of the insertion operator and removal operator are updated after every s iterations, i.e., in every segment, according to their past performance, as follows:

$$\begin{aligned} w_{i,j+1}=w_{i,j}(1-\mu ) + \mu \frac{\pi _i}{\theta _i}, \end{aligned}$$
(28)

where \(w_{i,j}\) is the weight of operator i used in segment j, \(\pi _i\) denotes the score of operator i obtained during the last segment, and \(\theta _i\) stands for the number of times operator i is used during the last segment. The reaction factor \(\mu \) controls how quickly the weight reacts to changes in the performance of the operators.

A roulette wheel selection mechanism is employed to specify which operator will be applied next. This mechanism assumes a probability to select operator j, defined as follows:

$$\begin{aligned} \frac{w_j}{\sum _{i=1}^n w_i}, \end{aligned}$$
(29)

where \(w_j\) is the weight of operator j, and n is the number of operators.

By using an operation, a feasible solution is detected at the end of an iteration. If the current solution is worse than the last solution, it will be accepted with a probability p in order to avoid local optima easier. Simulated annealing idea is used and probability p gradually declines in order to avoid local optima [25], as the following equation shows:

$$\begin{aligned} p=e^{\frac{-(F(X_{current})-F(X_{last}))}{T}} \end{aligned}$$
(30)

where \(T\,{>}\,0\) is the temperature which starts from an initial temperature and gradually decreases in every iteration using the expression \(T = T \cdot c\). c is the cooling rate and \(0\,{<}\,c\,{<}\,1\).

After a number of iterations, the search tends to converge and finally a (sub)optimal solution is found.

4.1 Insertion Operators

Three insertion operators are used, namely greedy insertion, random insertion, and transshipment insertion.

Greedy Insertion: This insertion finds the best position in all routes for a request. The algorithm of greedy insertion without transshipment has been widely discussed in literature [14]. In algorithm with transshipment, the requests are segmented by transshipment terminals firstly, then every request is divided into two sub-requests for one transshipment terminal. For each sub-request, the algorithm without transshipment is used to find its best position. If both sub-requests satisfy constraints, they will be added to the candidate list and then the best will be chosen. In greedy insertion, the operator without transshipment is tried first. If it doesn’t work, the transshipment will be considered.

The advantage of this operator is that it can find the best position for one request. However, it needs a longer time than other insertion operators as it may get stuck in a local optimum when the best position for one request is not the best position for the overall objective.

Random Insertion: To make up for the disadvantage of greedy insertion, the random insertion is designed such that the insertion position is chosen randomly, rather than trying all positions for both with and without transshipment case. Random insertion can expand the search space and avoid local optimum, and therefore needs less time.

Transshipment Insertion: The greedy insertion evaluates the insertion of each request sequentially and may miss good opportunities to use transshipment terminals. Some requests may benefit from the transshipment, as illustrated in [12], hence applying insertion with transshipment may detect the optimal solution quicker. Different from greedy insertion, this operator only uses the algorithm with transshipment.

4.2 Removal Operators

Five removal operators are considered to remove requests from routes and transfer them to the request pool: worst removal, random removal, delete node, clear route, and remove all.

Worst Removal: This operator removes the requests with the highest cost in each route. The cost of the request is calculated as follows:

$$\begin{aligned} cost_r = F(X) - F(X_{-r}), \end{aligned}$$
(31)

where \(X_{-r}\) is the solution without request r. A request, that is served by more than one barge, will be removed completely from all routes.

Random Removal: Similar to the idea of random insertion, the random removal operator removes requests randomly, offering more unexplored spaces for insertion operators.

Delete Node: In most times, a barge carries multiple requests, therefore removing part of the requests may not change the routes of barges. However, most of the cost-savings are obtained from minimizing distance, i.e., changing routes of barges. To get better solutions quicker, Delete Node operator is designed, which deletes visited terminals in the routes. If one pickup terminal is deleted, the delivery terminal and relevant requests will be deleted too.

Clear Route: Insertion operators may not be able to find feasible solutions based on a small number of removals in a short time. In this case, the route needs to be cleared, which means all requests in a route are removed to the request pool. Another idea behind this operator is to guide the search to the direction of minimizing the number of used barges and making full use of capacity.

Remove All: This operator deletes all requests in routes and fills the request pool. This operator may change the search direction from the beginning and thus provide a larger neighborhood for insertion operators.

The synchronization for relevant barges is considered. Due to the transshipment, other barges may be influenced when one request is inserted to/removed from the route of a barge. These affected barges can cooperate with changes by extending or shortening the waiting time.

4.3 Performance Improvement

The application of an insertion operator typically involves the evaluation of the same move repeatedly, thereby resulting in a high number of duplicate computations during the optimization. Avoiding these repetitive computations can significantly reduce computation time, especially for large instances. Inspired by the idea proposed in [14], a cache structure that uses a hash table is implemented. Specifically, the hash table holds the best insertion positions and infeasible insertion positions for a given request and route. In total, eight hash tables are established. From these, four hash tables are devoted to best insertion while the rest four hash tables are built for failed insertion. There are two hash tables for insertion without transshipment, which include all possible positions and the best position during the search separately. The other two hash tables are for insertion with transshipment. Similarly, the other four hash tables for failed insertion include the same keys but they don’t have values because the solution is infeasible.

Moreover, the complexity of transshipment is reduced by limiting the solution space. According to specific requests and barges, the transshipment terminals that are far away from them are not considered.

5 Case Study

In order to evaluate the proposed methodology, we carry out a set of experiments. All experiments are implemented in Python and run on a laptop with 8 GB of memory and an Intel Core i7 CPU with two 1.90 GHz and 2.11 GHz cores. First, we validate the ALNS algorithm with respect to the exact solution of the MILP for relatively small instances as a benchmark comparison. Then we perform numerical experiments on larger instances to show the performance of the ALNS algorithm for realistic size problems. For the experiments, we chose a case in the Rhine-Alpine water corridor that covers a wide area in Europe from Rotterdam/Antwerp to Basel. Improving transport across this corridor can benefit the transport operators in the Rhine river as well as transport stakeholders in the Trans-European Transport Network (TEN-T) [26].

5.1 Data

The Contargo company is one of the largest intermodal transportation providers in the Rhine-Alpine corridor, which is used as our case. In Rhine river, Contargo transports containers among 21 terminals, including deep-sea terminals in Rotterdam and Antwerp ports and inland terminals along the Rhine. According to figures [27] and timetables [28] in Contargo’s website, it has nine services, which all have both import and export. The cost data used in the paper are reported in [29]. The speed data is obtained from an online ship monitoring system [30]. Affected by water flow, the upstream speed is lower than downstream speed.

5.2 Benchmark Comparison

Table 3 compares the results of exact approach by Gurobi and the best solution by ALNS in terms of average cost and computation time for small instances (1–8 requests, 2 barges and 1 transshipment terminal). For each instance, 20 independent experiments are conducted to get the average value. When Gurobi finds the optimal solution in the limited time (12 h), ALNS is able to provide the same solution in significantly less computational time. For the instance with 7 requests, Gurobi cannot reach optimality within the time limit and ALNS outperforms within a significantly lower computational time. As of 8 requests, Gurobi cannot provide a feasible solution within the time limit.

Table 3. The comparison between benchmark and ALNS.
Full size table

5.3 Experiments with Large Instances

The possibility of transshipment in our model is one of the key complexities towards computational burden. Nevertheless, transshipment plays a vital role in supply chain today, allowing cargo to reach different parts of the world. It offers logistics players a high level of flexibility that can bring significant cost benefits. To obtain the saving cost of transshipment, the following experiments with large instances will compare the results of ALNS with/without transshipment.

Before proceeding with the results, we discuss the parameters of ALNS that affect the performance. Among those we analyzed the size of segments, s, and reaction factor \(\mu \) based on an instance with 10 requests, 4 barges, and 1 transshipment terminal. These requests use Rhine-Main and Rhine-Upper services of Contargo company. To make sure the tuned parameters perform well under PDPT, these requests are designed to benefit from transshipment. There are 200 iterations in each experiment, and all experiments are repeated 5 times to get the average result. We concluded that the size of the segment needs to be sufficiently large compared to the number of operators in order to be able to update the weights accordingly in the early iterations. Otherwise it might lead to misleading weights. For example, for the case of 10 requests we need at least 8 iterations in a segment. When it comes to the reaction factor, our experiments showed that one should not ignore the history completely, i.e., \(\mu \) should be smaller than 1. We chose 0.8 for the reactive factor \(\mu \). Note that, these parameters need to be carefully analyzed for ensuring the performance of ALNS for different problems.

Based on the above-mentioned tuning of parameters, we run larger instances as the results are shown in Table 4. Three large instances are designed with a naming convention such that “20r4k1T” means 20 requests, 4 barges and 1 transshipment terminal. The first instance contains 20 requests using same services with the small instance used in parameter tuning. Other two large instances include 30 requests, which cover all services of Contargo company. The only difference between these two instances is the loads of requests that are randomly drawn. The cost of the instances with 30 requests is lower than the instance with 20 requests because loads of requests and capacity of barges are different. Generally, the running time with large instances is less than 10 min.

Table 4. Results for large instances.
Full size table

In Table 4, “# Flexible Barges” column represents the number of barges without fixed timetables. Except for flexible barges, other barges use real fixed timetable. When the number of flexible barges increases, the cost is reduced due to the flexibility of the proposed PDPT model.

The results show that the savings from transshipment vary a lot from one instance to another. The three factors that are playing an important role in an interdependent way are: (1) the cost of transshipment (based on the load) (2) the number of flexible barges (3) the capacity of the barges with respect to the loads. When the load is higher the transshipment costs are higher and it may not be preferable to use the transshipment option. When the number of flexible barges increases, more benefits from transshipment can be exploited, as shown in results of instances 20r4k1T (number of flexible barges from 0 to 2) and 30r5k1T-I (number of flexible barges from 0 to 3). Meanwhile, when there are enough flexible barges, the attractiveness of transshipment may decrease as the same phenomenon can be represented by the flexibility in routes, as shown in results of instances 30r5k1T-I (number of flexible barges from 3 to 5) and 30r5k1T-II (number of flexible barges from 0 to 5).

From the results, we can conclude that the following cases could benefit from transshipment: a) Requests that on the overlap (or similar) route of barge A and B can be transferred from one barge to another, and the cost-savings result from avoiding an unnecessary barge trip. b) Barge A’s transport cost is lower than barge B, then part of requests of barge B can be transferred to barge A to make full use of its capacity.

6 Conclusions and Future Work

Inland waterway transport has been widely recognized as reliable, cost-efficient, and sustainable. To make full use of resources in waterway transport, a MIP model for Pick and Delivery Problem with Transshipment of inland barges is proposed. Because the solution of the studied problem is computationally expensive, an ALNS heuristic is proposed by developing operators specific to this problem. The results show that the ALNS approach reduces computation time significantly, and the best solution of large instances (up to 30 requests) can be obtained within 10 min. Due to the flexibility of PDPT, the cost decreases gradually when the number of barges without fixed timetable increases in the transport network. Additionally, the introduction of transshipment terminals brings reduction on costs (up to 14%), but it differs greatly from one instance to another. Future research will focus on the following aspects:

  1. 1.

    Multiple barge operators may want to cooperate to optimize their transport networks. Moreover, barge operators need to communicate with terminal operators about the arrival time and berth allocation. Therefore collaborative planning among different players will be studied.

  2. 2.

    New requests from a spot market may be released and new barges may be added into the transport network, which will lead to dynamic optimization. If the new request (new barge) is more suitable for a barge (a request), the original plan can be replaced with a penalty.

  3. 3.

    Boundaries of the work can be extended with the expansion of the network to include other modalities and the optimization for barges within the intermodal transport will be studied.

  4. 4.

    The storage in the terminal will be considered in the future, and the storage cost and terminal capacity will be added in the model.