Mathematics and Computers in Simulation 59 (2002) 5771

A simulation tool for combined rail/road transport

in intermodal terminals
Andrea E. Rizzoli , Nicoletta Fornara, Luca Maria Gambardella
IDSIA, Galleria 2, CH-6928, Manno, Lugano, Switzerland

Abstract
A simulation model of the flow of intermodal terminal units (ITUs) among and within inland intermodal terminals
is presented. The intermodal terminals are interconnected by rail corridors. Each terminal serves a user catchment
area via a road network. The terminal is modelled as a set of platforms, which are served by a number of gantry cranes
and front lifters. The user of the simulation model defines the structure of the terminal and the train and truck arrival
scenarios. The train arrivals are defined in a train timetable, while the patterns of truck arrivals for ITU delivery and
pick-up can be either statistically modelled or given as a deterministic input. The simulator can be used to simulate
both a single terminal and a rail network, that is, two or more interconnected terminals. During the simulation, various
statistics are gathered to assess the performance of the terminal equipment, the ITU residence time, and the terminal
throughput. The simulation software has been implemented as a discrete-event simulation model, using MODSIM III
as development tool. The simulator tool has been developed as part of the Platform project, funded by the Directorate
General VII of the European Community. 2002 IMACS. Published by Elsevier Science B.V. All rights reserved.
Keywords: Intermodal transport; Intermodal terminal simulation

1. Introduction

The globalisation of world economy has led to a constant decrease in the cost of transport (95%
of world cargo moves by ship, transport costs account for 1% of the total cost [1]). Nowadays many
intermodal terminals are still managed without a pervasive support of information technologies: the
terminal management highly relies on well-assessed policies, typical of each terminal, which have been
defined by the managers on the basis of their experience. In most cases these policies are satisfactory
since the terminals have sufficient resources in terms of tracks, equipment, human resources and they can
support the current flows of freight. On the other hand, the growth of freight transport shows a rapidly
increasing trend in the short and medium terms, which the current infrastructures and management tools
cannot meet.

Corresponding author. Tel.: +41-91-6108664; fax: +41-91-6108661.
E-mail address: [email protected] (A.E. Rizzoli).

0378-4754/02/$ see front matter 2002 IMACS. Published by Elsevier Science B.V. All rights reserved.
PII: S 0 3 7 8 - 4 7 5 4 ( 0 1 ) 0 0 3 9 3 - 7
58 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

The European Intermodal Association established the working group intermodal terminals, which
defined a set of minimum requirements for the intermodal terminals of the future (http://www.eiango.com/
terminals.html). These standards define the minimum dimensions of a terminal able to guarantee sufficient
traffic concentration and independent economic management using the currently available techniques.
Irrespective, terminal operators prefer to explore whether new management methodologies can improve
the terminal performance before investing in new equipment or enlarging the area of the terminals.
Computer-based simulation can provide the decision-makers with the help they need in creating the
strategies for development.

2. Issues in the simulation of rail/road intermodal terminals

Rail/road intermodal terminals differentiate from maritime intermodal terminals since they are inland
and they are nodes in a tightly interconnected network, composed of the rail and the road networks. They
are usually smaller than their maritime counterparts and the residence time of ITUs in the terminal is
usually much shorter (approximately 24 h). In such terminals, particular care must be devoted to the model
of the arrival and departure processes of trains and trucks at the terminal gate. While it is not the aim of
this paper to enter into the details of what happens beyond the terminal gates, we remind the reader that
a consistent number of researchers have worked on the problem of the simulation and the optimisation
of the rail network (for a review see [2], an application study is presented in [3]) and a comparable,
if not greater, effort has been put into the research on traffic simulation [4]. These studies are of great
importance since their results can be used to model the interfaces of the terminal with the external
world. The task of the modeller is therefore eased and s/he can concentrate on the modelling details of
the terminal.
When integrating the rail, road and terminal components in a unique simulation framework, it is
necessary to ensure the models to be congruent, that is to adopt the same level of resolution with
respect to both time and description of ITUs. For instance, according to the required level of detail, the
intermodal transport can be modelled either as a continuous system, describing the ITUs as a continuous
flow, or as a discrete system, where each single ITUs is represented. If the ITU description in the road
or rail networks is not congruent with the one adopted in the terminal, it is necessary to write ad hoc
models to convert the different types of inputs and outputs. For instance, data on the traffic rate at the
terminal gates, which could be obtained by the simulation model of the road network, can be used to
generate ITUs arrivals and departures in the terminal. In the Platform simulation model we also have
adopted such an approach and it is described in Section 4.2.
Despite the above-mentioned differences between maritime and rail/road intermodal terminals, they
display some common features that are invariant with respect to the modes of transport. For instance,
all terminals must have a yard area where the ITUs are stored. In all terminals, cranes (gantry and
front lifters) move ITUs to and from the various transport means. The ITUs enter and leave terminals
through gates, where decisions are made regarding the destination of the ITUs within the terminal itself.
Besides structural similarities, terminals share common processes such as the efficient storage of the
ITUs on the yard, and the scheduling of loading and unloading operations. The benefit is that much
research has been done on maritime terminals (see for instance [57] on terminal simulation, [7,8]
on optimisation of container scheduling) and it can provide inspiration for application to the rail/road
sector.
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 59

While the similarity of the intermodal structures facilitates the transfer of concepts developed for
maritime intermodal transport to the rail sector, many processes have some distinctive features, especially
regarding the handling of the ITUs. In the maritime transport ITUs are standardised ISO containers and
they are stackable, while ITUs in the combined rail/road transport sector can be containers, semi-trailer,
swap bodies, each one with different characteristics and requiring a different way of handling (e.g. swap
bodies and semi-trailers are not stackable). Another obstacle to the technology transfer is represented by
the information technology systems currently installed in rail/road terminals: while maritime terminals
have been investing in the IT sector for a long time, rail/road terminals have not done the same. The
consequence is that often data, such as the physical location of the ITU on the yard, which are necessary
to implement efficient management strategies, are not available.
There are some signals that things are changing. The pressure of freight traffic on European roads is
pushing the European Community to invest and promote intermodal transport as a viable alternative to
long-haul road transport [9]. The Platform project is one of the outcomes of this policy and we expect
that this and other demonstrative projects will show the terminal operators ways to invest to improve
the efficiency of their management procedures, thus enhancing their competitiveness with respect to
road-only freight.

3. The Platform project

The Platform project was financed by the IV Framework Programme of the Directorate General VII
(transport) of the European Community. One of the aims of the project was the implementation of a
simulation environment for the assessment of impacts produced by the adoption of different technologies
and management policies to enhance terminal performances. To achieve this objective, the project needed
to encompass all the phases of an intermodal transport of an ITU, a requirement for the comparison of
the performance of intermodality against road-only-based transport.
An intermodal transport along a rail corridor connecting two terminals T1 and T2 can be divided into
three legs. The initial leg describes the trip from the origin of the ITU to the first terminal T1. This leg
is usually managed by a forwarding company owning a truck fleet. Trucks pick-up and deliver ITUs
in the companys user catchment area. The second leg is the transport from T1 to T2 by train. The
railway companies owning the rail network manage this leg. Often, different rail companies cooperate
in transnational transports. The third and final leg is the transport from T2 to the ITU destination that is
again managed by a forwarding company.
To represent the intermodal transport in all its parts the Platform integrated simulation environment
will be composed of three modules: the road network planning and simulation module, which plans the
management of the forwarders orders and simulates the traffic of trucks on the road network; the terminal
simulation module, which simulates the terminal nodes and the change of transport mode, from truck to
train and back; the corridor simulation module, which simulates the rail network connecting the terminals.
These three modules are designed to work in parallel in order to produce results on the performance of the
integrated rail/road network. Typically, the road planning and simulation module accepts intermodal
transport orders for transport of an ITU from city to city. It then books a place for the ITU on one of
the train connecting two intermodal terminals and then schedules truck delivery and pick-up of the ITU.
The scheduled truck delivers the ITU in the terminal, that is, this information is provided as input to the
terminal simulation module. This module takes care of handling the ITU where it was booked on, then
60 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

sends the train to the corresponding terminal. This action is handled by the corridor simulation module.
At the receiving terminal similar actions are performed: the ITU is unloaded from train and loaded on
the pick-up truck. The truck is passed back to the road planning and simulation module, which routes it
to its final destination.
In this paper, we present the software component of the Platform project dedicated to terminal and
corridor simulation. A thorough description of the road planning module can be found in [10] and its
theoretical basis in [11].
An intermodal terminal can be regarded as a node in a network that models the connectivity of the origins
and destinations in the supply chain. If we look at the performance of this network, we are interested in
understanding if it is possible to increase the throughput of the nodes, that is, of the terminals. Since the
rail network can sustain a marginal increase in traffic, an improvement in the terminal throughput might
reduce the percentage of long-haul transports on the road. Because of this observation, we model the
internal processes in the intermodal terminals in order to understand how an increase in the intermodal
traffic affects the terminal performance. In the next section, the modelling assumptions to simulate the
terminal are described.

4. The Platform simulation model

The analysis of the user requirements, gathered from an in-depth literature review and from interviews
to intermodal operators through Europe [12], identified the need to model three main processes: the
loading/unloading of ITUs onto/from the train; the storage of ITUs on the yard; the arrival and departure
process of ITUs by truck.
Modelling these processes requires a resolution of the model at the level of the single ITU move and this
led to the selection of the discrete-event simulation paradigm. This approach is particularly apt to describe
the inner workings of a terminal, for instance to evaluate the train loading and unloading processes, but
its computational cost can be excessive to simulate a real network of intermodal terminals. Nevertheless,
the choice of a discrete model cannot be regarded as a dead-end for further investigations, since it can be
employed to calibrate a continuous black-box model of the terminal, once the statistical distributions of
its inputs and outputs are given [13].
The Platform terminal simulator has been developed in MODSIM III [14], a commercially avail-
able object-oriented and process-oriented simulation language. The adoption of the object-oriented
paradigm allowed software components to be defined that correspond to their real-world counterparts
and with a similar behaviour. The terminal components modelled in the terminal simulator are as
follows:
The road gate, where trucks enter and leave the terminal.
The rail gate, where trains enter and leave the terminal. The rail gate is connected to the shunting area,
outside the terminal, where the rail network operator shunts trains before they enter the terminal. The
rail gate is also connected to the rail tracks inside the terminal.
The platforms, each composed by a set of rail tracks and by a buffer area. The buffer area is a temporary
storage area for ITUs that are waiting to be loaded/unloaded to and from trains entering the platform.
Each platform is served by a set of gantry cranes, spanning the platform length and serving the set of
rail tracks and the buffer area.
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 61

The storage area, a longer term (usually 24 h) area to park ITUs. The front lifters, serve the storage
area, they serve trucks directed to the storage area picking up the ITUs and storing them in the storage
area.
These components are implemented in the simulation code as classes, using the object-oriented pro-
gramming language provided by MODSIM III. The modeller can easily assemble a rail/road terminal
model creating instances of these classes. Moreover, since the Platform simulation model reads from
a database the structure of the terminal model and creates the instances of the model components, the
modeller does not need to write code to create different terminal instances. This allows the Platform
simulation module to be quite generic and to be able to model a variety of different terminal layouts and
equipment.
The modeller creates model instances either specifying some characteristic parameters (e.g. the service
time of a crane) or the subparts of a component (e.g. the number of rail tracks in a platform). In particular,
she/he can define the yard layout: how many platforms are present in the model, the capacity of the
associated buffer areas, the number of gantry cranes working on the platform, and the number of rail
tracks in the platform. Only one storage area can be defined and its capacity must be entered too. For each
gantry crane, the modeller must specify the average number of moves per hour and the crane operating
cost per hour. Then, the terminal storage must be defined: the size of the storage area and the number of
front lifters serving it, with their performances (number of moves per hour and cost per hour). Finally, the
modeller defines the terminal interface to the external world. The road gate is identified by the number of
lanes and the average time needed to service a truck. This service time is an aggregate representation of
the time required processing the papers when a truck shows up at the road gate. The rail gate is represented
by the number of shunting tracks, the number of link tracks between the shunting area and the terminal.
The user must also specify the average time required to move a train from the shunting area into the
terminal. This average value is easy to compute since it mainly depends on the distance from the shunting
area to the destination rail track.
In the next sections we describe how the terminal model can be embedded in the simulation of
an intermodal transport by rail corridor simulation (Section 4.1), how truck arrivals and departures
at the terminal gate can be modelled (Section 4.2), and how the terminal components work together
(Section 4.3).

4.1. Rail corridor and rail network simulation

Intermodal transport involves transporting ITUs on a fully interconnected network, but intermodal
corridors are commonplace. A corridor is a privileged point-to-point railway connection between two
terminals. The creation of rail corridors made possible for intermodal transport to compete with road-only
transport not only in terms of cost, but also in terms of time. Exploring the performance of intermodal
transport over rail corridors was one of the objectives of Platform project and the characteristics of the
corridors made its simulation a simple problem to be solved. The underlying hypothesis is that a corridor
is an abstract representation of a path in a complex rail network. The simulation of a corridor link is
driven by a timetable, which contains the departure and arrival times of trains. When a train travels from
an origin terminal to a destination along a corridor, the simulator makes the train arrive in the destination
terminal after a set time, given by the arrival time minus the departure time, plus a stochastically generated
delay, to account for unexpected events.
62 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

The two nodes of the corridors are terminal models that are running in the same simulation. A train
travelling in a corridor must be loaded in the source terminal and unloaded in the destination terminal. In the
source terminal, it is represented as a list of ITU bookings. Booking are placed by forwarding companies,
which will send trucks to deliver ITUs according to the booking details (hour of train departure, type of
ITU, weight allowance, etc.). When the train is loaded and its departure time has arrived, it leaves the
source terminal for its destination on the corridor. At the destination, the train is unloaded and trucks
arrive to pick-up the transported ITUs. The generation of truck arrivals and departures is described in
Section 4.2.
However, a terminal does not exchange ITUs only along a corridor, it is also linked to many other
terminals, which often generate the major share of the rail traffic (we examined the Verona terminal in
northern Italy where traffic on the VeronaMunich (Southern Germany) corridor accounted only for 15%
of the total rail traffic in 1 week). For this reason, the Platform simulator takes into account these external
contributions by means of the rail network simulation. Again, a very simple simulation module generates
train arrivals and departures according to a timetable. The difference with the previous corridor simulation
is that departing trains must not be transferred to another terminal model, but they are simply discarded
to represent the traffic of ITUs brought in by trucks and then leaving for other terminals, external to the
corridor. On the other hand, incoming trains bring in new ITUs, which are later picked up by trucks, again
contributing to the global traffic in the terminal.
The software structure used to model train arrivals and departures is a priority ranked queue, where the
order is given by the time stamps associated with the departure and arrival events. During simulation, the
train generation module inserts arrival and departure events in the future event list [14] of the terminal
simulators. When the event time is reached, the train is then handled by the terminal rail gate and finally
handed over to the terminal internal processes for loading and unloading.

4.2. Simulating truck arrivals at the road gate

The simulation of the truck arrival process is needed to complete the description of the terminal input
and output flows, besides the ITU traffic generated by the rail corridor and the rail network.
Trucks arrive at the terminal to deliver ITUs, which are then loaded on departing trains, and to pick-up
ITUs, which have arrived by train. In the first case, trucks usually arrive before the train leaves, while in
the second case trucks usually arrive after the train arrival, so that they can minimise the length of stay in
the terminal. These remarks are confirmed by the observed data.
The Platform simulation module allows for two modes of truck arrival generation: manual and auto-
matic. The manual generation of truck arrivals is particularly useful to perform trace-driven simulation,
where recordings of truck arrival events are stored in time series, later fed into the simulator. This approach
is extremely useful to validate the model [15].
When trace-drive data are not available, or when the simulation user wants to test alternative arrival
patterns, an algorithm is used to automatically generate stochastic arrivals, according to a statisti-
cal distribution. To implement the automatic arrival module, we first calibrated and then validated a
model on the observed data. The ability of the model in reproducing the observed data turns out to be
useful when the modeller wants to add new trains in the terminal simulation, while maintaining the same
truck arrival pattern. On the other hand, its simple parameterisation (only one parameter) allows the
modeller to generate different arrival patterns, modifying the parameter value. The model calibration and
validation is reported in the next paragraphs.
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 63

Fig. 1. The percentage of truck arrivals bringing ITUs to be loaded on a given train. The x-axis represents the time before
departure. A few minutes before the train leaves, all the ITUs have arrived (100% of arrivals). This data sample is an instance of
the measured data.

Fig. 1 reports the observed percentage of truck arrivals for a given train as a function of time before
the train departure. Note the flat area in the curve, which lies in the area comprised between 18 and 24 h
before train departure. That area corresponds to the road gate closing time, when trucks cannot enter
the terminal. In the model we disregarded this feature for the moment and the observed data is fitted
to an exponential curve y = ex (R 2 = 0.74). The parameter is estimated and is used to perform a
random variate generation using the formula x = ln(1u)/ where u is given by a uniform distribution
U(0, 1) and x is the time before departure in hours. The data generated using the model are plotted in Fig. 2
against the observed data. The parameter should be calibrated for different train classes (e.g. long-haul
and shuttle), but we have presently assumed that it is a global parameter describing the arrivals for all
trains.
The simulation algorithm uses the above formula to generate truck arrivals for each train arrival and
departure (except for the train travelling on the corridor). For each ITU booking (for departing trains)
and for each ITU stowage (for incoming trains) a truck arrival is generated. In this algorithm we also
accounted for the road gate closing period. While the random variate generation algorithm creates arrival

Fig. 2. The data plotted in Fig. 1 is now compared to the data artificially generated.
64 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

times in the middle of the gate closing period, the truck generation algorithms either anticipate or delay
these arrivals in order to better represent the real truck arrival distribution. Finally, truck arrivals are then
inserted in the future event list of the simulator.

4.3. Simulation of terminal processes

In the previous sections, we have explained how the Platform simulation module generates train and
truck arrival events. In this section, we describe what happens to the trains and trucks when they enter
the terminal model. In an intermodal terminal it is interesting to examine the processes with reference
to the modal change, that is, ITU arriving by truck and departing by train, and vice versa. For this reason,
we present the terminal processes following their input and output paths.

4.3.1. ITU arrival by truck and departure by train

When a truck with an ITU arrives at the terminal, it joins a first in first out (FIFO) queue at the road
gate. Each road gate is represented by a FIFO queue. The service time of the road gate is a parameter set
by the simulation user, who can also decide how many road gates are used in the simulation.
When the truck has been processed by the gate and enters the terminal one of following three cases is
given:
1. the ITU arrives well ahead of the deadline (the time when the train on which it was booked must
leave);
2. the ITU arrives just before the deadline;
3. the ITU arrives after the train has left.
In the first case, the train might have not arrived yet. Then, the truck is directed to join a queue associated
with the buffer area of the platform where the train will arrive. In principle, the ITU should be placed
close to the rail track where the train is expected, but the Platform simulation module does not model the
details of the spatial location of the ITUs on the yard. This modelling assumption was made since spatial
location data, commonly available in maritime terminals, was not available in most of the information
systems of the rail/road terminals under study. The ITU is therefore placed in the buffer area, shared by
all the rail tracks in the same platform. It might happen that the buffer area is full; in this case, the truck
is directed to the storage area, where a front lifter will unload it. Note that at least two crane moves are
needed, one to unload the truck on the yard and another one to pick-up the ITU from the yard and put it
on the train.
If the ITU arrives just before the deadline and the train is currently being loaded, the truck is directed
to a queue associated with the train loading process and the ITU is directly loaded on the train. From
the point of view of the crane, this kind of operation has a high priority. In this situation, only one crane
operation is required to directly transfer the ITU from the truck to the train.
Finally, if the ITU arrives after the train has left, the truck joins the queue at the storage area where it
is unloaded by the front lifters. The ITU is added to the late-arrivals list, which contains the ITUs that
missed their train and that have to be rebooked on another train.
In Fig. 3 we have represented the structure of the queuing network associated with the arrival by
truck/departure by train process.
Trains depart from the terminal according to a fixed timetable (see Section 4.1). This constraint is
never violated in the simulation model and therefore it might happen that some trains depart before all
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 65

Fig. 3. The structure of the queueing network that represents the arrival by truck/departure by train process. Trucks join the
road gate in queue, then they are directed to one of the terminal internal queues: RT queue is associated with the railtrack
(there could be more than one RT queue in platform with many railtracks), while the BA queue and the SA queue are associated
with the buffer area and the storage area, respectively. The RT and BA queues are served by the gantry crane pool (composed
by two cranes in the example), while the SA queue is served by the front liner pool. Trains leave through the rail gate, where a
queue implements the sharing of the gate resource.

the booked ITUs have been loaded. Such an event is used as an indicator of a malfunction in the terminal
processes.

4.3.2. ITU arrival by train and departure by truck

When the train arrives to the destination terminal, it is directed to the shunting area where it waits for
the availability, of the rail gate (it might be engaged by another train). In addition, the availability of a
rail track on the trains destination platform must be checked. When these preconditions are satisfied, the
train may enter the terminal and the unloading operations start.
In the meantime, trucks are arriving to pick-up the ITUs delivered by the train. Truck arrivals for ITU
pick-up are symmetric to arrivals for delivery, in the sense that trucks arrive generally after the train has
arrived and the highest number of ITUs is picked up a few hours after train arrival.
When an empty truck arrives at the terminal, it waits in a queue at the gate and then enters the terminal.
Four alternatives are given: (1) the requested ITU is stored in the storage area; (2) the ITU has already
been unloaded from the train and it is stored in the buffer area; (3) the ITU is still on the train, waiting
to be unloaded; (4) the truck has arrived before the train. In the first case, the truck is directed to the
storage area, where it joins the job queue at the front lifters. In the second case, the truck is directed to
66 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

the platform, where it joins the job queue at the platform. In the third case, the truck also joins the queue
at the platform, but its priority is higher, since the objective of the terminal is to maximise the number of
direct transfers between the train and the truck. Finally, if the requested ITU is not in the terminal, the
truck waits for its arrival in a dedicated queue.

4.3.3. Train loading/unloading

In this section, we detail how we modelled the train loading/unloading operations to give a complete
picture of the Platform terminal simulator.
The proposed modelling approach for train loading/unloading operations is platform-centred. A plat-
form scheduler is associated with each platform, which assigns operations to the available cranes. The
storage area is managed via a FIFO queue which accesses the pool of front lifters.
Trains are modelled as sets of ITUs to be moved. Each move is an operation and a sequence of operations
is a job. Thus, a sequence of loading/unloading operations for a train corresponds to a job. Each operation
has a priority (for instance, if the ITU is to be picked-up by a truck). The platform scheduler assigns each
operation to the available cranes, ordering by priority. Operations with the same priority are scheduled
with a round-robin policy (one ITU for each job).
The possible operations performed by a gantry crane are: (1) loading an ITU on a wagon of a departing
train from a truck or from the buffer area; (2) unloading an ITU from a wagon of an incoming train either
to a truck or to the buffer area; (3) loading an ITU to a truck from the buffer area; and (4) unloading an
ITU from a truck to the buffer area.
The order of the operations when loading a train is the following: first the ITUs on waiting trucks (direct
trans-shipment) are loaded, second the ITUs on the yard. The trucks arriving when the corresponding
train is being loaded join the queue of waiting trucks and are given the highest priority. This allows the
loading process to be quicker and to minimise the time spent by the trucks waiting for service.
When unloading a train the order is: first move the ITUs on the waiting trucks, then the remaining
ITUs. Thus, a truck arriving for pick-up is served with the highest priority.
The cranes available for the loading/unloading operation must be allocated in the current work shift
and suitable for the operation. The list of the cranes that will be active during a given work shift are set
by the simulation user in the resource allocation table.
At least one gantry crane must be allocated at all times to perform both direct truck/train trans-shipment
and storage in buffer areas. At least one front lifter is needed if the storage area must be accessed. When
deciding which resource should be used to carry out an operation, it may happen that different operations
compete for resources. A round-robin resource allocation policy was adopted to avoid starving and
deadlocks.
Crane service time was modelled by a Gaussian distribution. In reality, each ITU is served in a time t,
which is the average value of the time taken to travel along the rail track to pick-up/unload the ITU.
The Platform simulation module has been designed in order to work in cooperation with an intermodal
transport planner (ITP) module. The aim of the ITP module is to synchronise the truck arrivals in the
terminal in order to minimise waiting times and reduce the queue length at the gates. If the planning
of transport on the road network is perfect, all the trucks would arrive in the optimal order, so the crane
is making incremental moves, which are time efficient, and t decreases. If the planning is poor, the crane
will probably travel back and forth to serve unexpected trucks, thus increasing the average service time.
If the crane has to serve more than one train and has to switch among tracks, it is assumed that t is
incremented by a fixed quantity to represent the time taken to change track. The information regarding
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 67

the time of delivery for an ITU is known in advance only if a road-dispatching module is present. Thus,
the advantage of planning the road network is that it is possible to improve the crane performance,
since a better synchronisation of the truck arrivals would transform most operations in direct train/truck
trans-shipments.

5. Simulation experiments

Many important European terminal operators were involved in the Platform Consortium and they
provided both data series, used to generate input scenarios for the simulated terminal, and terminal
structures, reproduced in the modelling environment. In particular, the terminal structural parameters are
described in a projects deliverable [12].
As stated in Section 3, the Platform project has a broader scope than the simulation of a single terminal,
the Platform integrated simulation environment includes an intermodal transport planner [11] to schedule
the transport of the ITUs in the road network. When two or more terminals are interconnected, rail
corridors are also simulated and ITUs can be exchanged among the terminals. The Platform integrated
simulation environment will thus allow simulating all the three legs of the ITU trip: from origin to the
terminal on the road network, from terminal to terminal on the rail corridor, from terminal to destination
on the road network. The Platform integrated simulation environment is managed via a user friendly
graphical user interface [10]. The GUI was developed by ETRA (Valencia, Spain), one of the partners
in the project. The GUI can be also used to drive the stand-alone terminal simulator and it provides an
interface to access the scenario data and the simulation parameters that are stored in a set of database
tables.
The simulation user can modify structural parameters, simulation parameters and input scenarios. All
of this can be easily done using the GUI which accesses a database where all the parameters are stored.
In the following sections, we detail how we set-up simulation experiments in order to evaluate terminal
management alternatives and we examine the results.

5.1. The experimental set-up

The experiments were performed on the model of the Quadrante Europa intermodal terminal, located
in Verona, Italy, and operated by Cemat SpA.
Two road gates (with a single queue), four platforms (named A, B, C, and D), two yard cranes per
platform and three front lifters are present in the current configuration of the terminal. After having
defined the structure of the terminal (the number of platforms and their capacity, the number of rail
tracks, the capacity of the storage area), the simulation user must define the pieces of equipment and their
performances, expressed as the average number of moves per hour. The user can specify the resource
allocation in detail: for each piece of equipment it is possible to specify in which work shifts it is active.
The work shift pattern is also user-customisable.
Before launching a simulation, the input scenarios must be defined. They are composed by a train
timetable which records train arrival and departures. The TrainGenerator simulation module (described in
Section 4.1) takes care of generating the corresponding arrival and departure events during the simulation.
Truck arrivals for ITU pick-up and delivery can both be specified as input scenarios read from historical
databases to perform trace-driven simulations, as shown in Section 4.2.
68 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

Finally, the user enters the simulation horizon and the simulation can start. The state of the simulation
model must be initialised. For this purpose, the actual simulation starts 1 day before the start time as
specified by the user. This allows the simulation program to set-up the initial queues at the road and rail
gates and to initialise the yard areas, thus avoiding the problems due to starting the model from an empty
state.

5.2. The alternative comparison

Three management alternatives were explored: alternative 0 consists in replicating the current manage-
ment practices, in order to calibrate the model; alternative 1 is based on the hypothesis that the adoption
of computer aided management tools decreases the performance of the rail gate procedures; alternative 2
sees the enhancement of the crane equipment, to speed-up trans-shipment operations.
In alternative 0 the average road gate processing time was set to 6.5 min. It was observed an average
waiting time of trucks at the road gate of 18.06 min and a mean residence time of ITUs in the terminal of
489 min. Fig. 4 shows the frequency distribution of the residence times. Despite the average value being
quite low, there are some instances when ITUs spend much more time on the terminal yard.
These simulation outputs reasonably matched the observed values of 18 min for the road gate waiting
time and of 12 h for the mean residence time. Unfortunately, not much more quantitative data was available
for model validation.
In alternative 1 we observe that the adoption of computer aided management (CAM) tools has an
impact on the processing time at the road gate. Different values of the gate processing time result in
different average waiting times for trucks queuing at the gate, as reported in Table 1. The situation at the
road gate is also represented by the graphs reported in Figs. 5 and 6, where the number of queued trucks
is plotted against simulation time. It is evident and expected that a lower processing time reduces the
average number of trucks in the queue, but from Table 1 we can also observe that a small increment in
the gate processing time can have a serious impact on the gate queues. This situation can be explained
thinking of the road gate as an M/M/1 queue [16]. In this queue model, the waiting time is known to tend
to infinity when the ratio of inter-arrival rate over the service rate tends to 1. This is an indicator that the

Fig. 4. Histogram representing the frequency distribution of the ITU residence time. The average value is 489 min.
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 69

Table 1
The relation between the processing time at the road gate and the average waiting time for trucks queuing at the gate
Processing time (min) Waiting time (min)

5.0 9.96
6 13.42
6.5 (alternative 0) 18.06
7 29.14
8 62.42

Fig. 5. The number of trucks in the queue waiting to enter at the road gate plotted against simulation time for = 7 min. The
simulation starts with 10 trucks already waiting at the road gate.

terminal management must be very careful in the operation of the road gate and that even the current
situation (alternative 0) could decay, given that the processing time is an average value which depends
on many factors, some of them unforeseeable.
In alternative 2 we examined the impact on the terminal performance of the use of improved trans-
shipment equipment, thus we increased the performances of the yard cranes by 30%, letting the road gate
processing time at the value of alternative 0 (6.5 min). We observed a decrease of the mean ITU residence

Fig. 6. The number of trucks in the queue at the road gate plotted against simulation time for = 6 min.
70 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771

time down to 481 min, which was not an indicative change. It can be inferred that a better synchronisation
between the road network and the terminal should improve the overall performance. Planned truck arrivals
can be used as a mean to decrease the total transport time in an intermodal transport, thus making it more
attractive than road-only transport. Forthcoming studies based on the use of the Platform integrated
simulation environment will deal with this hypothesis.

6. Conclusions

We have presented the terminal simulator component of the Platform project. This module describes
the processes taking place in an intermodal rail/road terminal and is based on the discrete-event simu-
lation paradigm. The basic processes of the flow of the ITUs in the terminal have been considered in
the model. The simulation user can define the terminal structure and test alternative input scenarios to
evaluate the impact of new technologies and infrastructures on existing terminals. An equally relevant part
of the Platform project is dedicated to the study of the impact of road network scheduling on intermodal
transport. In this study, the presented terminal simulator plays the important role of the bimodal node in
the transport network.

Acknowledgements

This paper is based on work carried out under the European Commissions Platform project (http://
www.idsia.ch/platform) within the transport RTD programme (Task 3.2/7). The project has been coordi-
nated by Ingegneria dei Trasporti, Rome, Italy and the Consortium brings together many of the leading
experts in Europe in the fields of telematics and transport project evaluation. The authors wish to thank
Cosimo Epifani and Adriano Alessandrini for their contributions in the experimentation with the Platform
simulation module.

References

[1] S. Taggart, The 20 tonne packet, Wired 7 (10) (1999).

[2] J.-F. Cordeau, P. Totla, D. Vigo, A survey of optimisation models for train routing and scheduling, Transportation Sci. 32 (4)
(1998) 380404.
[3] M. Lewellen, K. Tumay, Network simulation of a major railroad. In: D.J. Medeiros, et al. (Eds.), Proceedings of the 1998
Simulation Conference, SCS, Washington, DC, 1998, pp. 11351138.
[4] M. Pursula, Simulation of traffic systemsan overview, J. Geogr. Information Decision Anal. 3 (1) (1999) 18.
[5] Y. Hayuth, M.A. Pollatschek, Y. Roll, Building a port simulator, Simulation 63 (3) (1994) 179189.
[6] L.M. Gambardella, G. Bontempi, E. Taillard, D. Romanengo, G. Raso, P. Piermari, Simulation and forecasting in an
intermodal container terminal, in: A.G. Bruzzone, EJ.H. Kercklioffs (Eds.), Proceedings of the 8th European Simulation
Symposium, SCS, Genoa, Italy, 1996, pp. 626630.
[7] L.M. Gambardella, A. Rizzoli, M. Zaffalon, Simulation and planning for intermodal container terminal, Simulation 71 (2)
(1998) 107116.
[8] E. Kozan, P. Preston, Genetic algorithms to schedule container transfers at multimodal terminals, Int. Trans. Operational
Res. 6 (3) (1999) 311329.
[9] Directorate General VII of the European Commission, Combined goods transport: intermodality of goods transport,
SCADPlus Union Policy (http://europa.eu.int/scadplus/leg/en/lvb/124179.htm).
 A.E. Rizzoli et al. / Mathematics and Computers in Simulation 59 (2002) 5771 71

[10] Platform Consortium, Implementation of an integrated computer simulation environment for the Platform scenarios,
Platform Deliverable D4, 1998.
[11] H.-J. Brckert, K. Fischer, G. Vierke, Transpoitation scheduling with holonic MASthe TeleTruck approach, in: R. Trappl
(Ed.), Proceedings of the 14th European Meeting on Cybernetics and Systems Research, Vol. 2, 1998, pp. 695700.
[12] Platform Consortium, Guidelines for a computer-controlled freight platform for a time-tabled railway freight network, user
requirements and functions, Platform Deliverable D1, 1998.
[13] J.P.C. Kleijnen, Experimental design for sensitivity analysis, optimization, and validation of simulation models, in: J. Banks
(Ed.), Handbook of Simulation, Wiley, New York, 1998, pp. 173223.
[14] CACI Products Company, MODSIM III Users Manual, La Jolla, 1997.
[15] J.P.C. Kleijnen, B. Bettonvil, W. van Groenendaal, Validation of trace-driven simulation models: a novel regression test,
Manage. Sci. 44 (6) (1998) 812819.
[16] J. Walrand, An Introduction to Queueing Networks, Prentice-Hall, Englewood Cliffs, NJ, 1988.