Information Technology Reference
In-Depth Information
competition. NaRC [5] constructed RFQs and accepted offers from suppliers based on
projections for future prices and demand.
For the 2004 competition and in order to provide a disincentive for ordering and
holding large numbers of components in the inventory, a storage cost was introduced
and the pricing formula for the components was altered slightly. However, as it turned
out this did not have a major effect on the agents' strategies regarding their RFQs to the
suppliers during the first few days of the game.
4
Socrates
Socrates is an autonomous trading agent built in Java. It is production-driven, that is to
say, we concentrated on strategies to deal with the suppliers, as despite the modifications
made to the game, obtaining the components was essential to enable one to compete and
acquire orders on the customers' side.
The development of Socrates for TAC SCM 2004 was based on the Agentware
framework as provided by SICS, which includes a set of classes that provide the main
functionality to establish communication with the TAC SCM server and receive all the
events to be able to participate in the competition. The internal functionality of Socrates,
which determines the way in which it keeps and processes information, is based on
Value Object
classes. A Value Object is a design pattern for representing objects as
containers of information [9, 2]. Value Objects are used to represent transient objects
to keep track of information during a TAC game. Hence, every RFQ, supplier offer,
order, PC model, is represented as a Value Object. Socrates builds a number of different
lists for these Value Objects in order to simplify their maintenance. Comparator classes,
which are Java classes that implement the Comparable interface, are then used to sort
the lists. The
Comparato
r classes are defined by specifying the property or properties
of the Value Object class to be used for sorting the list. Once the lists are sorted, it is
easier to manipulate them. Socrates uses a
FileManager
class which is responsible for
reading the configuration files at the beginning of every TAC game. There are two con-
figuration files, the default
aw.conf
and our own configuration file
soc.conf
. The latter
one is used to specify the initial parameters to be used by the agent during the game.
The information contained in the files is then passed on to Socrates. The FileManager
is also responsible for storing information during the game in log files, which are then
used for subsequent analysis.
4.1
Preliminaries
As we are focusing on a production-driven strategy we need to estimate the number
of PCs that can be manufactured to achieve near to 100% utilisation. To determine the
components to be ordered we have to consider the duration of the game (220 days),
and the number of PCs that can be manufactured daily based on the agent's assembly
capacity (2000 cycles). The average number of manufacturing cycles for a PC is:
AvgCycles
=
sum
(
Cycles
i
)
/
16 = 5
.
5 (
i
is the PC model)
The assembly capacity for an agent during the whole game is therefore:
T otalAssemblyCycles
=
Days
∗
DayCycles
= 220
∗
2000 = 440000
