Intelligent Software Agents: Intelligent Agents For The Supply Chain Online Research Institute

TME3
Final Report
COMP667
Intelligent Software Agents

by

Marty Boogaart
Student ID: 9502090
and
Francois Nadeau
Student ID: 2517245

Professor: Chunsheng Yang
Athabasca University
July 31, 2006

Table of Contents
1 INTRODUCTION................................................................................................................................................1
- GOAL ...............................................................................................................................................................1
o What did we try to do? .............................................................................................................................1
o Who would benefit?..................................................................................................................................1
- PREVIOUS WORK .............................................................................................................................................1
o What related work has other people done?..............................................................................................1
o When do previous approaches fail/succeed? ...........................................................................................2
- APPROACH.......................................................................................................................................................2
o What approach did we try?......................................................................................................................2
o Under what circumstances do we think it should work well? ..................................................................2
o Why do we think it should work well under those circumstances?...........................................................2
2 METHODOLOGY...............................................................................................................................................2
- WHAT PIECES HAD TO BE IMPLEMENTED TO EXECUTE OUR APPROACH?...........................................................2
- FOR EACH PIECE... ............................................................................................................................................3
o Were there several possible implementations? ........................................................................................3
Agent......................................................................................................................................................................... 3
User Interface............................................................................................................................................................ 3
Simulation Wrapper .................................................................................................................................................. 3
Data Store ................................................................................................................................................................. 3
o If there were several possibilities, what were the advantages/disadvantages of each? ...........................3
Agent......................................................................................................................................................................... 3
User Interface............................................................................................................................................................ 4
Data Store ................................................................................................................................................................. 6
o Which implementation(s) did we do? Why?.............................................................................................6
Agent......................................................................................................................................................................... 6
User Interface............................................................................................................................................................ 6
Data Store ................................................................................................................................................................. 6
o What did we implement? <== Include detailed descriptions ..................................................................6
Agent......................................................................................................................................................................... 6
SCCORI Simulation Costing Information................................................................................................................. 6
Variable Notations .................................................................................................................................................... 8
ParanoidAgent........................................................................................................................................................... 8
ConsiderateParanoidAgent...................................................................................................................................... 10
RBPushAgent (Rules Based Push).......................................................................................................................... 11
RB_PullSpikeAgent ................................................................................................................................................ 12
RB_PullRandomAgent............................................................................................................................................ 14
RulesBasedAgent .................................................................................................................................................... 15
User Interface.......................................................................................................................................................... 16
Simulation Wrapper ................................................................................................................................................ 17
Data Store ............................................................................................................................................................... 17
o What didn't we implement? Why not? ....................................................................................................17
Agent....................................................................................................................................................................... 18
User Interface.......................................................................................................................................................... 18
Simulation Wrapper ................................................................................................................................................ 18
Data Store ............................................................................................................................................................... 18
3 RESULTS............................................................................................................................................................18
- HOW DID WE MEASURE SUCCESS? ..................................................................................................................18
o Best Possible Random Simulations ........................................................................................................19
The Facts................................................................................................................................................................. 19
A Simple Analysis - First Order Approximation..................................................................................................... 19
o Best Possible Spiked Simulations...........................................................................................................20

The Facts................................................................................................................................................................. 20
A Simple Analysis - First Order Approximation..................................................................................................... 20
An Empirical Estimate ............................................................................................................................................ 21
- WHAT EXPERIMENTS DID WE EXECUTE?.........................................................................................................22
- PROVIDE QUANTITATIVE RESULTS. ................................................................................................................22
ParanoidAgent......................................................................................................................................................... 22
ConsiderateParanoidAgent...................................................................................................................................... 23
RBPushAgent (Rules Based Push).......................................................................................................................... 23
RB_PullSpikeAgent ................................................................................................................................................ 23
RB_PullRandomAgent............................................................................................................................................ 24
RulesBasedAgent .................................................................................................................................................... 24
- WHAT DO OUR RESULTS INDICATE? ...............................................................................................................24
o Introduction............................................................................................................................................25
o Data Summary........................................................................................................................................25
o ANOVA Results ......................................................................................................................................26
o Means Comparison Results....................................................................................................................26
4 DISCUSSION......................................................................................................................................................27
- OVERALL, IS THE APPROACH WE TOOK PROMISING?.......................................................................................27
- WHAT DIFFERENT APPROACH OR VARIANT OF THIS APPROACH IS BETTER?....................................................28
- WHAT FOLLOW-UP WORK SHOULD BE DONE NEXT? .......................................................................................28
- WHAT DID WE LEARN BY DOING THIS PROJECT?.............................................................................................28
5 CONCLUSION...................................................................................................................................................29
APPENDIX A SOFTWARE PACKAGE..............................................................................................................A
REFERENCES ...........................................................................................................................................................C

Athabasca University COMP667, Tutor Marked Assignment 3 Final Project 27 July 2006
Francois Nadeau & Marty Boogaart Page 1
1 Introduction
- Goal
o What did we try to do?
The goal of our project was to research and develop a web-based application to allow
software agents to interact with students while using the Supply Chain Collaboration
Online Research Institute (SCCORI) supply chain simulation. This application interacts
with the simulation through the HTML user interface provided by SCCORI, and
therefore functions independently from this system and does not require any
modifications of the SCCORI site.
o Who would benefit?
The main purpose of the system is to allow students to use the SCCORI simulation
without having four human players.
- Previous Work
o What related work has other people done?
Others have created the SCCORI Supply Chain Simulation, which challenges students to
minimize product costs under varying scenarios.
The SCCORI supply chain simulation tool allows its users to experience the constraints
and functioning of a business supply chain. All of the players in the simulation are given
a role to play in the chain, and are able to purchase items in a turn-by-turn manner. Figure
1 demonstrates the simulation flow.

Figure 1 SCCORI Simulation Supply Chain
The SCCORI supply chain penalizes players who are unable to deliver items to the next
player in the chain. Therefore, players are encouraged to keep items in inventory to
minimize the chance of back-logs occurring. However, this strategy is not ideal since the
simulation associates a cost for the storage of items. Also, there is a fixed container-
shipping cost, which penalizes small orders. Therefore, the best overall strategy is for the
four players to cooperate with each other in order to minimize the total amount of
inventory, transport cost, and the occurrence of back-logs.
Students are expected to form into groups of four in order to occupy each of the four
positions in the supply chain (i.e., retailer, wholesaler, distributor, and manufacturer).
To our knowledge, no one has attempted to provide intelligent agents to occupy one or
more of these positions. Our goal was to not only create agents that would perform as
well as knowledgeable human players, but to also to create agents that used simple and
predictable (albeit poor) strategies.
o When do previous approaches fail/succeed?
Problems occur when one or more students are unavailable to occupy their assigned
positions. This forces other players to open two or more browser windows in order to
occupy the missing players position(s). This can be both confusing and time consuming.
Another failure of the present system is that some users may not understand a particular
strategy, or they may choose not to play a consistent strategy. This can be frustrating to
the student who is seriously trying to use the SCCORI simulation to test supply chain
management techniques.
- Approach
o What approach did we try?
Our approach proceeded as follows:
A) Create the infrastructure components.
B) Create and document various agents with different supply-chain strategies.
C) Analyze the results repetitive execution of the agents in the simulation.
Work item A in this list involved the creation of an Object Oriented application, and did
not present a significant challenge to the development of this project.
Work item B required us to develop agents capable of following various business
strategies.
The last work item, item C, required us to analyze the performance of our intelligent
agents. The main purpose was to characterize our agents in order to provide a variety of
agents to serve different purposes. This task required us to retrieve the simulation results
from the SCCORI simulation site and to analyze these results with Excel spreadsheets
and advanced statistical tests.
o Under what circumstances do we think it should work well?
We believe that this system is capable of functioning along side other humans as long as
human-to-agent is not required. This is because we did not have time to provide an
interface to allow the humans to interact with the agents.
o Why do we think it should work well under those circumstances?
We designed it to work well under those circumstances, because these conditions were
the requirements for this project.
2 Methodology
- What pieces had to be implemented to execute our approach?
We desired to create four pieces, as shown in Figure 2 below, but time constraints limited
us to the three critical ones: Agent, User Interface, and Simulation Wrapper. Due to the
lack of the Historic Data piece, we had to rely on manually downloading the simulation
results from the SCCORI simulation site rather than simply pulling them from our own
database. This, however, did not diminish the projects success, since we were able to
retrieve all of the required information from the SCCORI website.

Figure 2 System Architecture
- For each piece...
o Were there several possible implementations?
Agent
Several implementations of Intelligent Agents were possible. Some that we considered
include:
logical (rules based), fuzzy logic
decision-tree learning, genetic search
social rules based (i.e., communicating)
User Interface
We identified three possibilities for the implementation of the user interface; a server side
web application, a client side application, or integrating it within the SCCORI web site.
Simulation Wrapper
We identified two possible implementations for allowing us to communicate with the
SCCORI web site; the creation of a headless component which would be capable of
interpreting the HTML code generated by the SCCORI web site, or the modification of
the SCCORI web site to allow us to communicate with the use of XML based documents.
Data Store
The persistence layer would have been constructed with the use of an
Object-to-Relational mapping tool, such as Hibernate. This is in accordance to industrial
best practices. Another less efficient implementation would have been to use JDBC.
o If there were several possibilities, what were the advantages/disadvantages
of each?
Agent
logical (rules based), fuzzy logic
Advantages of the logical agents are that they are relatively easy to program and their
behaviour is immediately available for observation. A disadvantage of the logical
agents is that the rules can get complex if you allow them to.
Upon discovering that in SCCORI simulations all spiked runs are identical, we realized
that a genetic search agent could discover the best possible strategy for us. However,
the disadvantage of this approach is that each SCCORI simulation takes roughly half-
an-hour. With four agents playing each thirty-cycle simulation, there are 120 possible
entries to consider. That many degrees of freedom would require more simulation runs
than we had time to for, and therefore we did not implement such a scheme.
Neural networks suffer from the same problem as the genetic search agent.
At first decision trees appeared attractive, but considering that an agent may order zero
to one-hundred (or more) items, their discrete nature would require too many leaves for
each possible situation. Furthermore, given our time constraints, the task of creating a
pedagogy to teach such a decision tree agent was too daunting.
Communicating agents also appeared initially attractive, and given sufficient time, we
would have liked to create one.
A basic communication mechanism which used the Observer pattern was created, but
unfortunately we were unable to complete specifications for an agent which would be
able to be optimized through communication. The main problem with the construction
of such an agent was the need to create different agent logic for each of the SCCORI
roles available.
Two other issues dissuaded us from constructing agents which were able to
communicate. (1) In push mode, the players can only see their own stocking levels and
they are not allowed to communicate with each other. In such a situation, our agents
should live by the same rules. (2) In pull mode, the players (and our agents) can see all
of the stock levels, so there is really no need to communicate, since our agents can
deduce the same logic as what would be communicated. For instance, our rules-based-
pull agents monitor the Retailers stock-on-hand and their suppliers stocking levels to
enable them to act in ways that benefit both their own situation and that of the overall
supply chain.
User Interface
We identified three possibilities for the implementation of the user interface; a server side
web application, a client side application, or integrating it within the SCCORI web site.
Web Application
Description
The creation of a server side application which would allow its
users to control the agents from a web browser.
Advantages
o Students don't need to install an application.
o Centralized control of the agents created.
o Simple agent-to-agent communication mechanism can be
used.
Disadvantages
o Limited number of concurrent agents.
o Requires to be hosted on a server.

Client Side Application
Description
The construction of an application which would be executed by
the students computers.
Advantages Un-limited number of concurrent agents can be created.
Disadvantages
o Requires a distributed agent-to-agent communication
platform.
o Students need to install an application on their own
computers.
o De-centralized control of the agents created.

Integration with the SCCORI website
Description
The agents could have been integrated directly inside the
SCCORI web site. This would of required modifications of the
SCCORI source code to integrate agent-based methodologies.
Advantages
o Ease of use.
o Greater control of agent use.
Disadvantages
o Dependence on the SCCORI web site source code.
o The authors wanted to construct agents, not only an
intelligent software component.

Simulation Wrapper
Headless Web Browser
Description
The creation of a component which is capable of parsing the
HTML code from the SCCORI server, and enters inputs on our
behalf.
Advantages
o Ease of implementation.
o Independence from the SCCORI web site source code.
Disadvantages
o Requires the parsing of HTML code which was deign for
human usability, and therefore contains formatting tags
which are not needed by the wrapper.

Modification of the SCCORI web site
Description
The addition of an XML based communication channel on the
SCCORI web site.
Advantages
o Clear API definition for the agent-to-server communication.
o The SCCORI server would be able to distinguish between
human and agent players.
Disadvantages
o Future modification of the SCCORI server would need to be
replicated in both communication channels (the HTML and
XML interface).
o Students need to install an application on their own
computers.
o De-centralized control of the agents created

Data Store
The use of database for persistent storage is a standard practice in software development
projects, and therefore will not be further discussed.
o Which implementation(s) did we do? Why?
Agent
We implemented logical/non-social agents for the reasons stated above.
They are relatively easy to program. By carefully studying the SCCORI simulations,
we were able to deduce a number of rules of thumb that could be easily implemented
in propositional logic.
Their behaviour is immediately observable. Considering that each simulation takes
roughly thirty minutes, errors in design need to be ferreted out early on.
Communications is not allowed in push simulations and not necessary in pull
simulations.
User Interface
We decided to create a web-based user interface for two reasons. First we believed that
some students may not be willing to download and install an application, but that they
will be more willing to try a web application. Secondly, we did not want to embed our
code within the SCCORI web site because we wanted to make this project as independent
as possible from this site. In this way, it was are goal to create agents who's behaviour
could not be distinguished from a human player.
Simulation Wrapper
We decided to create a communication wrapper because we believed that this would be
easier then modifying the SCCORI web site source code. Another reason can be found in
this project's philosophy, which was to construct a separate component which could
interface with the SCCORI web server, without needing any modifications of the target
server.
Data Store
We did nothing, and therefore introduced no bugs in this section.
o What did we implement? <== Include detailed descriptions
Agent
We implemented six different agents: Paranoid, Considerate Paranoid, RB_Push,
RB_PullSpike, RB_PullRandom, and RulesBased. Detailed descriptions of each follow.
Before discussing the agents logic, we need to understand the SCCORI simulation
costing information. Also, some common notation will simplify the discussions. The next
two sub-sections discuss costing information and agent notation respectively. These are
followed by detailed descriptions of each of the six agents.

SCCORI Simulation Costing Information
The SCCORI User Manual (Gregoire, 2003) describes how cycle and total costs are
calculated. The intellegent agents need this information to decide their best course of
action (Note: the Paranoid agent is not intelligent and does not use the costing
information).
Cycle Cost
This cost is calculated each time a player places an order, even an order of zero.
( )
( )
( )
( ) t BackLogCos entory BackLogInv
st HandlingCo nHand InventoryO
ost ContainerC ntainers NumberOfCo
t ProductCos dered QuantityOr CycleCost
+
+
+
=

Total Cost
The total cost is simply a running total of all cycle costs, plus the cost of the starting
inventory.
( ) ( )
+ =
n
t ProductCos ventory StartingIn CycleCost TotalCost
1

Unit Cost
Unit cost is the price per unit ordered, based on your performance. With high costs, the
cost per unit will be higher. To keep a good unit cost, maintain a low inventory, order full
containers, and never run into a backlog.
ventory StartingIn d toryOrdere TotalInven
TotalCost
UnitCost
+
=
Transportation Information
Type Container Size Container Cost Capacity
Truck 20 feet $10 60 units
Truck 40 feet $20 120 units
Train 20 feet $20 60 units
Train 40 feet $30 120 units
Plane 20 feet $35 60 units
Plane 40 feet $45 120 units
Ship 20 feet $40 60 units
Ship 40 feet $60 120 units
Transportation Notes
1. Although, the SCCORI simulation indicates the Type, it does not immediately
indicate the Container Size.
2. The default simulations all run with a 20 foot Truck.
3. Given points 1 and 2, the Rules Based agent will always assume a 20 foot truck.
- Thus:
o shipping charges for 60 units is $10 (16.7 cents per unit)
o shipping charges for 61 units is $20 (32.8 cents per unit)
o it is important to ship at or near capacity, but never just over capacity
- Per item shipping charges range from:
o a minimum of 16.7 cents per unit to
o a maximum of 10 dollars per unit

Variable Notations
Not all agents use all these variables; but, the rules-based agents use most of them.
- supplier: is WHOLESALER, DISTRIBUTOR, MANUFACTURER for RETAILER,
WHOLESALER, DISTRIBUTOR respectively.
- sp.SOH: the current stock on hand held by the agent's supplier
- sp.LTD1: the amount which was ordered one cycle ago by the supplier
- sp.LTD2: the amount which was ordered two cycles ago by the supplier
- sp.LTD3: the amount which was ordered three cycles ago by the supplier
- sp.Stock: the total stock in supplier's SOH and in transit to supplier
- my.SOH: the current stock on hand inventory held by the agent
- my.LTD1: the amount which was ordered one cycle ago by the agent
- my.LTD2: the amount which was ordered two cycles ago by the agent
- my.LTD3: the amount which was ordered three cycles ago by the agent
- re.SOH: the current retailer's stock on hand
- re.orderReceived: the most recent order place on the retailer
- re.BO: is retailer seriously back logged? (TRUE or FALSE)
- invMax: maximum number of items which the agent can have in its supply chain
- my.InvMax: maximum number of items that this position wants to stock up to
- safetyLevel: SOH trigger level below which the agent needs to order product
- containerSize: maximum number of items in a shipment (assume 60 units)
- Order: the maximum amount that needs to be ordered
- minOrder: minimum order to keep down shipping costs (use half a container)
- remainder: Order modulo containerSize (remainder = Order % containerSize)
- isSpiked: is TRUE or FALSE if a spike has occurred

ParanoidAgent
Algorithm Definition
The Paranoid Agent is a purely reactive agent (Wooldridge, 2002). Each turn, this agent
orders the amount of items missing from its On Hand inventory in order to keep it
100% full.
Analysis
Let
- my.SOH be the current On Hand inventory held by the agent
- my.LTD1 be the amount which was ordered one cycle ago by the agent
- my.LTD2 be the amount which was ordered two cycles ago by the agent
- my.LTD3 be the amount which was ordered three cycles ago by the agent
- invMax be the maximum number of items which the agent can have in the supply
chain
Then we get
( )
( )
3 . 2 . 1 . .
0 0
0
LTD my LTD my LTD my SOH my invMax remainder
remainder Order
remainder remainder Order
Agent
=
<
>
=

Assumptions
- The system does not allow agents to order more items than invMax. Therefore
remainder will always be greater than or equal to zero.
Advantages
- Agent should minimize penalties from Back Logs.
- Cooperative agent since subsequent players can count on receiving items quickly
from this agent.
Disadvantages
- Does not consider the previous player in the chain. That is, this agent will order even
if the next player does not have the items On Hand, which will cause that player to be
penalized by Back Logs.
Results
Four ParanoidAgents played all positions on ten Random-Push simulations.
- The results are the average and standard deviations of cycle 30 of each run.
- To simplify comparisons to other agents:
o the average unit cost is the simple average of all four agents' unit costs
o the Total Costs is the sum of all four agents' total costs

Back Order Logic
To simplify the logic and also to ensure robustness, the agents do not maintain a
memory of previous orders. This allows agents to enter a simulation at any cycle, which
is good for stopping and restarting later.
The SCCORI simulation does not provide data as to how many items are backlogged
by the agent's supplier. Any backlogged item is considered in the agent's supply chain
even though it does not show up in the sum of SOH, LD1, LD2, and LD3. This is a
problem for the Paranoid agent which will order whatever it thinks that it still needs. In
a backlogged situation, this often causes the agent to order too much, causing the
SCCORI simulation to announce an invalid order and then to wait for the agent to try
again. This is captured by the agent's invalidOrder() method which employs the
following logic to: first try to set the order placed equal to the order received, and in the
event that fails, to simply place an order of zero so that the SCCORI server can carry
on. This logic is a compromise between placing a good order and providing a quick
response.
Antecedent Consequent Comments
Order > orderReceived set Order = orderReceived Try to just replenish the last order.
Order <= orderReceived set Order = 0 Something else is wrong; carry on.

ConsiderateParanoidAgent
Algorithm Definition
- The Considerate-Paranoid Agent is a slightly improved Paranoid agent. Each turn,
this agent will order the amount of items which is missing from its On Hand
inventory in order to have it 100% full; but, it will not cause a considerate supplier to
post a backlog.
- A considerate supplier is one that attempts to maintain adequate stock for its
customers. A supplier that allows the inventory to drop below the Safety Stock level,
has insufficient product in transit to recover to that level and still does not place an
order is considered inconsiderate.
- This agent does not need to be considerate when placed in the MANUFACTURER
position, because the factory can always deliver - it does not suffer backlog penalties.
In the MANUFACTURER position the agent reverts to a simple Paranoid Agent.
- This agent is only effective in the Pull mode where it can see all of the other agents
stock and order numbers.
Analysis
Let
- supplier be WHOLESALER, DISTRIBUTOR, MANUFACTURER for
RETAILER, WHOLESALER, DISTRIBUTOR respectively
- sp.Order be the amount just ordered by the agent's supplier
- sp.SOH be the current On Hand inventory held by the agent's supplier
- sp.LTD1 be the amount which was ordered one cycle ago by the supplier
- sp.LTD2 be the amount which was ordered two cycles ago by the supplier
- sp.LTD3 be the amount which was ordered three cycles ago by the supplier
- my.SOH be the current On Hand inventory held by the agent
- my.LTD1 be the amount which was ordered one cycle ago by the agent
- my.LTD2 be the amount which was ordered two cycles ago by the agent
- my.LTD3 be the amount which was ordered three cycles ago by the agent
- invMax be the maximum number of items which the agent can have in the supply
chain.
- theSafetyStock be the minimum amount of stock desired before an order must be
made
Then we get
( )
( )
3 . 2 . 1 . .
3 . 2 . 1 . .
0 0
0
LTD my LTD my LTD my SOH my invMax remainder
LTD sp LTD sp LTD sp SOH sp talStock supplierTo
remainder Order
remainder remainder Order
Agent
=
+ + + =
<
>
=

( ) SOH sp remainder
remainder tock theSafetyS talStock supplierTo
. , min return else
return ) ( if <

Assumptions
- The system does not allow agents to possess more items than invMax. Therefore
remainder will always be greater than or equal to zero.
Advantages
- Agent should minimize its own Backlog penalties
- Agent should minimize its supplier's Backlog penalties
- Cooperative agent since subsequent players can count on receiving items quickly
from this agent
Disadvantages
- Does not minimize stocking charges in that it always tries to maintain maximum
stock rather than sufficient stock
- Does not minimize shipping costs in that it will order small quantities rather than a
full truck-load
- Consider three positions. A Considerate-Paranoid supplier may appear to be
inconsiderate if that agent's supplier is backlogged (or had very little stock). The first
agent does not look farther than its supplier and so may punish its supplier with a
backlogging order even though that supplier is being considerate to the next supplier
(who is already backlogged).
Back Order Logic
The Considerate Paranoid agent uses exactly the same back-order logic as Paranoid
agent. Please see Paranoid agents back-order logic for details.

The remaining four Rules Based agents are reasoning agents that use propositional
logic to choose the best course of action (Russell, 2003).

RBPushAgent (Rules Based Push)
Objectives
- Designed for push runs, this agent cannot see the other agents' stock levels.
- It attempts to maintain adequate stocks while minimizing shipping costs.
The Facts
- Order = my.InvMax my.SOH my.LD1 my.LD2 my.LD3
- my.InvMax = [ 90 | 45 | 80 | 80 ]
for [ RETAILER | WHOLESALER | DISTRIBUTOR | MANUFACTURER ] respectively.
- safetyLevel = 55
- containerSize = 60
- minOrder = 30
The Rules
Order < 0 set Order = 0 Do not order negative quantities.
my.SOH > safetyLevel set Order = 0 Is an order really needed?
Order < minOrder set Order = 0 Avoid small shipments.
Order > containerSize AND
remainder < minOrder
set Order = remainder Is there enough for another container?
Order > 90 set Order = 90
Orders > 90 seem unreasonable, but blind
agent may try, so force 90.
Back Order Logic
To simplify the logic and also to ensure robustness, the agents do not maintain a
memory of previous orders. This allows agents to enter a simulation at any cycle, which
is good for stopping and restarting later.
The SCCORI simulation does not provide data as to how many items are backlogged
by the agent's supplier. Any backlogged item is considered in the agent's supply chain
even though it does not show up in the sum of SOH, LD1, LD2, and LD3. This is not a
problem for a Pull simulation, because the Pull-aware agents are considerate and will
not order any more than the supplier can deliver. However, the RB_PushAgent will
order whatever it thinks that it still needs. In a backlogged situation, this often causes
the agent to order too much, causing the SCCORI simulation to announce an invalid
order and then to wait for the agent to try again. This is captured by the agent's
invalidOrder() method which employs the following logic to step down to a valid
order. This logic is a compromise between finding a good order and providing quick
response.
Order > 90 set Order = 90 An order greater than 90 is usually not necessary.
Order > 60 set Order = 60 Orders between 60 and 90 are too expensive to ship.
Order > 50 set Order = 50 Notice that this logic steps by five each time for a
Order > 45 set Order = 45 maximum of eight attempts to find an acceptable value.
Order > 40 set Order = 40 Otherwise it just capitulates to a zero order.
Order <= 30 set Order = 0 An order less than 30 costs too much to ship.
All of the Rules Based agents use this logic, but only the RB_PushAgent relies on it.

RB_PullSpikeAgent
Objectives
- Designed for pull runs.
- This agent is optimized to perform well on spiked runs; but, it does not perform well
on random runs.
- It attempts to maintain adequate stocks, minimize shipping costs, and not backlog its
supplier.
- Before the spike it tries to fully stock at all levels; after the spike it behaves like
RB_PullRandomAgent.
- This agent is the clear winner in its ability to handle spiked runs.
The Facts
- sp.Stock = sp.SOH + sp.LD1 + sp.LD2 + sp.LD3 (not needed by MANUFACTURER)
- my.InvMax = [ 100 | 80 | 80 | 65 ]
- safetyLevel = 40
- minOrder = 30
- re.BO = FALSE
- isSpiked = FALSE
The Rules
re.OrderReceived > invMax set isSpiked = TRUE
Only one spike is ever
expected.
re.SOH < 15 set re.BO = TRUE
Things are really bad if
retailer is this far in the hole.
re.SOH > 15 set re.BO = FALSE
Things are looking good so
don't overstock the supply
chain.
re.BO = TRUE OR
isSpiked = FALSE
set Order = (Order +
invMax my.InvMax)
Maximize the stocking levels.
(I am not MANUFACTURER) AND
(sp.Stock >= safetyLevel)
set Order to
min(sp.SOH, Order)
Be considerate of a supplier
who works to maintain
adequate supplies.
(I am the MANUFACTURER) AND
re.BO = TRUE
set Order = invMax
my.SOH my.LD1
my.LD2 my.LD3
We may not let manufacturer
exceed invMax.
Order < 0 set Order = 0 zero
Do not order negative
quantities.
NOT(re.BO) AND isSpiked AND
my.SOH > safetyLevel
set Order = 0 Is an order really needed?
Order < minOrder
set Order = 0
Avoid small shipments, unless
the retailer is seriously
backlogged.
set Order = remainder Enough for another container?
Back Order Logic
The RB_PullSpike agent uses exactly the same back-order logic as RB_Push agent.
Please see RB_Push agents back-order logic for details.

RB_PullRandomAgent
Objectives
- This agent is optimized to perform well on random runs; but, it does not perform well
on spiked runs.
supplier.
- The difference between this agent and the RulesBasedAgent is invMax versus
my.InvMax.
The Facts
- my.InvMax = [ 100 | 80 | 80 | 65 ]
- safetyLevel = 40
- minOrder = 30
- re.BO = FALSE
The Rules
Things are really bad if retailer is
this far in the hole.
Things are looking good so don't
overstock the supply chain.
re.BO = TRUE set Order = invMax Maximize stocking levels.
(I am not MANUFACTURER)
AND
set Order to
min(sp.SOH, Order)
Be considerate of a supplier who
works to maintain adequate
supplies.
(I am the MANUFACTURER)
AND re.BO = TRUE
set Order = invMax my.SOH
my.LD1 my.LD2 my.LD3
exceed invMax.
Order < 0 set Order = 0 zero Do not order negative quantities.
NOT(re.BO) AND
NOT(re.BO) AND
Order < minOrder
set Order = 0
Avoid small shipments, unless the
retailer is seriously backlogged.
NOT(re.BO) AND
Back Order Logic
The RB_PullRandom agent uses exactly the same back-order logic as RB_Push agent.
Please see RB_Push agents back-order logic for details.

RulesBasedAgent
Objectives
- This is a generic agent that does reasonably well on both random and spiked runs.
supplier.
The Facts
- my.InvMax = 100
- safetyLevel = 50
- minOrder = 30
- re.BO = FALSE
The Rules
Things are really bad if retailer is
this far in the hole.
Things are looking good so don't
overstock the supply chain.
re.BO = TRUE set Order = invMax Maximize stocking levels.
(I am not MANUFACTURER)
AND
set Order to
min(sp.SOH, Order)
Be considerate of a supplier who
works to maintain adequate
supplies.
(I am the MANUFACTURER)
AND re.BO = TRUE
set Order = invMax my.SOH
my.LD1 my.LD2 my.LD3
exceed invMax.
Order < 0 set Order = 0 zero Do not order negative quantities.
NOT(re.BO) AND
NOT(re.BO) AND
Order < minOrder
set Order = 0
Avoid small shipments, unless the
retailer is seriously backlogged.
NOT(re.BO) AND
Back Order Logic
The RulesBased agent uses exactly the same back-order logic as RB_Push agent. Please
see RB_Push agents back-order logic for details.
User Interface
Our implementation solution was based on the use of Echo2, which is an Open Source
AJAX-based rendering Java framework (NextApp, 2005), and was deployed inside a
J2EE compliant Open Source server called JBoss. Figure 3 presents a UML
representation of the user interface.

Figure 3 - UML Representation of the User Interface
Simulation Wrapper
To implement the wrapper, we used HtmlUnit which is an Open Source Java library used
primarily for creating automatic test for web applications (Bowler, 2006). Figure 4
presents a UML representation of the simulation wrapper.

Figure 4 - UML Representation of the Simulation Wrapper
Data Store
Figure 5 presents a UML representation of the data store.

Figure 5 - UML Representation of the Data Store
o What didn't we implement? Why not?
Agent
fuzzy logic
Due to their severe penalties, fuzzy backlog decisions are out of the question; but using
fuzzy rules for both stocking levels and container fill factors may have provided better
decisions than our crisp (i.e., rules based) agents. The low costs of over stocking (i.e.,
handling costs) do not really warrant a lot of extra computing power, but container fill
factors really are a fuzzy variable. Still, considering the excellent overall results of
our crisp-logic, rules-based agents, and due to our limited time, a fuzzy rules-based
agent was not implemented.
The fact that each SCCORI simulation takes roughly half-an-hour severely restricted
our ability to create learning agents that would have time to learn. Four agents playing
each thirty-cycle simulation, requires 120 order decisions. That requires more
simulation runs than we have time to manage.
Since an agent may order zero to one-hundred (or more) items, decision trees discrete
nature would require too many leaves for each possible situation. Again, given our time
constraints, the task of creating a pedagogy to teach such a decision tree agent was too
daunting.
Communication requirements were so meager that pursuit of such a social agents was
of small value and not worth our efforts at this time. Two reasons for this were: (1) in
push mode, the players can only see their own stocking levels and they are not allowed
to communicate with each other. In such a situation, our agents should live by the same
rules; (2) in pull mode, the players (and our agents) can see all of the stocking levels, so
there is really no need to communicate. Our rules-based-pull agents already keep an
eye on the Retailers stock-on-hand and on their suppliers stocking levels to enable
them to act in ways that benefit both their own situation and that of the overall supply
chain.
User Interface
Unfortunately, we did not have enough time to implement a reporting system for the user
interface. This could have been completed with the use of JasperReport (JasperSoft,
2006), and would have allowed us to better monitor our agents' performance.
Simulation Wrapper
This component was fully completed, and we do not believe that any further requirements
need to be implemented.
Data Store
We did not have time to complete this component, and since we had access to the data
from the SCCORI web site, we decided to focus our energy elsewhere.
3 Results
- How did we measure success?
There were three measures for agent success:
1. All of our agents behave as expected.
2. On random simulations, our better agents minimize the average per-unit costs at cycle
30 to between 63 cents and 77 cents.
3. On spiked simulations, our better agents minimize the average per-unit costs at cycle 30
close to the empirically ideal value of 85 cents.
Where did we get these numbers? We were unable to obtain historical data of typical
student runs, so instead we devised a mixture of mathematical and empirical analyses to
determine what the minimum per-unit costs of well-run simulations should be. An analysis
of random simulations and then an analysis of spiked simulations follow.

o Best Possible Random Simulations
The Facts
In SCCORI random-run simulations, the Retailer receives random orders between
0 and 22 items. The average order is 11 items.
Four constants are the initial stock levels:
Retailer Wholesaler Distributor Manufacturer
40 50 60 80
Cycle costs are calculated as follows:
Purchase Cost SOH Handling Costs Backlog Costs Shipping Costs
50 cents per unit
3 cents per unit in
SOH per cycle
1 dollar per unit
backlogged per cycle
$10 per container
- Note: a container can hold up to 60 units, but always costs the same no matter how full
or empty.
- All stock deliveries take three cycles. Thus if a position orders on cycle 1, then its SOH
(stock on hand) inventory shows an increase at the start of cycle 4.
A Simple Analysis - First Order Approximation
What is the least overall per-unit cost that we could possibly attain by cycle 30?
As a first-order approximation, make the following assumptions:
- The average order is 11 units per cycle.
- Players/agents are considerate and do not backlog their suppliers.
- We may ignore backlog costs. A good player/agent can usually avoid backlogs.
- Only full containers (60 units) are ordered. This is not always advisable if one wants to
avoid backlogs, but it simplifies the analysis.
- We may ignore handling costs. At three cents per unit per cycle, this is a small part of
total costs.
The following are based on the previous assumptions:
- By cycle 30, the Retailer has received orders for (30 11 =) 330 units.
- Since the agents do not know when the simulation stops, they must order to supply 330 units.
- Shipping costs are ($10 / 60 units =) 16.67 cents per unit.
- The Retailer needs to purchase and ship (330 - 40 = ) 290 units
- Retailer's costs are: (40 * 50 cents + 290 * 66.7 cents =) $213.33
- The Wholesaler needs to purchase and ship (330 - 50 = ) 280 units
- Wholesaler's costs are: (50 * 50 cents + 280 * 66.7 cents =) $211.67
- The Distributor needs to purchase and ship (330 - 60 = ) 270 units
- Distributor's costs are: (60 * 50 cents + 270 * 66.7 cents =) $210.00
- The Manufacturer needs to purchase and ship (330 - 80 =) 250 units
- Manufacturer's costs are: (80 * 50 cents + 330 * 66.7 cents =) $ 206.67
- Total unit costs are: (213.33 + 211.67 + 210.00 + 206.67 = ) $841.67
- Total per unit costs are: ($841.67) / 333 = $2.53
Total per unit cost per position is: $2.53 / 4 = 63 cents per unit.
That cost makes a number of simplifying assumptions, but it certainly sets an absolute
lower limit for cycle 30 costs.

For another view of this approximation, consider a different container fill factor.
- Since it is not always advisable to wait for a full container-load before ordering, make the assumption
that on average we order half a container, or thirty units.
- At thirty units per shipment, the shipping costs increase to 33.33 cents per unit.
- Using a similar analysis as above, this changes the final average cost to 77 cents per unit.
The Rules-Based agents typically
*
never order less than 30 units and often order as many
as 60 units per container, so these two numbers form a nice per-unit cost goal-range with
which to evaluate an agent's performance.
*
NOTE: - the RB_PullSpike agent is not concerned with shipping costs prior to the spike
and so will immediately order any quantity that it needs and that its supplier can deliver.
In the final analysis, it is unreasonable to expect an average per-unit cost less than
63 cents per unit by cycle 30; but, it may be possible to achieve a number between
63 and 77 cents per unit.

o Best Possible Spiked Simulations
The Facts
In the SCCORI simulations used by COMP604 students, all spiked runs are identical.
Orders on the retailer in SCCORI spiked run simulations:
Cycle 1 2 3 4 5 6 7 8 9 10 11 121314151617181920212223242526 27 28 29 30 3132
Order 10 13 11 1514 9 20 22 15 201401013111514 9 202215202015151416 11 20 14 13 6 5
Four more constants are the initial stock levels:
Retailer Wholesaler Distributor Manufacturer
40 50 60 80
Cycle costs are calculated as follows:
Purchase Cost SOH Handling Costs Backlog Costs Shipping Costs
50 cents per unit
3 cents per unit in
SOH per cycle
1 dollar per unit
backlogged per cycle
$10 per container
- Note: a container can hold up to 60 units, but always costs the same no matter how full
or empty.
- All stock deliveries take three cycles. Thus if a position orders on cycle 1, then its SOH
(stock on hand) inventory shows an increase at the start of cycle 4.
A Simple Analysis - First Order Approximation
What is the least overall per-unit cost that we could possibly attain by cycle 30?
As a first-order approximation, make the following assumptions:
- We may ignore handling costs.
- All positions have 100 units in SOH when the spike hits.
- We may ignore backlog costs. A good player/agent can usually avoid backlogs.
- Only full containers (60 units) are ordered.
- Except for the spike, the average order is 11 units per cycle.
It should be obvious that some of these assumptions are mutually exclusive; but then, this
is just a first approximation.
The following are based on the above assumptions:
- At cycle 11, the retailer is backlogged by 40 units, and immediately orders 100 units.
- At cycle 12, the retailer is backlogged by (40 + 11 =) 51 units, but can order no more since the
wholesaler's SOH = 0.
- At cycle 13, the retailer is backlogged by (51 + 11 =) 62 units, but can order no more since the
wholesaler's SOH = 0.
- At cycle 14, the retailer has SOH equal to (100 - (62 + 11) =) 27 units, and now places another order.
- Ideally, the retailer should be able to maintain adequate stocks after this point.
Total backlog costs are: (40 + 51 + 62 =) $153.
- Shipping costs are ($10 / 60 units =) 16.67 cents per unit.
- Total units required is (140 + 29 * 11 =) 459.
- The Retailer needs to purchase and ship (459 - 40 =) 419 units
- Retailer's costs are: (40 * 50 cents + 419 * 66.7 cents =) $299.33
- The Wholesaler needs to purchase and ship (459 - 50 =) 409 units
- Wholesaler's costs are: (50 * 50 cents + 409 * 66.7 cents =) $297.67
- The Distributor needs to purchase and ship (459 - 60 =) 399 units
- Distributor's costs are: (60 * 50 cents + 399 * 66.7 cents =) $296.00
- The Manufacturer needs to purchase and ship (459 - 80 = ) 379 units
- Manufacturer's costs are: (80 * 50 cents + 379 * 66.7 cents =) $ 292.67
- Total unit costs are: (299.33 + 297.67 + 296.00 + 292.67 =) $1185.67
- Total per-unit costs are: ($153.00 + $1185.67) / 459 = $2.92
Total per unit cost per position is: $2.92 / 4 = 73 cents per unit.
That cost makes a number of simplifying assumptions, but it certainly sets an absolute
lower limit for cycle 30 costs.
It should also be noted that the average order for the other cycles is 15 units, whereas
most random runs average out at 11 units. The spiked simulation appears to be designed
to punish the participants.
Can we get a better estimate?
An Empirical Estimate
We put the orders that the retailer receives into a copy of the RB_PullSpiked spreadsheet
in the SCCORI Fast Simulation workbook. Then, using our knowledge of the exact
ordering sequence, we over-rode the logic in selected cells to force the lowest possible
per-unit costs. We could not find any combination of orders that would lower this below
85 cents per unit.
Thus, our empirical lower limit is 85 cents per unit. We feel that this is a reasonable goal
for our RB_PullSpiked agent, who must operate without the benefit of knowing the
Retailer's received-order sequence.
Note: The Ideal Spiked Run spreadsheet may be viewed in the SCCORIModel.xls
workbook provided with the COMP667 project submission.
- What experiments did we execute?
In order to characterize our agents, we attempted to run each agent on thirty random
simulations. Unfortunately early versions of the framework suffered some problems which
required constant monitoring and precluded simultaneous and multiple overnight runs. The
testing time took so long that some agents had to be cut back to ten simulations in order to
meet our deadlines. Fortunately from a statistical point of view we were still able to
consider those samples large enough to represent their populations, since we always pooled
all four positions into one average per-unit cost. This increased the overall standard
deviations, but in the end that did not hurt our final data analyses.
Since all SCCORI simulation spiked runs are identical, we only characterized each agent
against a single spiked simulation.
- Provide quantitative results.
The raw quantitative data are available in the spreadsheets provided with the COMP667
project submission. There are seven sub-directories which contain the raw data
spreadsheets. In the main spreadsheet directory there are also seven Excel workbook files
with similar names. These workbooks contain the individual spreadsheets of their
namesake directories, plus a summary worksheet at the front that shows the average and
standard deviations of each cycle across all of the spreadsheets. These spreadsheets are
called:
Another spreadsheet called: Paranoid PullRandom.xls, Considerate PullRandom.xls,
RB_PullRandom PullRandom.xls, RB_PullSpiked PullRandom.xls,
RB_Push PullRandom.xls, RulesBased PullRandom.xls, and AllSpikedRuns.xls.
One other spreadsheet of interest here, is called StatisticalAnalysis.xls, which automates
the tedious mathematics required for the F and t tests. We only had to verify one set of data
to ensure that all of our calculations were consistent.
The numerical results for each of the four agents are shown below. The following general
notes apply in all six cases:
- The results are the average and standard deviations of cycle 30 of each run.
- To simplify comparisons to other agents:
o the average unit cost is the simple average of all four agents' unit costs
o the grand total cost is the sum of all four agents' total costs
- All spiked runs are the same, so there is no point in more than one run.

ParanoidAgent
Four Paranoid Agents played all four positions on ten Random-Pull simulations.
Random Pull Runs $Costs
Position Unit Cost SD Total Cost SD Avg. Unit Cost 149.5 cents
RETAILER 1.30 0.0607 575.41 22.97

Total Costs $3129.92
WHOLESALER 1.45 0.1185 722.01 57.34
DISTRIBUTOR 1.67 0.1166 918.43 60.23
MANUFACTURER 1.56 0.0783 914.07 39.85


Four ParanoidAgents played all positions on a single Spiked-Push simulation.
Spiked Push Run $Costs
Position Unit Cost Total Cost Average Unit Cost 151 cents
RETAILER 1.38 934.84

WHOLESALER 1.48 1085.58
DISTRIBUTOR 1.65 1295.47
MANUFACTURER 1.54 1267.89

ConsiderateParanoidAgent
Four Considerate Paranoid Agents played all four positions on twenty-eight Random-Pull
simulations.
RETAILER 1.22 0.0634 539.82 13.50

WHOLESALER 1.12 0.0521 565.43 12.51
DISTRIBUTOR 1.08 0.0455 599.60 12.45
MANUFACTURER 1.04 0.0406 619.62 12.45

Four ConsiderateParanoidAgents played all positions on a Spiked-Pull simulation.
Spiked Pull Run $Costs
Position Unit Cost Total Cost Average Unit Cost 102 cents


RBPushAgent (Rules Based Push)
Four RB_PushAgents played all four positions on ten Random-Push simulations.
RETAILER 0.80 0.0179 331.47 19.73

WHOLESALER 1.09 0.1163 454.71 58.13
DISTRIBUTOR 0.86 0.0552 385.85 31.35
MANUFACTURER 0.84 0.0467 394.01 27.57

Four RB_PushAgents played all positions on a single Spiked-Push simulation.
Position Unit Cost Total Cost Avg. Unit Cost 181.75 cents
RETAILER 2.00 1279.41

DISTRIBUTEOR 1.76 1186.48

RB_PullSpikeAgent
Four RB_PullSpikeAgents played all positions on ten Random-Pull simulation runs.
RETAILER
1.17 0.0493 523.39 12.00

WHOLESALER
1.09 0.0387 551.58 11.80
DISTRIBUTOR
1.05 0.0336 586.44 11.87
MANUFACTURER
1.02 0.0300 606.44 11.87

Four RB_PullSpikeAgents played all positions on a single Spiked-Pull simulation.


RB_PullRandomAgent
Four RB_PullRandomAgents played all positions on thirty Random-Pull simulations.
Position Unit Cost SD Total Cost SD Avg. Unit Cost 71 cents
RETAILER
0.75 0.0184 302.35 33.05

WHOLESALER
0.70 0.0113 294.62 27.72
DISTRIBUTOR
0.69 0.0103 299.14 27.50
MANUFACTURER
0.70 0.0113 307.37 27.33

Four RB_PullRandomAgents played all positions on a single Spiked-Pull simulation.
RETAILER 1.93 1213.14


RulesBasedAgent
Four RulesBasedAgents played all positions on thirty Random-Pull simulations.
Position Unit Cost SD Total Cost SD Avg. Unit Cost 72 cents
RETAILER
0.76 0.0133 312.05 27.99

WHOLESALER
0.71 0.0128 318.37 27.62
DISTRIBUTOR
0.69 0.0144 317.08 30.35
MANUFACTURER
0.72 0.0116 344.77 29.76

Four RulesBasedAgents played all positions on a single Spiked-Pull simulation.
RETAILER 1.80 1191.09


- What do our results indicate?
An Excel workbook called StatisticalAnalysis.xls is included with the COMP667 project
submission. This workbook contains spreadsheets to automate the tedious mathematics
required for the F and t tests. We only had to verify one set of data to ensure that all of our
calculations were consistent. An analysis of our results is presented below, followed by a
ranking of our agents.
o Introduction
In order to characterize our six agents, we ran each of them through multiple simulations.
For comparison purposes, we averaged the per-unit cost of all four positions and recorded
that along with the standard deviation.
We performed ANOVAs on the results and found that most of the fifteen population
comparisons almost certainly did not share similar variances, which forced us to use the
t-test to compare means rather than z-tests against the normal distribution (Mason, 1991).
The results of the ANOVA F-tests are shown below.
We paired the means tests against each other in order; reasoning that if the two highest
means were significantly different, then the first and third need not be tested, and so we
only needed to test the second highest mean against the third, and so on. To keep things
simple, we did the t-test on all five pairs; the t-test is harder to pass than a z-test, so this
did not seem unreasonable.
The null hypothesis states that one mean is less than or equal to the other. In four cases,
our t-tests indicated that there was only a 0.05% chance that this could be so. Thus we
rejected the null hypothesis.
In the two cases that our rejection rate was not as good, the F-tests were also less certain
about the differences in variances, so we applied the z-tests. In both cases the z-test
provided a better indication that the means were different (as expected).
All results are summarized below. The calculations may be viewed in the
StatisticalAnalysis.xls spreadsheet provided with the COMP667 project submission.
o Data Summary
Note that since we pool the averages and standard deviations of all four positions, we use
four times the number of simulations for n.
Agents ordered by SD. Costs in cents.
Agent Avg SD SD
2
n 4n
Paranoid 149.3 16.6 275 10 40
RB_Push 89.7 13.1 170 10 40
Considerate 111.8 8.24 67.9 28 112
RB_PullSpike 108.4 6.95 48.3 10 40
RulesBased 72.0 2.98 8.88 30 120
RB_PullRandom 71.2 2.66 7.08 30 120

Agents ordered by Avg. Costs in cents.
Agent Avg SD SD
2
n 4n
Paranoid 149.3 16.6 275 10 40
Considerate 111.8 8.24 67.9 28 112
RB_PullSpike 108.4 6.95 48.3 10 40
RB_Push 89.7 13.1 170 10 40
RulesBased 72.0 2.98 8.88 30 120
RB_PullRandom 71.2 2.66 7.08 30 120

o ANOVA Results
Rather than doing linear regressions on lookup tables, we used Professor Lowry's on-line
F-calculator to compare all of the variances against each other (Lowry). The results of the
fifteen comparisons are shown below.
Probability that the sample populations have the different variances.
RB_Push Considerate RB_PullSpike RulesBased RB_PullRandom
Paranoid 93.2% >99.99% >99.99% >99.99% >99.99%
RB_Push - >99.99% >99.99% >99.99% >99.99%
Considerate - - 92.2% >99.99% >99.99%
RB_PullSpike - - - >99.99% >99.99%
RulesBased - - - - 88.8%

o Means Comparison Results
We used the t-test for all five means-comparison tests. In the two cases where 99.95%
certainty was not possible, the F-test was also less certain that the variances were
significantly different, so we applied the z-test and reported them too. In the final
analysis, we believe that the comparison of agents performance shown below is fair and
reasonable. Appropriate t and z tables were found in the CRC handbook (Beyer, 1978).
Probability that these agents truly do have different means.
Agents Compared
Respective
Means
t-test
confidence
z-test
confidence
Paranoid vs Considerate 149.3 versus 111.8 99.95% na
Considerate vs PB_PullSpike 111.8 versus 108.4 99% 99.5%
RB_PullSpike vs RB_Push 108.4 versus 89.7 99.95% na
RB_Push vs Rules Based 89.7 versus 72.0 99.95% na
RulesBased vs RB_PullRandom 72.0 versus 71.2 95% 99.97%

The last comparison, RulesBased versus RB_PullRandom, is somewhat questionable. As
the ANOVA shows, we are almost 89% sure that the variations are different, so that
precludes using the z-test 89% of the time. The t-test shows only 95% confidence that the
Rules Based mean is larger than the RB_PullRandom mean, which tells us that we would
be wrong 1 time out of 20 in accepting the conclusion that the means are different. In
other words, their performance may be the same on random runs; but, they are probably
not. The other means-comparisons are so high (99% or better) that we may confidently
order the random-run results as shown next.
The agent performances are ranked in three tables below:
- A higher rank number indicates better performance.
- The first table ranks the agents according to their performance in the random-run
simulations.
- The second table ranks them according to their performance in the spiked-run
simulations.
- The third table combines the rank numbers of the previous two tables to identify the
best overall performers.
- The performance parameter is the average unit cost. All costs are reported at cycle
thirty.
- In the combined rankings table, the ties are decided by giving the agent with the
minimum spread between its performances the higher ranking.

Random Simulation Ranking Spiked Simulation Ranking
Rank Agent Name
Average
Unit Cost
Rank Agent Name
Average
Unit Cost
6 RB_PullRandom 71 cents 6 RB_PullSpike 87 cents
5 RulesBased 72 cents 5 RulesBased 98 cents
4 RB_Push 90 cents 4 RB_PullRandom 101 cents
3 RB_PullSpike 108 cents 3 ConsiderateParanoid 102 cents
2 ConsiderateParanoid 112 cents 2 Paranoid 152 cents
1 Paranoid 150 cents

1 RB_Push 182 cents

Combined Ranking
Agent Name Rank
RulesBased 10
RB_PullRandom 10
RB_PullSpike 9
ConsiderateParanoid 5
RB_Push 5
Paranoid 3
4 Discussion
- Although ConsiderateParanoid is a simpler agent than the RB_Push agent, it outperforms it
because it operates in Pull mode which enables it to prevent propagating backlogs down the
line.
- The RulesBased agent is the best overall agent because it ranks in second place on both
types of runs. Also RB_PullRandom beats RulesBased by only a narrow margin in the
Random Runs (1 cent), while RulesBased beats RB_Random by a wider margin in the
Spiked Runs (3.25 cents).
- For Spiked Runs, RB_PullSpike outperforms all the rest by a wide margin; but, this is at a
great price, because even the "blind" RB_Push agent outperforms it on Random runs.
- Comparing the two "blind" agents (RB_Push and Paranoid) performances on the Spiked
run, we see that even the simple Paranoid agent outperforms the RB_Push agent. The
reason is that the Paranoid agent's raison d'etre is to prepare for spikes, and it when a spike
comes, Paranoid is as ready as it can possibly be. To its credit, on Random runs, RB_Push
can deliver product for less than 2/3 of Paranoid's cost.
- If we had to choose just one agent, it would be the RulesBased agent
- Overall, is the approach we took promising?
We feel that our supply chain management agent approach is very promising. Not only
does our range of agents allow students of supply chain management to test against
different types of players; but, our best performing agents approach the limits of
performance as indicated by our mathematical and empirical analyses of the SCCORI
simulation.
To recap our best performing agent results:
- The best average random per-unit cost of 71 cents falls well within the estimated range of
63 to 77 cents per unit. The lower end of that range made conservative simplifying
assumptions that could never be realized in actual simulations.
- Also the best spiked per-unit cost of 87 cents is very close to the empirical best of 85
cents, which was achieved through pre-knowledge of the spiked order sequence. Our
agent had no such knowledge when it achieved its value of 87 cents.
- What different approach or variant of this approach is better?
The two cent difference in our RB_PullSpike agents performance versus the empirical-
best can be attributed to a single order of one-unit made by the retailer-agent during cycle
five of the simulation. That additional ten-dollar cost averages out over 419 units to 2.4
cents per unit. Additional logic could be added to that agent to avoid single orders, but the
extra logic and processing hardly seems worth the trouble.
- What follow-up work should be done next?
We would encourage future agent developers to create a genetic search agent that could
determine the best possible set of one-hundred-twenty order-placements in order to
minimize the per-unit cost of SCCORI spiked runs to its absolute minimum. This, of
course, would require a considerable number of simulation runs.
Another area that can use some improvement is to convert the web-based interface into a
more robust Swing application.
- What did we learn by doing this project?
Marty Boogaart
I learnt (and also re-learnt) much more than the scope of the COMP667 course originally
intended. Of course the project was a powerful motivator to understand the various
intelligent agent options to choose from so that we could make good choices. Also, I now
realize that I was exposed to a broad over-view of the artificial intelligence landscape,
which until now always seemed a bit mystical and out-of-reach. I now appreciate that the
tools in the field of AI are available to me; that I can understand and make use of them.
Other learning that I experienced includes:
- A more thorough understanding of the Java programming language. To allow us to test
our agents, a sophisticated agent framework needed to be created. Although this did
involve the use of agent-based techniques, this framework was created with the use of
Object Oriented techniques, which reinforced many of the concepts that were introduced
in COMP308.
- Extensive experience with Wiki programming (Wikipedia, 2003). We documented our
work on a Wiki server, and I can now document in a Wiki almost as fast as I can type in
Word (almost).
- Understanding and appreciation of Concurrent Versions Systems (CVS, 2006). To ease
development, we setup and used a code repository.
- ANT (Davidson, 2000) is the Java way to automate routine maintenance and compilation
tasks. I have long used DOS batch files for such chores, but this project forced me to
learn about ANT. ANT is like batch files on steroids!
- A better understanding of how Windows help files and HTML help files are created. Our
user manual was created using Help Scribble (Goyvaerts, 2006). The program itself does
not compile the Windows help file, but uses compilers that are downloadable from
Microsoft and Borland.
- It has been a few years since I have done any statistical analysis. This was a nice
opportunity to refresh my skills.
- An appreciation and understanding of JBoss (JBoss, 2006). I am still not fluent with it
yet, but I at least understand its purpose and how it is used.
- A better appreciation of the challenges in supply-chain-management. There are now
universities offering bachelor degrees in SCM!
Francois Nadeau
This project provided me with a good exercise for learning the manner in which agents are
able to solve business needs. It also removed my previous image of AI as a mystical black-
art-like field, and made me realized that many of its techniques are simply mathematical
algorithms.
The following is a short list of what I learned during this project:
- Appreciation for the Agent-based pattern, and a better understanding of how it can be
used to provide additional web services.
- Coordination skills from working in a distributed team whose members live in time zones
fifteen hours apart.
- This was the first time that I used Echo2, which is the AJAX framework library that we
used to create the user interface. Unfortunately, I did not like it and probably won't use it
again.
5 Conclusion
As stated in the Introduction and paraphrased here, our goal was to create intelligent agents
to interact with the supply-chain-management simulations available at the SCCORI web site.
Those agents would be available to students via a SCCORI agent web site so that they could
participate in simulations with less than four human players. That site, complete with a user
manual, is now available at http://219.33.28.36:8080/sccoriAgentClient/index.html. Our
agents provide a range of skills and the performance of our best agents approach the limits of
achievement that are possible in the SCCORI simulations. In short, we have succeeded in
accomplishing our objectives.
A
Appendix A Software Package
The SCCORI-Agent source code is separated into two directories.
- 04_Client : This project contains the User-Interface which needs to be deployed in a web
container such as Tomcat or JBoss.
- 05_Server: This project contains the Agents, simulation wrapper, and data store
components.
Both of these projects have an Apache Ant build script, and the libraries required for their
compilation and execution. All third party libraries used in this projects are Open Source
libraries. Listings of teh software directory structures follow.
Directory structure for the 05_Server project:
05_Server/
|-- build.xml
|-- doc
| |-- allclasses-frame.html
| |-- allclasses-noframe.html
| |-- ...
| |-- index.html
| `-- stylesheet.css
|-- lib
| |-- commons-beanutils-1.7.0.jar
| |-- ...
| `-- xmlParserAPIs-2.2.1.jar
`-- src
|-- java
| |-- ca
| | `-- athabascau
| | `-- sccori
| | |-- agent
| | | |-- AgentFactory.java
| | | |-- ConsiderateParanoidAgent.java
| | | |-- ParanoidAgent.java
| | | |-- RB_PullRandomAgent.java
| | | |-- RB_PullSpikeAgent.java
| | | |-- RB_PushAgent.java
| | | `-- RulesBasedAgent.java
| | |-- comm
| | | |-- ErrorNotifier.java
| | | |-- EternalThreadedRefreshHandler.java
| | | |-- Simulation.java
| | | |-- TurnAdapter.java
| | | |-- TurnListener.java
| | | `-- comm.cdf
| | |-- data
| | | |-- SimulationInfo.java
| | | |-- TurnEvent.java
| | | |-- TurnInfo.java
| | | `-- data.cdf
| | `-- message
| | |-- Message.java
| | |-- MessageChannel.java
| | `-- MessageModule.cdf
| `-- log4j.properties
`-- resources
`-- WEB-INF

35 directories, 124 files

The Ant Build script

The JavaDoc generated for the User Interface (directory
structure shortened to ease reading).

There are 20 Open Source libraries in this project,
shortened here to ease reading.

Source code for the various Agents

Source code for the Simulation wrapper component

Source code for the Data Store component

Source code for the Message mechanism

B
Directory structure for the 04_Client project:
_Client/
|-- build.xml
|-- doc
| |-- allclasses-frame.html
| |-- ...
| |-- index.html
| `-- stylesheet.css
|-- lib
| |-- Echo2_App.jar
| |-- ...
| `-- xstream-1.1.jar
`-- src
|-- java
| `-- ca
| `-- athabascau
| `-- sccori
| `-- client
| |-- AgentPanel.java
| |-- ClientApplication.java
| |-- ClientServlet.java
| |-- SimulationPool.java
| |-- SystemPanel.java
| `-- user-interface.cdf
`-- resources
|-- WEB-INF
| |-- classes
| | |-- ca
| | | `-- athabascau
| | | `-- sccori
| | | `-- client
| | | `-- icon.png
| | `-- hibernate.properties
| |-- jboss-web.xml
| `-- web.xml
|-- images
| |-- icon.png
| `-- sccoriagent.png
|-- index.html
|-- sccoriAgents.chm
`-- usermanual
|-- Rankings.png
|-- SCCORIAgentLogin.png
|-- SCCORIAgentLoginComplete.png
|-- SCCORIAgentWebSite.png
|-- SCCORIAgentsWorking.png
|-- SCCORIsite.png
|-- cnt.htm
|-- hs10.htm
|-- hs100.htm
|-- hs110.htm
|-- hs120.htm
|-- hs130.htm
|-- hs20.htm
|-- hs30.htm
|-- hs40.htm
|-- hs50.htm
|-- hs60.htm
|-- hs70.htm
|-- hs80.htm
|-- hs90.htm
|-- idx.htm
|-- sccoriAgentHelp.htm
`-- sccoriAgentLogo_Help.png

39 directories, 153 files

The Ant Build file

The JavaDoc generated for the User Interface (directory structure
shortened to ease reading).

There are 44 Open Source libraries in this project, shortened here to
ease reading.

The User Interface source code (written for the Echo2 framework).

The web container descriptor

The On-line user manual

C
References

Beyer, W. H. (1978). CRC Standard Mathematical Tables (25 ed.). Boca Raton: CRC Press.
Bowler, M. (2006). HtmlUnit (Version 1.9): Gargoyle Software.
CVS. (2006). Concurrent Versions System.
Davidson, J. D. (2000). ANT - Another Neat Tool.
Goyvaerts, J. (2006). HelpScribble (Version 7.6.1): JG Software.
Gregoire, D. (2003). SCCORI User Manual [Electronic Version]. Retrieved 26 July 2006 from
http://www.sccori.com/sim/products/sccoriUsermanual.doc.
JasperSoft. (2006). JasperReports.
JBoss. (2006). JBoss: Red Hat.
Lowry, R. F Calculator [Electronic Version]. Retrieved July 2006 from
http://faculty.vassar.edu/lowry/tabs.html#f.
Mason, L., Marchal. (1991). Statistics an Introduction (third ed.). Orlando: Harcourt Brace
Jonanovich Inc.
NextApp, I. (2005). Echo2 (Version 2.0.0).
Russell, S. N., Peter. (2003). Artificial Intelligence a Modern Approach (second ed.). Upper
Saddle River: Prentice Hall.
Wikipedia. (2003). MediaWiki Handbook [Electronic Version]. Retrieved July 2006 from
http://meta.wikimedia.org/wiki/MediaWiki_User's_Guide.
Wooldridge, M. (2002). An Introduction to MultiAgent Systems. West Sussex: John Wiley &
Sons, Ltd.

Intelligent Software Agents: Intelligent Agents For The Supply Chain Online Research Institute

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Intelligent Software Agents: Intelligent Agents For The Supply Chain Online Research Institute

Hochgeladen von

Copyright:

Verfügbare Formate

TME3

Das könnte Ihnen auch gefallen