Information Technology Reference
In-Depth Information
AgentGUI
3
, which then provides a bird's eye view of the physical layout. The
Protege
ontology editor serves as a tool for the development of the communication ontology
and configuration interface. The system is structured into core agents, user interface
agents, administrative agents and module agents (see Figure 2). Core agents represent
the different handling devices in a port, but are generally modeled as one generic type
with multiple options of configuration. This provides a flexible approximation of the
reality while reducing the complexity by abstraction.
ContMAS
realizes a decentralised
planning process since agents maintain and are solely responsible for individual plans
for the execution order of container moves. In its basic version
ContMAS
allows the
simple simulation of the activities within a harbor. However, in order to test different
optimization strategies agents can be equipped with “intelligence”, which means that
a specific strategy can be added to each agent. Alternatively, agents can use advisors
in order to come to a better decision. In this paper we will present two already devel-
oped optimization strategies, one which deals with the optimization of the allocation of
container moves to straddle carriers (Section 5), and one to optimize the allocation of
container positions in the yard (Section 6).
Agents:
The core agents are called
ContainerHolderAgents
. Those are the agents which
can pick up, transport (“hold”) and drop containers, one for each individual device or
other actor, such as cranes, ships, straddle carriers, yard areas or apron areas. There are
several other agents in the model. The
HarbourMaster
controls the setup and events
such as creation of a new agent e.g. for a newly arriving ship. The
ControlGUIAgent
provides the graphical interface for the human user. The
RandomGenerator
provides
random numbers or events for simulations. Agents are also used for visualisations such
as a bird's eye map or 3D rendering of the containers held by an agent.
Environment:
The logical structure of the port is modelled as a tree of
Domains
. Each
Domain
lies in exactly one parent
Domain
and can contain several sub-
Domains
.An
agent lives in exactly one
Domain
and can be capable of accessing several other
Do-
mains
. For example, a
Crane
lives in the
Domain CraneRails
and can access the
Domain
TrainRails, ShipBerth
and
StraddleCarrierStreet
to exchange containers with agents
living in those
Domains
. This structure permits to dynamically calculate the shortest
logical path through the port for a container, along with possible alternatives for com-
parison and weighing.
Data Structures:
Agent communication uses a data structure called
TransportOrder-
Chain
(
TOC
) which represents the path of a container through the port as a list of
Trans-
portOrders
, each representing a single step (e.g. ship
crane). Each TOC is marked
with a
TransportOrderChainState
indicating the state of the negotiation, e.g. whether a
call for proposals has been issued, a drop planned, etc.
→
4.2 Simulator Operation
Operation:
All negotiations between the agents are carried out by means of an ex-
tended contract net protocol. We selected the contract net since it is a standard generic
3
Currently
under
development
by
Dipl.-Ing.
Christian
Derksen
and
Nils
Loose
at
University
Duisburg-Essen
http://www.dawis.wiwi.uni-due.de/team/
christian-derksen/
