1 Introduction

Container ports need to handle large container volumes, for example, tens of thousands of containers arrive at Rotterdam port by sea every day. To move these containers, road, inland waterway and railway transport are provided connecting terminals and the hinterland. Traditionally, road transport took the largest share in the freight transport market both inside the port area and in the hinterland. However, waterway and railway transport are stimulated by the port authority as economical and environmental friendly alternatives. For example, the port authority published a strategic plan, i.e., Port Vision 2030, stating that stakeholders within Rotterdam port have agreed to reduce the usage of road transport: a maximum of 35% of containers transported to and from the Maasvlakte by road in 2030 (Port of Rotterdam 2011). The strategic Plan covers the period up to 2030 and in more recent progress report, it states that rail transport should be developed with priority and that rail transport share is falling short of the target established in Port Vision 2030 (Port of Rotterdam 2014).

The development of multiple transport modes, on the one hand, increases the transport capability; but on the other hand, leads to higher infrastructure investment and more operations between modes inside the port area. In Rotterdam port, the port authority pursues the improvement of the port efficiency and accessibility by cooperation between transport modes (Port of Rotterdam 2011). For example, a Barge Service Center has been established to provide better waterway transport and the same is pursued for rail transport. This terminal handles inland waterway barges and sends containers to other terminals and vice versa. Moreover, the port authority subsidizes the PortShuttle services, which connect the rail yards in Maasvlakte and the Railway Service Center in the hinterland by feeder trains (“PortShuttle adds second shuttle” 2017). This paper seeks to improve the multi-modal transport system in the port area. We put the focus on the rail-road transport system and study how to move containers from different port terminals to rail yards in the port area and then deliver the containers to the hinterland by rail.

The container transport in this paper involves moving containers inside a terminal, moving containers between port terminals using a variety of modes (railway and road) and moving containers from rail yard in the port area to the hinterland using railway. Generally, there are two types of intermodal terminals with rail connection in a port area, i.e., railway terminal with road connection (RTR), and maritime terminal with both road and on-dock railway connections (MTRR). Inside these terminals, transshipment can be performed and containers from sea transport and/or road transport can be transshipped to rail transport. In another type of terminals, which is called maritime terminal with road connection and rail off-dock (MTR), containers cannot be transshipped to rail transport directly—the containers must be moved to a RTR or MTRR through inter-terminal transport (ITT) first. Actually, ITT also connects MTRRs and RTRs, which makes it possible to exchange containers between different rail yards in the port area in order to fill the trains towards the hinterland with containers.

To achieve an integrated ITT and hinterland rail transport, several planning problems should be solved. On a strategic level, a proper ITT network must be built to connect the terminals. The ITT network involves the connection between terminals and ITT fleet that moves containers between them. On a tactical level, the port authority and terminal operators must first determine if and how it is possible to share the resources, e.g., rail yards and ITT trains. It is notable that not all containers can be exchanged between all terminals as ITT requires coordination between terminal operators and freight shippers, which means information and facilities should be shared and the coordination benefits must be clear. Then, the railway timetable and the size of the trains which could guarantee the efficiency of railway transport must be designed. On an operational level, the terminal operator also has to decide when and how to move the containers to a rail yard according to the ITT network and also to the timetable of outbound trains.

This research focuses on the tactical planning problems, i.e., how would the different ITT connections, train formation strategies and railway timetables affect the container delivery performance? Additionally, we also develop a rolling horizon framework to guarantee the model can be used in operational planning, i.e., planning the container handling operations and design the vehicles’ routes. We assume that terminals in a port area could coordinate with each other in a certain level, and resources such as ITT trucks and ITT trains are shared among terminals. Therefore, the decision on the ITT organization considering terminal handling capacity and the railway timetable could be made to maximize the number of containers to be delivered by train within a certain time period (e.g., a day). Then, a mathematical model which could formulate the vehicle and container movements considering the terminal handling capacity is proposed. In that model, different ITT connections, hinterland train sizes and railway timetables are tested with a given ITT fleet to provide insights into the possible strategies which could improve the integrated container delivery to the hinterland.

The remaining part of this paper is organized as follows. Section 2 reviews the studies on terminal operations and ITT. Section 3 will define the integrated port container transport system studied in this paper in great detail. In Sect. 4, the problem is mathematically modeled with a time–space graph and the performance is tested with different transport strategies. Section 5 contains the experiments and Sect. 6 presents the conclusion and further research.

2 Literature review of ITT and container terminal operations

This section reviews the research related to different aspects of the container transport from the port area to the hinterland: research on ITT mainly focuses on the container and vehicle movement between terminal; and the research on terminal operations covers problems such as crane scheduling, container transshipment, train loading and departing.

ITT itself can be based on different modes, such as railway, road and inland waterway. A detailed review of ITT can be found in Heilig and Voß (2017). The implementation of a multi-modal ITT system among several terminals usually requires coordination between terminal operators and the port authority. Duinkerken et al. (2006), proposed an ITT system which is shared among the terminals at the Maasvlakte, Rotterdam. Heilig et al. (2017) investigated the truck-based ITT system provided by a third party ITT provider. The ITT provider collects demand information, monitors the trucks’ positions and schedules the trucks’ routes. Schepler et al. (2017) studied an ITT system based on road, waterway and railway transport and provided suggestions for the port authority and terminal operators in terms of vehicle routings. Our research considers a rail-road network for ITT and the rail connections to the hinterland. The studied ITT system provides service for multiple terminals in the port area aiming at improving the ITT transport system efficiency.

Most existing research on ITT only focused on the transport inside the port area. Ottjes et al. (2006) studied an AVG-based ITT system for the Maasvlakte terminals in Rotterdam and tested the traffic flow between the terminals. Hendriks et al. (2012) focused on the berth allocation problem among multiple terminals considering quay crane operation cost and ITT costs. In Li et al. (2017a) and Li et al. (2017b), inland waterway vessels are used to carry ITT containers between certain terminals in the port. Both studies aim at reducing the time that vessels spend in the port while increasing the number of ITT containers that can be transported. Our research considers the railway transport to the hinterland, therefore the railway timetable must be taken into account. Tierney et al. (2014) propose the first fully defined mathematical model of ITT using a time–space graph. Based on the graph, the authors present an integer-programming model to optimize the container and vehicle flow between terminals. In our study, we also use a time–space model, but we extend the model developed by Tierney et al. to study an ITT integrated with detailed terminal operations and hinterland rail connections.

Different terminal operation problems have been intensively studied. Stahlbock and Voß (2008) provide a detailed review of the operational problems in a maritime container terminal. When moving a container inside a terminal, the movement of cranes and trucks is a key process to be optimized to accelerate that process. Kim and Park (2004) study a quayside crane scheduling problem which determined the order of ship loading and unloading operations. The authors considered containers with same destination and size as a group and assumed that a group of containers should be put into adjacent slots in the ship, which was defined as clusters. Then the problem was formulated as moving containers between several clusters and ship-bays using cranes. In our research, we focus on the operations related to railway transport, therefore, quay crane scheduling problem and other operation problems on the seaside, see Carlo et al. (2015), are not considered in detail. But Kim and Park (2004) inspired us with the container group abstraction: in our research, a group of containers with the same release time and origin terminal is defined as a transport task. Inside the terminals in our model, transport tasks should be executed between different terminal locations with cranes and trucks. Froyland et al. (2008) optimize the landside crane operations in a maritime container terminal. To reduce the complexity, the authors decomposed the problem into three stages: first determine the container flow between quayside and landside on an hourly basis; then determine the stacking positions for the import containers on the quayside; and finally, determine the order of containers and trucks served by Rail Mounted Gantries (RMGs) and the containers temporary stacking position on the yard side. In our research, containers are not only moved inside a terminal but also moved between terminals in the port area. To reduce the computational intractability, we do not consider the precise position of a container in the storage yard nor on the train, and we use a uniform handling time for every container. However, in future research, these items can be taken into account.

When loading a train in a MTRR and RTR, a well-organized deployment of the handling equipment and spatial arrangement of containers on a train could reduce the working time of the equipment and increase the utilization of a train’s carrying capacity. Corry and Kozan (2008) present a mixed integer programming (MIP) model to assign containers to rail wagons using RMGs. The objective is to minimize the number of rail wagons required and the working time. Wang and Zhu (2014) optimize the container transshipment between trucks, storage yards and trains. The objective is to minimize the RMGs’ idle time. In our research, trains with different capacities are used, and the train loading process is performed considering the railway timetable.

In European countries, the passenger trains have a higher priority: the passenger trains’ timetable is prescribed, a freight train’s operator can only request to insert the freight train between passenger trains, see Cacchiani et al. (2010). Delayed trains may not be allowed to enter a rail section to avoid potential conflicts. Thus, delayed trains must be rescheduled or canceled. A possible way to improve the flexibility for the rail operator, e.g., in D’Ariano et al. (2008), is reserving longer departure time slots for the trains, which makes the timetable more robust for delays. In our research, we handle the delayed hinterland trains with new departure time slots. Usually, a train is assigned with a departure time slot from its departure terminal to make sure this train could enter the inland railway network without delaying other trains. We assume that the departure time slots could be shared among several terminals in the port area; therefore, the terminal operator has some flexibility in organizing the ITT delivery and hinterland train loading. The using of periodic and flexible timetable is explained in detail in Sect. 3.1.

Overall, the existing research has tackled different subproblems while neglecting the integration of these highly interactive problems in port areas and their hinterlands. Our study optimizes the container movement inside and between terminals and the port hinterland, by using RMGs, shared ITT trucks and ITT trains. The objective is to maximize the container delivery for all terminals in a certain time period. The container delivery performance is discussed with different ITT network configurations, train formation strategies and types of railway timetable.

3 Container movement inside the port area and to the hinterland

3.1 ITT and rail transport to the hinterland

ITT connects different terminals in a port area. In this study, MTRs are connected with other terminals by road; MTRRs and RTRs are connected with other terminals by both road and rail. Containers are released at MTRs and MTRRs and then moved to a rail yard using shared ITT trains and trucks through ITT. In this system, ITT trucks move containers from MTRs to MTRRs and RTRs; ITT trains and trucks exchange containers among MTRRs and RTRs.

To reveal how different ITT connections can affect the container transport, two types of ITT connections are applied in this research: complete ITT and incomplete ITT. In the complete ITT case, containers from MTRs can be moved to all MTRRs and RTRs; MTRRs and RTRs accept containers from any other terminal. In the incomplete ITT case, some connections are excluded. ITT trains and trucks are used in both cases.

Containers leave the port area with hinterland trains from MTRRs and RTRs. The hinterland trains depart according to the railway timetable. If a train is not fully loaded at its departure time, the terminal operator must decide whether the train should depart or not. When a train cannot depart at the scheduled departure time slot, the railway terminal operator and the network operator must find another solution like either rescheduling or canceling the train.

Our research considers both periodic and flexible timetable. In the periodic timetable scenarios, each train has a predetermined departure time slot from a predetermined departure terminal. Therefore, each train could leave the port area and enter the inland railway network at a proper time without blocking other trains. We assume that in flexible timetable scenarios, the railway operator only cares about the time when a train enters the inland railway network, and the train could move freely inside the port area. Thus, a departure time slots pool could be shared among all rail terminals inside the port area and the train could depart at any departure time slot from any one of the terminals which is not used by another train. Additionally, two types of train size are used: small trains with 40 TEU and large trains with 80 TEU capacity. All trains must reach a minimal loading rate (in our case set at 75%) before departure as Boysen and Fliedner (2010) pointed out that trains could only be profitable if full trains are moved.

Based on the ITT connection case and railway timetable to the hinterland, the routes of the vehicles in the port area should be scheduled to make sure every container can arrive at the rail yard on time. Moreover, the transshipment inside terminals must be taken into consideration as well.

3.2 Container terminals and transshipments inside the terminals

Three types of container terminals are considered, i.e., RTR, MTR and MTRR, see Fig. 1. As we study the container transport from the port to the hinterland, the storage yards in the MTRs and quayside storage yards in MTRRs are the origin of containers and the containers should be moved to the rail side of the RTRs and MTRRs. In these terminals, four types of operations are considered: (1) truck loading, (2) truck unloading, (3) train loading, and (4) train unloading.

Fig. 1
figure 1

Schematic representation of RTR, MTR and MTRR

Full size image

In a MTR, several storage blocks are vertically located next to the deep sea berth; automated Guided Vehicles (AGVs) are used to transport containers between the berth and the storage blocks; loading and unloading operations are performed at the I/O points where RMGs move containers between trucks and storage blocks, see Vis and De Koster (2003) for a detailed description. In our study, ITT trucks pick up containers from the I/O points and move the containers to MTRRs or RTRs.

In a MTRR, when an outbound container is unloaded from the deep-sea ship, if the railway tracks are constructed along the quayside, then it is possible to load the container onto the train using RMGCs or RTGCs; otherwise, vehicles such as trucks and reach stackers will be used to transport the container from the quay to the rail yard. In the rail yard of a MTRR, RMGs moves containers between trains, rail side storage blocks and trucks.

In this research, the container from the quayside will be first moved to the I/O points and then loaded onto an ITT truck by a RTG. Then the truck will transport the container to the rail yard inside the terminal or to another terminal in the port area. When a truck arrives at the rail yard in MTRR, without losing generality, the container carried by truck should be firstly unloaded to the storage yard and loaded onto a train later. Rail-rail transshipments also take places in the rail yard in the MTRR, where cranes move containers from one train to another. In our research, the rail–rail transshipment between ITT trains is excluded because it can be avoided by running a train visiting all rail terminals. It is assumed that the rail–rail transshipment is performed in the following way: a RMG unloads the container from an ITT train and moves it to the storage blocks; when the train to the hinterland is ready for loading, that container will be loaded onto that train. This assumption, however, could lead to an increase of RMG operations and transshipment time.

In a RTR, storage yards and truck lanes are constructed along the railway tracks and rail mounted gantry cranes (RMGs) are used to move containers between truck, storage yards and trains, see e.g., Boysen and Fliedner (2010). In some cases, for example, if the storage yards and truck lanes are not built next to the railway tracks, extra vehicles such as reach stackers and forklifts are used to move containers, see e.g., Kozan (2006).

This research focuses on the terminals using RMGs, therefore, truck unloading, train loading and unloading are performed in a way similar to the operations in rail yards in MTRRs. The rail–road transshipment is not considered because due to the typical size of ITT (up to 20 km in this research), it is not logical to make a transfer from a train to a truck, therefore, no trucks are loaded in RTRs or rail yards in MTRRs for ITT transport. The road–road transshipment is not considered because it will not improve the transport performance while requiring extra transshipment cost. In the next section, the integrated ITT, terminal operations and hinterland rail transport will be modeled.

4 Problem modeling

4.1 Time–space network representation

4.1.1 Links and arcs

The container and vehicle movement is formulated by a directed graph denoted as \(G(N,A)\), where \(N\) is the set of nodes (i.e., locations of terminals and locations to pick up or drop off containers in the network) and \(A\) is the set of arcs. The subsets \(N^{ter}\), \(N^{pickup}\), \(N^{dropoff}\) and \(N^{hin}\) refer to the terminal, container pick-up, drop-off points and destination node in the hinterland respectively.

Let two adjacent nodes \(i,j \in N\) identify an arc \((i,j)\), which refers to the possibility of moving from one node (location) to another one at a given time. Each arc, \((i,j) \in A\), is associated with a traverse time \(f_{i,j}\). To model the moving and staying status of vehicles and containers, two types of arcs are considered, i.e., stationary arcs and moving arcs (subsets \(A^{sta}\) and \(A^{mov}\) respectively). Vehicles and containers on a stationary arc do not move in space but simply stay at the same node (location) during the given time step. In other words, the only thing changing between the start- and end-node of the arc is time. Vehicles and containers on a moving arc are moving from one terminal to another; the arcs connect two different locations at different times.

Figure 2 shows a simple ITT network with four terminals: one MTRR, two RTRs and one MTR. This simple network illustrates how the time–space network represents the real ITT network. In order to distinguish the railway and road connection, 2 dummy nodes are used to represent the transport segments. Node \(1 - Rail\) and \(1 - Truck\) denote the rail side and truck side in terminal 1 respectively. Railway tracks in terminal 1, 2 and 3 are connected while road in terminal 1, 2, 3 and 4 is connected.

Fig. 2
figure 2

4-terminal network with dummy nodes

Full size image

4.1.2 Transport operations

The railway segments nodes are further connected to the destination in the hinterland, i.e., \(N^{hin} \in N\), by directed arcs. These arcs are only accessible at certain departure time slots according to the railway timetable. Therefore, containers will stay in the drop-off nodes before moving to their destinations. Let \(\theta\) denotes the demands to be served and \(\varTheta\) denotes the set of demands. More precisely, each demand \(\theta \in \varTheta\) is named as a task. Each task is associated with a certain number of containers \(Dem_{\theta }\) in TEU, an origin node \(o_{\theta } \in N\), a destination node \(d_{\theta } \in N\), an earliest release time \(r_{\theta }\) and an intended delivery time \(u_{\theta }\). This paper only discusses the outbound transport flow from the port area to the hinterland and not the return flows to the port area. Therefore, pick-up nodes \(N^{pickup} \in N\), e.g., \(1 - RailP\) in Fig. 2, will be the origin of the task and the hinterland node \(N^{hin} \in N\) will be the destination of the task.

Let \(V^{TrainITT}\), \(V^{TruckITT}\) and \(V^{TrainHin}\) be the set of vehicles used, i.e., ITT trains, ITT trucks and hinterland trains. Each vehicle \(v\) has a carrying capacity \(VehCap_{v}\). Vehicles can move containers between terminals using the transport arcs, i.e., black arcs in Fig. 2. \(Win_{v}\) is the set of possible departure time slots for hinterland train \(v \in V^{TrainHin}\). Let \(\eta\), which is 75% in this case, represent the minimal loading rate which trains must reach before departure.

4.1.3 Transshipment operations

The transshipments between transport modes can also be represented by the nodes and arcs. These arcs are named transshipment arcs, i.e., colored arcs in Fig. 2. As mentioned in Sect. 2.2, transshipments are performed via storage yards: when a container is transferred from road to rail inside a terminal, e.g., terminal 1, the drop-off location in storage yard \(1 - TruckD\) is connected to the pick-up location \(1 - RailP\). Thus it is possible to move from a truck to a train with an operation time \(f_{1 - TruckD,1 - RailP}\). Similarly, when a container is transshipped from one train to another, it will be moved from the railway drop-off node \(1 - RailD\) to railway pick-up node \(1 - RailP\) with an operation time \(f_{1 - RailD,1 - RailP}\). To represent the RMGs capacity, \(ArcCap_{i,j}\) is used to limit the number of containers that can be moved via transshipment arcs at each time step.

4.2 Mathematical model

The parameters used in the model are shown in Table 1.

Table 1 Parameters used in the model
Full size table

We use an integer programming model to formulate the movement of containers and vehicles and maximize the number of containers which can be delivered to the hinterland. Two integer variables are used to formalize the temporal and spatial movements of vehicles and containers respectively. Let variables \(x_{i,j,t,v}\) indicate the number of \(v\) type of vehicle travelling on arc \(\left( {i,j} \right)\) at time t. Variables \(y_{i,j,t,\theta }\) represent the number of containers for task \(\theta\) is delivered on arc \(\left( {i,j} \right)\) at time \(t\). We assume that containers that cannot be delivered before their due time will remain at the origin terminals. The objective function can then be expressed as minimizing the number of containers cannot reach their destination on time. The final optimization model would then read:

$$\hbox{min} Z = \sum\limits_{\theta \in \varTheta } {\sum\limits_{{\left( {d_{\theta } ,d_{\theta } } \right) \in A^{sta} }} {(Dem_{\theta } - y_{{d_{\theta } ,d_{\theta } ,u_{\theta } ,\theta }} )} }$$
(1)

S.T.

$$\sum\limits_{{\left( {o_{\theta } ,j} \right) \in A}} {y_{{o_{\theta } ,j,r_{\theta } ,\theta }} } = Dem_{\theta } ,\quad \forall \theta \in \varTheta$$
(2)
$$\sum\limits_{{\{ i|\left( {i,j} \right) \in A\} }} {y_{{i,j,t - f_{i,j} ,\theta }} } = \sum\limits_{{\{ k|\left( {j,k} \right) \in A\} }} {y_{j,k,t,\theta } } ,\forall \theta ,t \in T,t - f_{i,j} \ge 0,\quad \forall j \in N$$
(3)
$$\sum\limits_{{\left( {O_{v} ,j} \right) \in A}} {x_{{o_{v} ,j,t,v}} } = \left| {V^{TruckITT} } \right|,t = Min(r_{\theta } ),\quad \forall v \in V^{TruckITT}$$
(4)
$$\sum\limits_{{\left( {O_{v} ,j} \right) \in A}} {x_{{o_{v} ,j,t,v}} } = \left| {V^{TrainITT} } \right|,t = Min(r_{\theta } ),\quad \forall v \in V^{TrainITT}$$
(5)
$$\sum\limits_{{\left( {O_{v} ,j} \right) \in A}} {x_{{o_{v} ,j,t,v}} } = \left| {V^{TrainHin} } \right|,t = Min(r_{\theta } ),\quad \forall v \in V^{TrainHin}$$
(6)
$$\sum\limits_{{\left( {i,j} \right) \in A}} {x_{{i,j,t - f_{i,j} ,v}} } = \sum\limits_{{\left( {j,k} \right) \in A}} {x_{j,k,t,v} } ,\quad \forall t \in T,t - f_{i,j} \ge 0,v \in V$$
(7)
$$\sum\limits_{i \in N} {\sum\limits_{{j \in N^{hin} }} {\sum\limits_{{v \in V^{TrainHin} }} {x_{i,j,t,v} } \le 1} } ,\quad \forall t \in Win_{v}$$
(8)
$$\sum\limits_{{v \in V^{TrainHin} }} {x_{i,j,t,v} } = 0,\forall t \notin Win_{v} ,\quad i \in N^{dropoff} ,j \in N^{hin}$$
(9)
$$\sum\limits_{\theta \in \varTheta } {y_{i,j,t,\theta } } \le \sum\limits_{v \in V} {VehCap_{v} \cdot x_{i,j,t,v} } ,\quad \forall t,i \in N^{ter} ,j \in N^{ter} ,\left( {i,j} \right) \in A^{mov}$$
(10)
$$\sum\limits_{{\left( {i,j} \right) \in A^{mov} }} {x_{i,j,t,v} } = 0,\quad \forall t,v,\forall i \in N^{pickup}$$
(11)
$$\sum\limits_{{\left( {i,j} \right) \in A^{mov} }} {x_{i,j,t,v} } = 0,\forall t,v,\quad \forall j \in N^{dropoff}$$
(12)
$$\sum\limits_{{i \in N^{ter} }} {\sum\limits_{t \in T} {y_{i,j,t,\theta } } } = \sum\limits_{{k \in N^{ter} }} {\sum\limits_{t \in T} {y_{j,k,t,\theta } } } + \sum\limits_{{p \in N^{dropoff} }} {\sum\limits_{t \in T} {y_{j,p,t,\theta } } } \forall j \in N^{ter} ,\quad \theta \in \varTheta$$
(13)
$$\sum\limits_{\theta \in \varTheta } {y_{i,j,t,\theta } } \ge \sum\limits_{{v \in V^{TrainHin} }} {\eta \cdot VehCap_{v} \cdot x_{i,j,t,v} } ,\forall t,i \in N^{ter} ,j \in N^{hin} ,\left( {i,j} \right) \in A^{mov}$$
(14)
$$\sum\limits_{\theta \in \varTheta } {y_{i,j,t,\theta } } \le \sum\limits_{v \in V} {ArcCap_{i,j} } ,\quad \forall t \in T,i \in N^{ter} ,j \in N^{dropoff} ,\left( {i,j} \right) \in A^{mov}$$
(15)
$$\sum\limits_{\theta \in \varTheta } {y_{i,j,t,\theta } } \le \sum\limits_{v \in V} {ArcCap_{i,j} } ,\quad \forall t,i \in N^{pickup} ,j \in N^{ter} ,\left( {i,j} \right) \in A^{mov}$$
(16)
$$y_{i,j,t,\theta } = 0,\quad \forall \theta ,t < r_{\theta } ,\left( {i,j} \right) \in A$$
(17)
$$x_{i,j,t,v} = 0,\forall t < \hbox{min} \left( {r_{\theta } } \right),\quad \left( {i,j} \right) \in A$$
(18)
$$y_{{o_{\theta } ,o_{\theta } ,u_{\theta } ,\theta }} + y_{{d_{\theta } ,d_{\theta } ,u_{\theta } ,\theta }} = Dem_{\theta } ,\quad \forall \theta \in \varTheta$$
(19)
$$x_{i,j,t,v} \in \{ 0,1\} ,\quad \forall t,v,\left( {i,j} \right)$$
(20)
$$y_{i,j,t,\theta } \in \{ 0,1\} ,\quad \forall \left( {i,j} \right),t,\theta$$
(21)

Function (1) minimizes the number of containers that cannot reach their destination before the due time. Constraints (2) and (3) ensure the consistency of containers’ movement for each demand at origin, intermediate, and destination node. Constraints (4) to (6) guarantee that vehicles depart from pre-determined terminals at the earliest release time. For each node, constraint (7) forces the number of incoming vehicles to equal the number of outgoing vehicles at any time. Constraint (8) ensures that at any departure time slot, only one train could depart from any of the terminals, which prevents one departure time slot being used by more than one train. Constraint (9) is used to force trains to depart based on the given timetable. In constraint (10), the number of containers delivered by a truck or train cannot exceed its carrying capacity. Constraint (11) and (12) prevent vehicles traveling to the dummy nodes. Constraint (13) ensures that containers on ITT trains cannot be moved to hinterland trains directly. When containers moved to a terminal by ITT trains, these containers must be either moved to another terminal by ITT train or dropped off first. Constraint (14) ensures that a train will not leave before it reaches the minimum required loading rate. In constraint (15) and (16), the number of containers being handled cannot exceed the handling capacity of the terminal. Constraint (17) ensures that containers cannot be moved out of their origin nodes before the corresponding release times. Constraint (18) ensures that vehicles will not move before the earliest container release time. Constraint (19) ensures that at the due time of task \(\theta\), all containers in that task should be at their origin or destination node. In our model, the ITT will send as many containers as possible to rail terminal before the departure of the train. In that case, delayed delivery to a rail terminal is meaningless as the connecting train could have departed or cancelled. Thus, we assume that the containers cannot be sent to destinations before their due time will stay at their origin terminals. With this assumption, we could: (1) avoid the non-performance in ITT; (2) rule out some similar solutions for the solver (as the delayed containers can be at any locations at its due time, while the location of these containers has no influence to our objective function). In other terms, this fix helps as the final location of the delayed containers, i.e., the index \((i,j)\), for which \(y_{i,j,t,\theta }\) is non-zero, for the time \(t = u_{\theta }\), for each \(\theta\), has no direct influence on to our objective function. Constraints (20) and (21) state the restriction of the variables \(x_{i,j,t,v}\) and \(y_{i,j,t,\theta }\).

5 Computational experiments

Computational experiments are conducted under different conditions, several scenarios were created by varying the transport demand, ITT terminal connections, train formation and railway timetables. The tested cases need to be complex enough to reflect realistic conditions but at the same time be solvable in an acceptable time period. Thus, the test cases were designed as container transport from 11 container terminals to a single destination in the hinterland with 2 ITT trains, 8 ITT trucks and maximum 20 trains to the hinterland (an extended version of Fig. 2). The scenarios represent a randomized transport demand day with different distributions. A planning horizon of 24 h with a 5-minute discretization was used.

5.1 Container terminals and transport network: instances and assumptions

We use a simplified network based on the terminals in Maasvlakte 1&2. 11 real-life container terminals are considered: four MTRRs, five MTRs and two RTRs. The MTRRs and RTRs are connected to the Port Railway Line and then further connected to the Betuweroute, which heads to Germany. The terminals’ names and types are shown in Fig. 3. The possible connections between the terminals, their distance, and the minimum travel time (if there is no queue for loading/unloading) are shown in Fig. 4a.

Fig. 3
figure 3

Container terminals in Maasvlakte 1&2

Full size image
Fig. 4
figure 4

Connections between terminals and peak demand factors

Full size image

In order to plan the vehicle and container movement among these terminals, the following key information about the containers, ITT vehicles, hinterland railway, and terminals over a certain time period (e.g., daily basis) should be collected and available in advance, see Table 2.

Table 2 Required information for the optimization model
Full size table

For the containers, information about transport volume, origin terminal or yard in the port, release time in the origin terminal, the destination of the container, and the destination is needed. The transport volume, the origin terminal or yard and the release time can be obtained from terminal operators based on their operational plan. The terminal operators also have the destination information of each container from the deep-sea container carriers.

For the ITT vehicles, including ITT trucks and ITT trains, we need the information about their location and capacity as the input for our model. The ITT vehicles can be provided by a third party ITT provider, a logistic provider or several terminal operators. Then, information should be collected from different actors involved and identify available vehicles and their capacities.

For the hinterland railway transport, the information about railway timetable and train capacity is needed. The railway timetable, which indicates which time slots are possible for train departure, can be obtained from the track owner; and the capacity of the hinterland train can be collected from the train operator.

For the terminals, the handling capacities and handling speed are needed to calculate the time spent in (un)loading. This information can be collected from terminal operators based on the type of equipment and the operation plan.

We believe that most of the information about the containers and ITT vehicles should be collected at least on a daily basis because the accuracy of the information will become lower over a longer time period. The infrastructure manager (in most cases), e.g., ProRail in the Netherlands, or the track owners (for some industrial private railways) usually use a fixed timetable for a year. Similarly, the terminal handling capacity may remain the same if the same amount and type of equipment and working procedure (number of crew, business hours, etc.) are used. Therefore, the information about the hinterland railway timetable and terminals can be updated only if there are major changes in the terminal.

Although collecting the information requires considerable effort from the decision maker(s) who wants to schedule the integrated ITT and hinterland rail system, we believe obtaining these data is possible. For experimental purpose, however, estimation should be made as the input for our model. The estimation could for example be made with on-site observing, however, the complication is that we cannot get these data for all terminals at the same time. Therefore, we made the following assumptions given the conditions of terminals in Port of Rotterdam.

In terms of operational capacity, the capacity is assumed to be always enough for loading and unloading trucks as well as for the transshipment from trucks to trains. The capacity of train loading, unloading and transshipment, however, can be estimated by the number of rail tracks and rail cranes in each yard. The number of cranes in each rail terminal can be found in Fig. 3. Every railway crane can handle one TEU per time step.

Among the studied terminals, six terminals possess rail access, as shown in Fig. 3. All these terminals except terminal 8 can handle ITT trains and hinterland trains. As the rail track length in terminal 8, Rotterdam Container Terminal is much shorter than 750 m, it is assumed that no hinterland trains depart from that terminal. As for the capacity of trains, ITT trains can carry 20 TEU containers and hinterland trains can carry either 40 TEU or 80 TEU containers. The minimum assumed loading rate of the hinterland train is 75%. In terminal 1, 2, 3, 10 and 11, maximal four small trains or two large trains could depart every day.

The transport demand is generated considering the throughput of the Rotterdam port and the modal split. In 2017, approximately 1.2 million TEU containers are sent to the hinterland from Rotterdam port (Port of Rotterdam 2017). According to the Port Vision 2030, rail transport covered around 15% of the total transport demand in 2011 and should cover at least 20% of these containers before 2030 (Port of Rotterdam 2011). Given the improvement of the rail transport, we consider two scenarios of rail transport around 20%: in small transport demand cases (DS1 and DS2), the share of rail transport increases slowly and 18% of the total transport demand is covered by rail (600 TEU per day) and in the large transport demand cases (DS3 and DS4), the share of rail transport has been largely increased, i.e., 24% of the containers are covered by rail (800 TEU per day).

In this paper, all containers have the same destination in the hinterland, thus we only need to generate the release time and origin terminal of each task. Among the four DSs, two of them (DS1 and DS3) are released evenly within the day and two of them (DS2 and DS4) are released with peak factors. The peak factors, i.e., the ratio of peak demand to the average demand, used in the experiment were reported in Nieuwkoop (2013), which studied the variation in ITT transport demand between terminals of Maasvlakte 1. The variation of the transport demand can be found in Fig. 4.b. To avoid infeasible transport demand, it is assumed that the last transport demand is released 3 h before the end of the planning horizon. The transport demand of each terminal is shown in Fig. 3, e.g., the total transport demand of terminal 1 in DS1 and DS3 is 162 TEU; the total transport demand of terminal 1 in DS2 and DS4 is 216 TEU. The transport demand scenarios are as follows:

DS1 65 tasks: 600 TEU containers distributed evenly;

DS2 61 tasks: 600 TEU containers distributed with peak factors;

DS3 65 tasks: 800 TEU containers distributed evenly;

DS4 67tasks: 800 TEU containers distributed with peak factors.

5.2 ITT connections: complete and incomplete connections

To test container delivery with different ITT connections, a complete and an incomplete ITT system were created. In the complete ITT, we assumed that containers can be moved to any MTRR or RTR (terminal 1, 2, 3, 10 and 11) before being loaded onto the train to the hinterland. Then, we constructed the incomplete ITT network considering the existing current terminal connections. As a result, connections between ECT terminals (terminal 1, 5, 6, 10, 11), Rotterdam World Gateway (terminal 2) and APM terminals (terminal 3 and 4) were excluded. Therefore, containers from the ECT terminals, i.e., terminal 1, 5 and 6, can only be moved to terminal 10 and 11; containers from terminal 4 can only be moved to terminal 3; containers from terminal 2 and 3 cannot be moved to other terminals; containers from other terminals can be moved to any MTRR or MTR. In the incomplete ITT network, only four terminals (terminal 2, 3, 10 and 11) can be used for the hinterland trains.

5.3 Railway timetable: periodic timetable and flexible timetable

Two timetable scenarios are proposed: the periodic timetable and the flexible timetable. In the periodic timetable, each planned train is assigned with a departure time slot. If a train is delayed, then the train will be canceled. In a flexible timetable case, instead of assigning the departure time slots to each train, we assume that there is a departure time slots pool and these slots can be shared among the trains and terminals. So the terminal operator could choose a suitable departure time slot from the pool as long as that time slot is not used by another train. Moreover, in the periodic timetable case, each train has a fixed terminal to depart and a maximum of four trains can depart from each terminal during the planning horizon; in the flexible timetable case, there is no limitation for the number of trains departing from each terminal.

5.4 Test Scenarios and container delivery

The experiments include 24 scenarios, see Table 3. The small transport demand scenarios (DS1 and DS2) are tested with complete and incomplete ITT connections; small and large hinterland trains; and flexible and periodic timetables. In the complete ITT connections, maximal 20 small trains or 10 large trains can depart from each of the five terminals (i.e., terminal 1, 2, 3, 10 and 11); in incomplete ITT connections, maximal 16 small trains and 8 large trains could depart from the four terminals (i.e., terminal 2, 3, 10 and 11). Therefore, the configuration of large transport demand scenarios (DS3 and DS4) and incomplete ITT connection are infeasible and not included in the experiments. The 24 scenarios are solved using IBM ILOG OPL CPLEX OPTIMISER version 12.7.1 on a machine with Microsoft Windows 7 operating system, Intel i5 core 3.2 GHz CPU, 16 GB RAM.

Table 3 Overview of tested scenarios
Full size table

Figure 5 shows the movement of one task in the optimization results. In this case, demand scenario DS2 with incomplete ITT connection was executed. The arcs in Fig. 5 represent 12 TEU containers released from terminal 1 at 0:00 and finally loaded onto a hinterland train departed from terminal 11 at 11:30. Because the incomplete connection was used, these containers had to be sent to terminal 10 or 11. The transshipment operations started at 6:25, and all 12 TEU containers were ready for the ITT trains at 8:35. At 8:45 an ITT train took these containers from terminal 1 to terminal 11. This train arrived at terminal 11 at 9:35 and then containers were dropped off from the ITT train. After that, containers were loaded onto the hinterland train. The loading process ended at 11:20.

Fig. 5
figure 5

Illustration of the optimization results

Full size image

Table 4 gives an overview of the experiment results. The first column is the index of the test scenarios. The second column indicates the number of containers delivered on time to the hinterland. The last three columns show the number of hinterland trains that departed, the average loading rate of the hinterland trains and the computation time. Most of the cases with 600 TEU containers can be solved within 10 min, while some other cases with 800 TEU containers take around one hour to find the optimal solution.

Table 4 Overview of container delivery
Full size table

The complete ITT connection performed better than the incomplete ITT connection. Test scenarios with complete ITT connection (S1–S4, S9–S12) delivered more containers to the hinterland regardless of transport demands and train capacity: on average, 98% of the containers were delivered on time with complete ITT while 94% of the containers were delivered on time with incomplete ITT.

Moreover, the incomplete ITT network puts more pressure on the rail yards. Table 5 shows the number of containers handling operations, i.e., pick-up, drop-off and transfer in two RTRs, for a relevant subset of scenarios. For example, when small trains with periodic timetable are used to transport 600 TEU containers with evenly distributed release time, the rail yards in MTRR and RTR need to perform 606 handling operations in a complete ITT connection (scenario 1), while the figure is 1034 for incomplete connection, i.e., 71% increase. On average, the total number of handling operations increased by 67% and 78% if the incomplete ITT connection was used for DS1 and DS2 respectively. It is also notable that in some complete ITT cases (S4, S11 and S12), no train departed from rail terminal 11, but the system could still deliver more containers than the incomplete ITT.

Table 5 Number of containers handling operations in rail yard of MTRR and RTR
Full size table

Two types of hinterland trains were tested. According to Table 4, the terminal operator should consider smaller trains when using fixed timetables: trains with 40 TEU transported more containers in all scenarios. This increases the flexibility of the system against higher operational costs (more locomotives, more drivers). When using the flexible timetable, the loading rate of smaller trains is higher.

The flexible railway timetable has a promising role in improving the container delivery performance. Table 4 shows that when the transport demand was 800 TEU, trains with a flexible timetable could deliver all containers; when the total transport demand was 600 TEU and the complete ITT was used, trains with flexible timetable could deliver all containers. Trains with fixed timetable could not deliver all containers in any case. It is notable that in the flexible timetable cases, the average train loading rate is lower because fewer trains were cancelled.

Figure 6 shows that in a flexible timetable case, 20 trains were fully loaded while in the periodic timetable, the average loading rate of the 20 trains departed was 92.88%. DS4 was used in these two cases. As shown in Fig. 4b, the peak hours were between 6:00 and 9:00, and the periodic trains departed during the peak hours without fully loading, which could result in lost capacity.

Fig. 6
figure 6

Periodic and flexible timetable

Full size image

5.5 A rolling horizon approach to solving large cases

When solving the problem with smaller transport demand and a periodic timetable, the computation is efficient enough to provide solutions to dispatch the transport and handling operations. The last column of Table 3 shows the CPU time for solving each scenario. Most of the test cases with small transport demand can be solved within 10 min. However, the computation time increases significantly when dealing with larger transport demand and flexible timetable. In this section, a rolling horizon procedure is proposed to improve the computation so that the optimization could also be implemented in practice.

Rolling horizon framework is usually used when solving dynamic problems or when commercial software fails in finding an optimal solution within a reasonable computation time. Wang and Kopfer (2015) solve a dynamic vehicle routing problem with two types of rolling horizon framework. The first one is the rolling horizon with fixed interval and the second type is called request triggered rolling horizon. In the first type of rolling horizon, the length of the planning horizon is fixed and pre-determined. In the second type of rolling horizon, the release of a new transport request will terminate the previous planning horizon and start a new one. Liang et al. (2018) focus on an automated taxi routing problem. With the proposed rolling horizon procedure, real-time transport requests are considered when a new planning horizon starts. Our research uses a rolling horizon with fixed interval because we only consider static transport demand.

In the proposed rolling horizon framework (see Fig. 7), the planning for one day is performed with several iterations. In the first iteration, a planning horizon with fixed length (from Time interval 1 to Time interval 2) is considered. The optimal solution for vehicle routing and container handling is found based on the transport demand and available vehicles in that planning horizon. Then, the solution for Time interval 1, i.e., Result 1, is implemented for dispatching the transport and handling operation and the status of vehicle and containers is recorded as the input of next planning horizon which starts from Time interval 2.

Fig. 7
figure 7

Rolling horizon framework

Full size image

In practice, the rolling horizon framework can be used to consider real-time demand information: in this case, the demand information will be updated at the beginning of each planning horizon. In this study, we use static transport demand data and there is no transport demand released after 21:00. Therefore, we divide the one-day planning into five planning horizon: each horizon covers 8 h. In the first four planning horizon, the solution of the first 4 h is implemented; and in the last horizon, the solution for the entire planning horizon is implemented.

When solving the problem with the rolling horizon, a maximum computation time, i.e., 10 min, is set for each planning horizon. If the optimal solution cannot be found within 10 min, the best solution found will be accepted and the next planning horizon will start. Table 6 shows the computation results with the rolling horizon and optimal solution. For most of the planning horizons, it is possible to finish the computation within the time limit. The rolling horizon algorithm can give good solution compared with the optimal solution: the difference between the rolling horizon and the optimal solution are large in terms of the computation time (the rolling horizon is much faster). However, the performance of the rolling horizon in terms of delivered containers is lower as compared to the optimal solution.

Table 6 Computation time in minutes and number of containers delivered
Full size table

6 Conclusions

This paper focused on the integration of inter-terminal transport (ITT) within the port area considering the transshipment operations and railway timetable. The ITT network was designed based on the terminals in Maasvlakte 1&2, Rotterdam and the problem was formulated with a mathematical optimization model. Our model can help terminal operators to schedule the ITT fleet and RMGs in terminals. The experiments also show that more and flexible ITT connections and a flexible railway timetable can increase the transport performance of containers being delivered to the hinterland.

The existing research has studied a wide range of relatively isolated decision problems of container transport inside a port area (ITT), terminal operations and rail transport to the hinterland. Most of them focused on either operations within single terminal or single transport segments. In our research, an integer programming model is proposed based on a time–space graph. The model optimizes the movements of containers, ITT vehicles and hinterland trains in an integrated way. Moreover, the model can formulate the transshipment operations between different vehicles and the storage yard considering the handling capacity.

Computational experiments are conducted with different transport demands, variations in available ITT connections, hinterland train capacities and railway timetables. The results show that a better ITT connection can improve the container delivery to the hinterland. If the Port authority and terminal operators can reach an agreement to provide more ITT access to each other then they can increase the number of containers delivered on time and reduce the number of handling operations. In the experiments, 98% and 94% of the total containers from the terminals can be delivered to their destination with complete ITT and incomplete ITT respectively. This indicates that the port authority may encourage the coordination between terminals as this increases the performance of the ITT network and its connections to the hinterland. Next, if a more flexible railway timetable is possible, i.e., terminals could have more choices on when the train departs, more containers can be delivered on time. In the experiment, all containers can be delivered to their destination with the flexible timetable and complete ITT connection. When using a periodic timetable, 91% of the container can be delivered with complete ITT connections and 89% of the containers can be delivered with incomplete ITT connections. Also, this means that a better performance of the ITT network and its hinterland connections is possible if more flexibility is introduced by the infrastructure provider.

When using a periodic timetable, smaller trains with higher frequency perform better than large trains with low frequency. Although smaller trains are more expensive, they also offer more flexibility and higher frequencies leading to a better performance in the model (although possibly at higher costs).

Moreover, a rolling horizon framework is proposed to provide solutions with shorter computation time. Each of the 5 planning horizons considers the transport demand for 8 h. By solving the problem based on a shorter planning horizon, the computation time is reduced, however, the number of delivered containers is considerably lower (although the difference in general remains under 10%).

For further research, the model can also be extended to analyze a transport system with inland shipping, railway and trucking, which could be beneficial for the port authority, terminal operator and for the intermodal transport provider. The movement of inland waterway vessel can be formulated in a similar way as for the ITT trains, while the different schedule for the vessels could be studied and analyzed. And the costs and time of using different transport modes should also be considered. In the multi-modal transport system, different objectives should be also considered. For example, minimize the trains delays could be important for the railway operators to reduce the rescheduling costs. Overall, more cooperation and more flexibility introduced into the integrated ITT system and its hinterland rail connections will improve its performance as compared to current operations which are less flexible and less cooperative.