Agent-based Planning and Simulation of Combined Rail/Road

Transport

Luca Maria Gambardella, Andrea E. RizzoliIDSIA, Galleria 2, CH-6928 Manno, Switzerland

Petra FunkDFKI, Stuhlsatzenhausweg 3, D-66123, Saabrucken, Germany

Abstract

A simulation model of the flow of Intermodal Terminal Units (ITUs) among inland intermodalterminals is presented. The intermodal terminals are inter-connected by rail corridors. Each terminalserves a user catchment area via a road network. The terminal is modelled as a set of platforms, whichare served by a number of gantry cranes and front lifters. Given the schedule of train connectionsamong the terminals, an agent-based system, the Intermodal Transport Planner (ITP) books ITUs ontrains and assigns trucks to deliver them to the source terminal and to pick them up in the destinationterminal. The terminal and rail corridor simulation software has been implemented as a discrete-eventsimulation model, using MODSIM III as development tool. The ITP has been implemented on thebasis of the TELETRUCK system. This research has been developed within the PLATFORM project,funded by the Directorate General VII of the European Community.Keywords: multi-agent simulation, intermodal transport planning, intermodal terminal simulation

1 Introduction

Nowadays many intermodal terminals are stillmanaged without a pervasive support of informa-tion technologies: the terminal management highlyrelies on well-assessed policies, typical of each ter-minal, which have been defined by the managers onthe basis of their experience. In most cases thesepolicies are satisfactory since the terminals havesufficient resources in terms of tracks, equipment,human resources and they can support the currentflows of freight. On the other hand, the growth offreight transport shows a rapidly increasing trendin the short and medium terms, which cannot bemet by the current infrastructures and manage-ment tools. Computer based simulation can pro-vide the decision-makers with the help they needin creating the strategies for development.

The pressure of freight traffic on Europeanroads is pushing the European Community to in-vest and promote intermodal transport as a vi-able alternative to long-haul road transport [1].The PLATFORM project is one of the outcomes

of this policy and we expect that this and otherdemonstrative projects will show the terminal op-erators ways to invest to improve the efficiencyof their management procedures, thus enhancingtheir competitiveness with respect to road-onlyfreight.

One of the aims of the PLATFORM projectwas the implementation of a simulation environ-ment for the assessment of impacts produced bythe adoption of different technologies and manage-ment policies to enhance terminal performances.To achieve this objective, the project needed to en-compass all the phases of an intermodal transportof an Intermodal Transport Unit (ITU), a require-ment for the comparison of the performance of in-termodality against road-only based transport.

An intermodal terminal can be regarded as anode in a network that models the connectivity ofthe origins and destinations in the supply chain.If we look at the performance of this network, weare interested in understanding if it is possible toincrease the throughput of the nodes, that is, ofthe terminals. Whereas the rail networks can sus-

1

tain a marginal increase in traffic, an improvementin the terminals throughput might reduce the per-centage of long-haul transports on the road. Be-cause of this observation, we model the completelogistic chain in a complex network of intermodalterminals in order to understand how intermodaltransport can be put in competition with road-onlybased transport.

2 The PLATFORM architecture

The PLATFORM architecture consists of two sub-systems: the intermodal transport planner (ITP)that manages the planning of the whole intermodaltransport chain from origin to destination for anITU; the simulation system (composed by the roadsimulation, rail simulation, and terminal simula-tion modules) that models and simulates the ITUtransport process, both assessing the feasibility ofthe plans generated by the ITP and evaluates theperformances of intermodal terminals, thanks toa detailed description of the intra-terminal pro-cesses.

The ITP plans the a whole intermodal trans-port task (ITT) for an ITU thanks to:

• Intermodal Planning and Execution Units(IPnEU) – for planning the whole ITT of anITU. They split the ITT into its three mainparts, the initial and final leg on the road andthe main leg by train. They contact the spe-cialised agents for planning, booking, reser-vation of these parts.

• Forwarding Agents – for planning and book-ing the ITT of the ITU by truck. Theseagents are responsible for the planning ofdelivery ITUs to and their pick-up fromterminals. Each forwarder is modelled bysuch a forwarding agent. A broker agentco-ordinates the planning of the forwardingagents of the area around each terminal

• Booking Agent – for booking the ITT of theITU by train. This agent checks for availabil-ity of places on scheduled trains, checkingwhich bookings are possible. The bookingagent then chooses the best one and makesthe reservation.

The simulation system performs the executionof ITTs including internal terminal operations toevaluate their feasibility and their performances.It is composed of:

• Road Simulation – simulates the transport ofthe ITU by truck, as delegated to forwarders.It simulates the flow of incoming and depart-ing trucks at each terminal in the corridor.

• Terminal Simulation – simulates the loading,unloading of ITUs from trucks and trains aswell as storing of ITUs in the intermodal ter-minal. Terminal equipment, loading plat-forms, yard areas and gate procedures aresimulated, in order to demonstrate function-ality of the terminal procedures and poten-tial for improvement.

• Train Simulation – simulates the flow oftrains within the chosen rail corridor. Ac-cording to the train time-tables, the flow oftrains from and to the terminals is simulated,focussing especially the train flow within thechosen corridor.

A graphical user interface (not described in thispaper) allows customising the simulation, to selectthe important parameters, views and maps, and toinspect of the input and output data of the simu-lation.

In the following, first we introduce the ITP(Section 3), then we explain the different compo-nents of the simulation system, the road networksimulation, the rail simulation, and the terminalsimulation (Section 4 and Section 5). Finally, wepresent the system as a whole, detailing the syn-chronisation mechanism between road and termi-nal simulations (Section 7).

3 The intermodal transportplanner

The planning of intermodal transports is per-formed by means of an agent-based model of theintermodal transport chain. The transport ser-vice operators are represented by individual, in-telligent software agents. Each of these agents isequipped with task- and domain-specific planningand scheduling abilities as well as models of their

2

local resources in terms of time, load capacitiesetc. This approach allows for the distribution ofthe tasks to be solved in the processing of inter-modal transport orders.

Multi-agent systems are highly suitable for dis-tributed problem solving as they offer the pos-sibility to divide the main task into small sub-tasks. Moreover such handy subtasks may containoverlapping goals, which are addressed by agentsthrough their interactive abilities, i.e. they nego-tiate about their resources and abilities and elabo-rate co-operative solutions and plans. A more de-tailed introduction to multi-agent systems can befound for example in [2], [3] or [4]. For the inter-modal transport chain in the PLATFORM tool, wehave developed a multi-agent system, which mapsthe whole transport chain from the origin to thedestination loading area of the forwarder. Theforwarders are connected by road to intermodalterminals, which in turn are connected throughthe railway network. In the multiagent systemeach transport operator is represented as an au-tonomous agent. An ITT is planned and negoti-ated in the agent world, as well as co-operativelyexecuted.

The forwarding agents, at the beginning andthe end of the chain, are instances of theTELETRUCK system [5], [6]. The TELETRUCKsystem was designed as an agent-based forwardingsystem, able to manage the business processes offorwarding companies. The TELETRUCK agentsociety is implemented as an holonic agent system.An holonic agent or holon is an agent that is com-posed of sub-agents working together in order topursue a common goal. The users or the othermembers of the agent society can interact with aholon as if it were a single agent. This allows tomodel several level of abstraction in a convenientway. In a holon one agent is distinguished as thehead of the holon. The head co-ordinates the re-source allocation within the holon and controls thecommunication with the rest of the agent society.The head can be equipped with the ability to planfor the sub-agents. These agents have their ownplans, goals, and communication facilities in or-der to provide their resources for the transporta-tion plans according to their role in the society.They can merge together with a Plan’n’ExecuteUnit (PnEU) and form a holon which represents a

complete vehicle, as shown in Figure 1.Agents also represent intermodal terminals.

They consist of a terminal agent, which is the headof the agent society and a booking agent manag-ing the booking requests for the trains handled inthe terminal. This agent comprises the heart ofthe terminal services for the negotiation and plan-ning of ITTs. and represent the commercial de-partments of intermodal terminals. Such a systemis comparable to reservation systems for passengertransport. Booking and reservation systems, eventhough not so common in todays freight traffic,will in the future provide essential support for thesmooth management of fast loading devices withinintermodal terminals such as the Automated Load-ing System, the Krupp Fast Handling Device, orthe Daimler KombiLifter [7].

In order to be able to plan ITTs we designeda third agent type, the Intermodal Plan’n’ExecuteUnit (IPnEU) which extends the TELETRUCKsPnEU. The IPnEU is able communicate with for-warding agents and terminal agents to close thetransport chain. The IPnEU acts like a virtualcargo carrier imposing highly specific requirementson the cargo type. This agent has twofold abilities:during the planning phases of an ITT it negotiateswith the different transport services in order to es-tablish a co-operative transport plan. Later on,during plan execution the agent accompanies thecargo, which is moved through the physical trans-port network in the respective software network.Thus, this agent provides for advanced planningand online tracking of ITTs.

3.1 An agent for intermodal planningand execution

Intermodal plans are usually generated as the re-sult of the interaction between the forwarders andthe terminal companies. We represent the knowl-edge in intermodal transport planning for eachtransport operator, by encapsulating it into theIPnEU which is an agent associated with an in-termodal order. This means the IPnEU plans andexecutes the plans for all the goods to be deliv-ered within the same order and not only for asingle ITU, as it does the PnEU in the standardTELETRUCK system. If an order contains morethan one ITU, it may be splitted over several vehi-

3

Figure 1: Vehicle agents and PnEU (left) forming a holonic vehicle structure (right).

cles. Yet only one IPnEU is supervising the trans-port execution. The IPnEU plans and negotiatesthe intermodal transport of the ITUs it representsand then monitors the execution of the plan, even-tually migrating to other software systems, whilethe ITUs are in transit.

Thanks to its planning capability, the IPnEUhas smooth access to all the transport operatorsin the transport chain to perform the negotiationand planning of an ITT. Moreover, the IPnEU is amobile agent, which accompanies its cargo in theagent world, while the goods are shipped in thephysical world. Mobility in the physical world ismirrored by the ability to migrate through a soft-ware network, following the execution of an inter-modal order from origin to destination. Figure 2illustrates this: the intelligent agent on the top isthe IPnEU during the planning and negotiationphase; the walking agent is the vehicle holon dur-ing the execution and monitoring phase. The smallpuzzle in the hands of the walking agent indicatesthe holonic agent society. The black piece standsfor the IPnEU’s participation in it. The phasesare modelled differently, though we are able to mixthem freely and thus provide for emergency replan-ning during execution or due to new incoming or-ders, allowing for their dynamic insertion into ex-isting plans.

In the next sections we show how the announce-ment of an ITT triggers the inactive IPnEUs (theactive IPnEUs are by definition busy with eitherplanning or executing an order) to enter the plan-ning and negotiating phase. The planning phaseitself is divided into a negotiation phase (Section(3.2)) with preliminary commitment to the servicesrequested (road based transport, rail based trans-port and terminal services) and a final commit-

ment phase (Section 3.3), where the informationgained during the negotiation will be used in or-der to place bookings on trains and to route ve-hicles. The preliminary commitments serve twopurposes: reserve resources during planning andnegotiation and provide a decision and planningbasis for service providers within the intermodaltransport chain.

3.2 Communication and co-operation:negotiating intermodal orders

Customers and transport agents communicate tonegotiate the contract for the execution of inter-modal orders. The customer at the origin requestsan ITT to the forwarder of her choice. She mayannounce the order to several transport operatorsin order to receive and select the most competitiveoffer. Figure 3 shows the details of the negotiationand planning phase.

The forwarder recognises that the order re-quires an intermodal transport and activates anIPnEU to provide for intermodal planning. TheIPnEU splits the order into three parts: the rail-based main leg order which constrains the ordersfor the initial and final road-based legs. The mainleg order, on rail, is passed to the booking agent ofone or more terminals, who then engage in plan-ning it. The result of this activity, the main legplan is communicated back to the IPnEU. If theIPnEU has contacted several terminals, it sendsone of them a preliminary commitment and ad-justs the orders of the initial and final leg to thechosen plan for the main leg (latest arrival timeat the terminal gate, earliest pick up time at thedestination terminal). Other main leg plans arerejected. Planning of the initial and final leg canbe done concurrently. In Figure 3 this is indicated

4

Figure 2: The IPnEU planning and migrating.

by dashed arrows. Planning the initial and finallegs involves the usual TELETRUCK planning andscheduling activity, which results in a holon for ev-ery vehicle. With the information on the wholetransport, the IPnEU can then tell the forwarderthe pick up time at the customers depot (possiblya time window) and the delivery time (possiblya time window) at the final destination. The In-termodal Planning and Negotiation Protocol is anapplication-specific extension and nesting of sev-eral classical Contract Net Protocols [4].

3.3 Results of the negotiation and plan-ning phase

The negotiation and planning phase generates anintermodal transport plan. Such a plan is a com-position of plans for the different transport legs.The intermodal plan is composed of two road-based transport plans and one rail-based plan. Theroad-based plans implement the TELETRUCKapproach, that is, for each vehicle an holonic struc-ture is generated. Each structure is dominated bya PnEU. The IPnEU participates to each one ofthese holonic structures. This is possible, becausean agent can be part of several holons at the sametime.

As in the TELETRUCK implementation,whenever the system plans a road-based transport,the agents representing the involved physical com-ponents form a vehicle holon that is headed by aPnEU. If an ITU that is part of an intermodaltransportation order is transported, not only theagent that represents that ITU but also the IPnEUthat represents the transportation order are incor-porated in the vehicle holon. Precisely, the ITUagent and its IPnEU form a holon that is headed

by the IPnEU and that represents the ITU.For the rail-based transport, the train that

transports several ITUs can be viewed as a holonicstructure that consists of the ITUs, the wagons,and the engine. We do not model the wagons ex-plicitly but represent the whole train by the loco-motive agent. The train holon is composed of theIPnEU agents that represent the intermodal or-ders, the agents representing the ITUs in transit,and the locomotive agent which is the head of thetrain holon.

As a consequence of the domains structure,holons overlap. The agents form holons at the timeof planning and can be members in several holons.The ITU agents are part of the holon that rep-resents the intermodal order, they belong to twovehicle holons for the initial and the final legs, andto a train holon for the main leg. The IPnEUagents exhibit even stronger omnipresence: theyparticipate in the vehicle holons for initial and thefinal legs of each ITU in the order and they arepart of the train holons that carry at least oneof the respective ITUs. This agent society is visu-alised in Figure 4. The picture shows on both sidesroad-based vehicle holons that consist of a PnEU,a driver agent, a truck agent, and a conjunctionof ITU and IPnEU agent. In the middle there isa rail-based train holon that contains the locomo-tive agent, both ITUs and the IPnEU. The IPnEUis part of all holons involved and supervises thewhole transportation chain.

4 The road network simulator

While the planning phase can be compactly de-scribed with the protocol illustrated in Figure 3,

5

Figure 3: The intermodal planning and negotiation protocol.

the execution requires some more elaborated meth-ods and competencies. The execution itself canalso be described in a protocol-like diagram, wheremessages about the result of the execution arecommunicated (Figure 5). Within this figure thegrey arrows indicate the transport control or su-pervision by the IPnEU.

The IPnEU splits the order at hand into a mainleg to be on train and an initial and final leg to beexecuted by trucks. The intervals are based onestimated duration of the different legs. For themain leg it consults the booking agents, while therelative road network area brokers are contactedfor the initial and final legs

When the booking agent and the road networkarea brokers return the booking for the main legand the plans for the initial and final leg, respec-tively, the IPnEU must integrate the three plansinto the intermodal transport plan for the currentorder. If the integration fails, another iterationwith modified time windows takes place.

For the region around a terminal, a roadarea network broker agent is responsible for theorganisation of the initial or final legs. Thisagent is implemented as an autonomous copy of aTELETRUCK system, but without subagents rep-resenting the transport units. It knows about theforwarders in the region and can contact their for-

warding agent, in order to announce the transporttask to them asking for their bids for that task.Modified negotiation and communication facilitieshad to replace therefore the original ones whichwere used normally for the distribution of ordersto the transport subagents.

The forwarding agents of the local forwardersare again implemented as autonomous copies of theTELETRUCK system, of course with their usualsubagents for the transport units and their compo-nents. In extension of the normal TELETRUCKfunctionalities the forwarding agents must be ableto communicate and negotiate with the road net-work area broker. That is, the forwarding agentsnow receive the announcements of the (initial orfinal leg) orders that are returned by the road net-work area brokers and they reply with a bid forthat order. In order to provide the bid, they com-pute their potential plans for executing that orderin collaboration with their transport subagents.The road network area broker selects from the of-fered plans the most suitable and returns it to theIPnEU, which, in turn, integrates it with the mainleg plan and the second road haulage plan.

The trucks generated by the road simulationmodule will then be directed to the intermodalterminal gates. The synchronisation of the roadsimulation module with the terminal simulation is

6

Figure 4: A holonic intermodal transport chain with two road holons and a rail holon.

described later in Section 7. Now we introduce thesimulation of the rail-based leg of the intermodaltransport, which involves the simulation of the in-termodal terminal activities and of the rail corridortransports.

5 The terminal simulator

In the PLATFORM project we modelled the lo-gistic chain as the interaction of road networks,terminals and the rail network. We do not takeinto account decisions taken in the rail network,which is seen as a black box, but we focused onmodelling the effects of decisions taken in plan-ning road transport and the management of theterminals, as requested by the user requirements ofthe project [8]. In the preceding sections we haveexamined what happens outside the gates of theterminal, now, thanks to the terminal simulator,we examine and assess the effects of managementpolicies within the terminal and their side effectson the whole logistic chain.

The terminal simulator (TS) has been devel-oped in MODSIM III [9], a commercially avail-able object-oriented and process-oriented simula-tion language. The adoption of the object-orientedparadigm allowed software components to be de-fined that correspond to their real-world counter-parts and with a similar behaviour. The termi-nal components modelled in the terminal simulatorare:

• the road gate, where trucks enter and leave

the terminal;

• the rail gate, where trains enter and leave theterminal. The rail gate is connected to theshunting area, outside the terminal, wherethe rail network operator shunts trains be-fore they enter the terminal. The rail gateis also connected to the rail tracks inside theterminal;

• the platforms, each composed by a set of railtracks and by a buffer area. The buffer areais a temporary storage area for ITUs that arewaiting to be loaded/unloaded to and fromtrains entering the platform. Each platformis served by a set of gantry cranes, spanningthe platform length and serving the set ofrail tracks and the buffer area;

• the storage area, a longer term (usually 24hours) area to park ITUs. The front lifters,serve the storage area, they serve trucks di-rected to the storage area picking up theITUs and storing them in the storage area.

These components are implemented in the sim-ulation code as classes, using the object-orientedprogramming language provided by MODSIM III.The modeller can easily assemble a rail/road ter-minal model creating instances of these classes.Moreover, since the simulation model reads from adatabase the structure of the terminal model andcreates the instances of the model components, themodeller does not need to write code to create dif-ferent terminal instances. This allows the model

7

Figure 5: Execution protocol of an intermodal order (message and control flows).

to be quite generic and to be able to describe a va-riety of different terminal layouts and equipment.

The modeller creates model instances eitherspecifying some characteristic parameters (e.g. theservice time of a crane) or the subparts of a compo-nent (e.g. the number of rail tracks in a platform).In particular, s/he can define the yard layout: howmany platforms are present in the model, the ca-pacity of the associated buffer areas, the numberof gantry cranes working on the platform, and thenumber of rail tracks in the platform. Only onestorage area can be defined and its capacity mustbe entered too. For each gantry crane, the mod-eller must specify the average number of movesper hour and the crane operating cost per hour.Then, the terminal storage must be defined: thesize of the storage area and the number of frontlifters serving it, with their performances (num-ber of moves per hour and cost per hour). Fi-nally, the modeller defines the terminal interfaceto the external world. The road gate is identi-fied by the number of lanes and the average timeneeded to service a truck. This service time is anaggregate representation of the time required pro-cessing the papers when a truck shows up at theroad gate. The rail gate is represented by the num-ber of shunting tracks, the number of link tracksbetween the shunting area and the terminal. The

user must also specify the average time requiredto move a train from the shunting area into theterminal. This average value is easy to computesince it mainly depends on the distance from theshunting area to the destination rail track.

In the next sections we describe how the sim-ulator handles truck arrivals and departures atthe terminal gate (Section 5.1), and how the trainloading and unloading processes are modelled (Sec-tion 5.2). Remember that ITUs which travel onthe corridor are generated by the IPnEU and theinter simulation communication between the roadsimulator and the terminal simulator is describedin Section 7.

5.1 ITU arrivals and departures

When a truck with an ITU arrives at the termi-nal, it joins a First In First Out queue at the roadgate. Each road gate is represented by a FIFOqueue. The service time of the road gate is a pa-rameter set by the simulation user, who can alsodecide how many road gates are used in the sim-ulation. When the truck has been processed bythe gate and enters the terminal one of these threecases is given: a) the ITU arrives well ahead of thedeadline (the time when the train on which it wasbooked must leave); b) the ITU arrives just before

8

the deadline; c) the ITU arrives after the trainhas left. In cases a) and c) the ITU is placed intemporary storage areas, in case b) a direct trans-shipment on the platform is performed: the truckis directed to a queue associated with the trainloading process and the ITU is directly loaded onthe train. From the point of view of the crane, thiskind of operation has a high priority.

Trains depart from the terminal according to afixed timetable (see Section 6). This constraint isnever violated in the simulation model and there-fore it might happen that some trains depart be-fore all the booked ITUs have been loaded. Suchan event is used as an indicator of a problem interminal management (e.g. insufficient resourcesto sustain the throughput).

When the train arrives to the destination ter-minal, it is directed to the shunting area where itwaits for the availability of the rail gate (it mightbe engaged by another train). In addition, theavailability of a rail track on the trains destinationplatform must be checked. When these precondi-tions are satisfied, the train may enter the terminaland the unloading operations start.

In the meantime, trucks are arriving to pick-upthe ITUs delivered by the train. Truck arrivals forITU pick-up are symmetric to arrivals for delivery,in the sense that trucks arrive generally after thetrain has arrived and the highest number of ITUsis 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 entersthe terminal. According to the availability of theITU, either a direct transhipment on the platformis performed or the truck is directed to storage ar-eas where the ITU has been stocked or to a waitingqueue for incoming trains.

5.2 Train loading/unloading

The proposed modelling approach for train load-ing/unloading operations is platform-centred. Aplatform scheduler is associated with each plat-form, which assigns operations to the availablecranes. The storage area is managed via a FIFOqueue 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 ofoperations is a job. Thus, a sequence of load-

ing/unloading operations for a train correspondsto a job. Each operation has a priority (for in-stance, if the ITU is to be picked-up by a truck).The platform scheduler assigns each operation tothe available cranes, ordering by priority. Opera-tions with the same priority are scheduled with around-robin policy (one ITU for each job).

The order of the operations when loading atrain is the following: first the ITUs on waitingtrucks (direct transshipment) are loaded, secondthe ITUs on the yard. The trucks arriving whenthe corresponding train is being loaded join thequeue of waiting trucks and are given the high-est priority. This allows the loading process tobe quicker and to minimise the time spent by thetrucks waiting for service.

When unloading a train the order is: first movethe ITUs on the waiting trucks, then the remainingITUs. Thus, a truck arriving for pick-up is servedwith the highest priority. The cranes available forthe loading/unloading operation must be allocatedin the current work shift and suitable for the op-eration. The list of the cranes that will be activeduring a given work shift are set by the simulationuser in the resource allocation table.

At least one gantry crane must be allocated atall times to perform both direct truck/train trans-shipment and storage in buffer areas. At least onefront lifter is needed if the storage area must beaccessed. When deciding which resource shouldbe used to carry out an operation, it may happenthat different operations compete for resources. Around-robin resource allocation policy was adoptedto avoid starving and deadlocks.

Crane service time was modelled by a Gaus-sian distribution. In reality, each ITU is served in atime t, which is the average value of the time takento travel along the rail track to pick-up/unload theITU.

6 Rail corridor and rail networksimulation

A rail corridor is a privileged point-to-point rail-way connection between two terminals, and it en-ables intermodal transport to try to compete withroad-only transport not only in terms of cost, butalso in terms of time. From the modelling view-

9

point it consists of the allocation of appropriatetime slots on the rail network. A corridor is thusan abstract representation of a path in a complexrail network.

Exploring the performance of intermodal trans-port over rail corridors was one of the objectivesof PLATFORM project and the characteristics ofthe corridors made its simulation a simple problemto be solved. The simulation of a corridor link isdriven by a timetable, which contains the depar-ture and arrival times of trains. When a train trav-els from an origin terminal to a destination alonga corridor, the simulator makes the train arrive inthe destination terminal after a set time, given bythe arrival time minus the departure time, plus astochastically generated delay, to account for smalldeviations from the expected schedule.

The two nodes of the corridors are terminalmodels that are concurrently running in the samesimulation. A train travelling in a corridor mustbe loaded in the source terminal and unloaded inthe destination terminal. In the source terminal, itis represented as a list of ITU bookings. Bookingare placed by the IPnEU, as described in Section 3,which will send trucks to deliver ITUs according tothe booking details (hour of train departure, typeof ITU, weight allowance, etc.). When the train isloaded and its departure time has arrived, it leavesthe source terminal for its destination on the corri-dor. At the destination, the train is unloaded andtrucks arrive to pick up the transported ITUs.

However, a terminal does not exchange ITUsonly along a corridor, it is also linked to manyother terminals, which often generate the majorshare of the rail traffic (we examined the Veronaterminal in Northern Italy where traffic on theVerona-Munich (Southern Germany) corridor ac-counted only for 15% of the total rail traffic inone week). For this reason, the PLATFORM ter-minal simulator takes into account these externalcontributions by means of the rail network sim-ulation. Again, a very simple simulation modulegenerates train arrivals and departures accordingto a timetable. The difference with the previouscorridor simulation is that departing trains mustnot be transferred to another terminal model, butthey are simply discarded to represent the traf-fic of ITUs brought in by trucks and then leav-ing for other terminals, external to the corridor.

On the other hand, incoming trains bring in newITUs, which are later picked up by trucks, againcontributing to the global traffic in the terminal.Note that the trucks which pick-up and deliverITUs outside the rail corridor are not managed bythe IPnEU agents. For this reason, a stochasticprocess artificially generates them, as described in[10].

The software structure used to model train ar-rivals and departures is a priority ranked queue,where the order is given by the time stamps asso-ciated with the departure and arrival events. Dur-ing simulation, the train generation module insertsarrival and departure events in the Future EventsList [9] of the terminal simulators. When the eventtime is reached, the train is then handled by theterminal rail gate and finally handed over to theinner terminal for the simulation of loading andunloading.

7 Inter simulation communica-tion

The PLATFORM terminal simulation (TS) mod-ule has been designed in order to work in coop-eration with the IPnEU agents. The aim of theIPnEU agents is to synchronise the truck arrivalsin the terminal in order to minimise waiting timesand reduce the queue length at the gates. If theplanning of transport on the road network is wellplanned, the trucks would arrive in the best or-der, so the crane is making incremental moves,which are time efficient, and the required time toload/unload a train would decrease. If the plan-ning is poor, the crane will probably travel backand forth to serve unexpected trucks, thus increas-ing the average service time. Thus, the advantageof planning the road network is that it is possibleto improve the crane performance, since a bettersynchronisation of the truck arrivals would trans-form most operations in direct train/truck trans-shipments.

The TS is therefore fed by the IPnEUs. Thedistributed architecture of the PLATFORM sim-ulation implies that TS and IPnEUs are differentprograms, exchanging data during their execution.In this section we describe the interaction of thetwo programs. Please note that all the processes

10

are symmetric in the sense that the origin terminalin one transport plan can become the destinationterminal in another plan.

7.1 Accessing information to generatetransport plans

The IPnEU agents must interact with the TS toacquire the information required to place bookingson trains. First, an IPnEU queries any terminalto check whether a corridor exists between the ori-gin and destination terminals. If so, the IPnEUscan book places on a train connecting the originterminal with the destination terminal. The traindeparture times from the origin and its expectedarrival time at destination are retrieved from thetimetable of the rail corridor, stored in the TSdatabase. Once a train has been chosen, the IP-nEU fills in the bookings on this train. This proce-dure must be repeated for all the trains that leavethe terminal during the simulation horizon.

The IPnEU must then schedule trucks whichwill deliver the ITU to the origin terminal fromits origin on the road network and that will pick-up the same ITU at the destination terminal, thusbringing it to the final destination. The IPnEUmust therefore generate the arrival of trucks at theroad gate in the origin terminal. This gate is rep-resented as a buffer which is periodically read bythe TS module and used to generate the truck ar-rivals in the terminal model. The origin terminalthen unloads the truck and sends it back to theroad network, writing the truck data in the out-ward road gate.

In the meantime, the TS is loading the train forwhich the ITUs were booked. When the loadingprocess is over, the train leaves the origin terminaland is transferred to the destination terminal viathe corridor.

At the same time, the IPnEU has generated thearrival of a truck for ITU pick-up at the destinationterminal, according to the transport plan. Thistruck is also inserted in the road gate, this time ofthe destination terminal. The terminal simulatoruses this information to generate the truck arrival;it unloads the ITUs from the train on the truckand registers the outgoing trucks in the road gate,which is then accessed by the IPnEU to performthe last leg of the ITU delivery.

7.2 Synchronising the terminal simula-tion with the IPnEU agents

Given the distributed nature of the intermodalchain and the ability of IPnEU agents to migratefrom machine to machine in a computer network,the two programs, TS and IPnEU, might be exe-cuted on different machines, which run at differentclock speed, and their local simulation time caneasily diverge. Lets assume that the two simula-tors start at the same instant, and consequentlyalso their local simulation time is the same. Inprinciple, just after a few units of processing time,the simulation time in the two simulators may havesensibly diverged. For instance, the simulationtime in the IPnEU may lag behind the simulationtime in the TS. In this case, when the IPnEU gen-erates an event (a truck arrival), the TS sees anevent with a time label which is in its past.

In Figure 6 it is graphically represented whathappens if an event arrives after its simulation timehas elapsed. The event D3 should have been exe-cuted by the TS before events I3 and I4. If thereis no possibility to backtrack the simulation, can-celling events I3 and I4 (thus applying the timewarp simulation method), the consequence is thatthe two simulators will proceed at the speed of theslowest of the two.

With the constraint of not being able to usetime warp, because of the simulation environmentcurrently adopted, the best approach, to minimisethe waste of CPU time, is to adopt a unique fu-ture event list (FEL) where both programs writethe next scheduled events. With such a sharedstructure, it would be possible to keep the two sim-ulations synchronised. This is shown in Figure 7,where the same events of Figure 6 are ordered ina single FEL. When the TS starts, it finds thatthe next event is D1, scheduled at time 5. The TSwould then wait that D1 is executed before exe-cuting I1, scheduled at time 7.

The synchronisation algorithm could be basedon the mutual exchange of the next event time.That is, both simulators start at the same time,TS knows that the next local event is scheduled attime 7 and publishes it in a global variable (whichcan be a text file), while ITP knows its next localevent is at time 5. TS then checks if the simu-lation time of event I1 is less than the simulation

11

Figure 6: The Future Event Lists of the two simulations running independently.

time of D1, if not, it inserts a virtual event in its lo-cal FEL, thus jumping directly at time 5, when anevent from ITP could be received. Note that notall the ITP events have an influence on the TS. Ifthe interacting events would be known in advance,the synchronisation could be done on fewer events,but this is difficult to achieve, if not impossible, ina simulation where random events are generated.

8 Conclusions

We have presented an agent-based planner andsimulator for intermodal transport, developed inthe framework of the PLATFORM project. Thesoftware architecture is divided into the Inter-modal Transport Planner, and in the simulationsystem. The former is an agent-based applicationwhich takes care of organising transport planesfor the dispatching of Intermodal Transport Unitsalong the various stages of an intermodal trans-port, from origin to destination. The latter is adiscrete-event based simulator that has been de-signed and implemented to verify the feasibilityof these plans and measures their performances.The simulator also focuses in the detailed mod-elling of the internal terminal processes in orderto let the terminal managers evaluate the impactof new technologies and infrastructures on existingterminals.

9 Acknowledgements

This paper is based on work carried out underthe European Commissions PLATFORM project(http://www.idsia.ch/platform) within the trans-port RTD programme (Task 3.2/7). We also

wish wish to thank: Cosimo Epifani and AdrianoAlessandrini for their contributions in the experi-mentation with the PLATFORM simulation mod-ule, Hans-Jurgen Burckert, Gero Vierke,VolkerRueckel, Andreas Gerber, Ingo Zinnikus, RainerSiedle for their support in the development ofthe Intermodal Transport Planner and NicolettaFornara for her contribution to the design and im-plementation of the Terminal Simulation module.The graphics for the ITP sections have been pre-pared by Jasmin Schneider.

References

[1] Directorate General VII of the EuropeanCommission, Combined goods transport: in-termodality of goods transport, SCADPlusUnion Policy (http://europa.eu.int/scadplus/leg/en/lvb/l24179.htm).

[2] J. Muller (Ed.). Verteilte Kunstliche Intelli-genz: Methoden und Anwendungen; BI Wis-senschaftsverlag, Mannheim, Leipzig, Wien,Zurich; ISBN 3-411-16181-7; 1993.

[3] G. M. P. O’Hare and N. R. Jennings (Eds.).Foundations of Distributed Artificial Intelli-gence. Wiley and Sons, Inc.; ISBN 0-471-00675-0; 1996.

[4] R. G. Smith. The Contract Net Protocol:High-Level Communication and Control ina Distributed Problem Solver. IEE Transac-tions on Computers, Series C-29, 12, pp 1104–1113, 1980.

[5] H.-J. Burckert, K. Fischer, G. Vierke, Trans-portation scheduling with holonic MAS the

12

D1 I1

t=7

D2 D3 I3

t=122

I4

t=180t=5 t=23 t=90t=43

I2

Figure 7: The Future Event List of the two simulation running interleaved in parallel.

TeleTruck approach. In Proceedings of the14th European Meeting on Cybernetics andSystems Research, (Edited by R. Trappl), Vol.2, (1998) 695-700.

[6] H.-J. Brckert, K. Fischer, G. Vierke. Trans-portation Scheduling with Holonic MAS TheTeleTruck Approach. Proceedings of TheThird International Conference on PracticalApplication of Intelligent Agents and Multi-Agent Technology (PAAM98), edited by H.S.Nwama and D. T. Ndumu, 1998.

[7] P. Funk. Fast Loading Devices: Planningand Scheduling Requirements. DFKI Tech-nical Memo No. TM-98-03; DFKI GmbHSaarbrucken, Germany; May 1998.

[8] PLATFORM Consortium, Guidelines for acomputer-controlled freight PLATFORM fora time-tabled railway freight network, user re-quirements and functions. PLATFORM De-liverable D1, 1998.

[9] CACI Products Company, MODSIM III UsersManual, La Jolla, 1997.

[10] A.E. Rizzoli, N. Fornara, L. M. Gambardella,A Simulation Tool for Combined Rail/RoadTransport in Intermodal Terminals. To ap-pear in: Mathematical and Computer Mod-elling, 2002.

[11] P. Funk. A Multiagent System for IntermodalTransport Chains. Dissertation Thesis, Uni-versity of the Saarland, Germany. To Appear.

13