Cover ERCIM News 56

This issue in pdf
(64 pages; 8,7 Mb)

Cover ERCIM News 55
previous issue
Number 55
October 2003:
Special theme:
Machine Perception

all previous issues

Next issue:
April 2004

Next Special theme:
Games Techlology

About ERCIM News

Valid HTML 4.01!

< Contents ERCIM News No. 56, January 2004

Multi-Agent System Technology in a Port Container Terminal Automation

by Vicent J. Botti

Scientists at Universidad Politécnica de Valencia have been working on a solution to a port container terminal management, specifically the automatic allocation of containers. Given its inherent complexity, we propose that multi-agent systems are the most suitable method for addressing this problem.

Agent/multi-agent systems have become an important field within artificial intelligence research. They have found a number of applications, including control processes, mobile robots, air-traffic management and intelligent information retrieval.

Here we present a multi-agent system for solving the automatic allocation problem in a container terminal. The operations carried out in such terminals are among the most complex tasks in the transport industry. This is due to three factors: the diverse range of entities performing operations, their interaction with a dynamic environment, and the distributed nature of the problem, in which independently functioning systems directly affect each other through their actions.

Existing centralised and sequential applications for container terminal management are now insufficiently flexible to respond to changing management styles and the highly dynamic variations in loading/unloading requirements. Traditionally, the entire terminal is controlled by centralised software, which limits the expansion and reconfiguration capabilities of the system. Using hierarchical organisation forces the grouping of resources into permanent, tightly coupled sub-groups, within which information is processed sequentially by a centralised software supervisor. This may result in much of the system being shut down by a single point of failure, as well as contributing to plan fragility and increased response overheads.
The multi-agent system model seems an adequate framework to overcome such problems through the design and development of an application that is flexible, adaptable, versatile and robust enough for the efficient management of a container terminal.

It is critical that once in port, the turn-around of a cargo ship be as fast as possible. An average cargo liner spends 60% of its time in port, and a cost in the order of US$1000 per hour is associated with this. Consequently, the container allocation process must be directed towards minimising cargo ship stowage time. This is the main objective of the optimisation of the global performance allocation process.

Container terminal management is a very complex system, and traditional solutions decompose the problem into several sub-problems, each representing one particular aspect. While the set of operations to be conducted in the terminal is very extensive, existing approaches share some common features:

  • the Marine Side Interface focuses on the loading and unloading of containers. Normally two or three gantry cranes (GC) are used to move containers for each ship
  • the Transfer System transfers containers between the apron and the container storage yard. Yard trucks (YT) perform transports within the terminal. Transtainers are used to pick up or to put down a container on the storage area of the yard (see Figure 1)
  • the Container Storage System allocates and controls containers in the yard (see Figure 2)
  • the Land Side Interface handles interactions with the land transportation modes.
Figure 1: Yard map.
Figure 1: Yard map.

Figure 2: Transtainer.
Figure 2: Transtainer.

System Architecture
Figure 3 shows the system architecture, in which we divide the problem into sub-problems, each of which is solved by a specific agent. These agents are mainly characterised by their independence from the rest of the system elements. They are able to coordinate and to communicate decisions to the rest of the system. Communication between agents is done by means of asynchronous messages, which are based upon the FIPA-ACL standard. The proposed distributed approach enhances flexibility, efficiency and robustness. Five agent classes can be found in this system:

  • ship agents determine the ships’ loading/unloading sequence
  • stevedore agents manage the ships’ loading/unloading process
  • service agents distribute the containers in the port terminal
  • transtainer agents optimise the use of these machines
  • gate agents interact with the land transport (I/O of containers by land).
Figure 3. System Architecture.
Figure 3. System Architecture.

Ship Agents
In response to the arrival of a ship (ship agent creation event), the system creates a new ship agent for this ship and its load profile. Its goals are to minimise gantry crane idle time, the ship’s loading/unloading time, and the derived costs from the stowage process. This work is closely related to that of the stevedore agents, with which the ship agent must coordinate.

Each ship agent faces a scheduling problem in which a set of resources (the cranes) must be assigned to the different operations (loading/unloading of containers), thereby establishing a resource use time (loading/unloading time). This requires that the various ship agents active at any time must coordinate with each other to minimise clashes between assigned cranes.

Stevedore Agents
For any given gantry crane, stevedore agents try to obtain the most appropiate scheduling in order to manage container stowage. The agent must know the gantry crane loading/unloading sequence, which yard trucks are assigned to this crane and the positions of the various containers within the terminal (this information is provided by the relevant service agents). The agent therefore coordinates with active ship agents and service agents, and attempts to minimise both empty movements of the machinery employed and the number of machines necessary for the internal transfer.

Service Agents
The terminal is divided into services, with each being assigned specific stacking ranges. The main goal of a service agent is to determine the appropriate allocation for containers arriving in the terminal from a specific service, and the most suitable configuration for that portion of the yard controlled by the agent. To do this, the agent must know the yard map of its assigned portion, the container characteristics (type, length, weight, destination port, ship) and the stacking factor. The agent must also coordinate with other service agents in order to resolve conflicts, such as reallocation of containers where their assigned stacks are full.

In solving the configuration problem, service agents must maximise stacking density in their yard portions. The service agent launches this process automatically when it considers it to be necessary, based on criteria such as time, stack allocation conflicts (slots without use or cargo ships that run out of reserved areas), low stacking density etc.

Transtainer Agents
Each transtainer is modelled as an autonomous agent whose goal is to perform container-stacking operations efficiently. A transtainer agent must minimise the transtainer’s empty movements. To do this, it obtains the most efficient sequence for moving the container to or from its correct position in the yard. Each agent waits for stacking requests from the various service agents, which inform the transtainer agent of the location of containers to be loaded to vessels or external trucks, or where containers being unloaded from vessels or trucks are to be placed.

Gate Agents
A gate agent controls the arrival or departure of a container by land. The agent manages the assigned terminal gate, informing the corresponding service agent of the arrival of new containers (in order to store them) and of the arrival of trucks (in order to retire containers from the yard). For instance, when a container arrives, the gate agent checks the accuracy of its data, and if the data is correct, asks for a container location from the service agent responsible for the service to which the container is assigned. Once the location is known, this is communicated to the truck, which delivers it to the appropiate stack. A similar process occurs for containers leaving the terminal.

Internal and external interactions (between the various agents and with system users respectively) are shown in Figure 4. FIPA standards have been followed as far as possible in implementing this prototype. In doing so, a set of auxiliary agents has been created:

  • wrapper agents provide access to the database and communicate with external software
  • the UDMA (User Dialogue Management Agent) is an interface agent with human users
  • the UPA (User Personalisation Agent) manages the explicit profiles and preferences of registered human users.
Figure 4. System Interactions.
Figure 4. System Interactions.

There is also an agent platform (AP) to support the entire architecture. It provides the following services: yellow pages, white pages, a communication channel and an agent platform security manager.

Please contact:
Vicent J. Botti, Universidad Politécnica de Valencia/SpaRCIM