Resource Allocation in an Artificial Electronic

MarketFinal Report

Matthew Mun-Yui Yee

5/9/2008

The allocation of resources in a large organisation can be an inefficient exercise constrained by poor sources of information and assorted human factors. Markets and financial instruments such as derivatives exhibit desirable properties in conveying information to market participants as well as mitigating risk. An automated system for simulating the trade and consumption of futures resource contracts between software agents is presented and implemented. The performance of different transactions is show and a relationship between a trading constraint and trading activity are presented as results.

Contents1 Introduction.........................................................................................................................................4

1.1 What advantage does a Market based solution hold over a centrally planned solution?...........5

1.1.1 The Producer.......................................................................................................................5

1.1.2 The Consumer......................................................................................................................5

1.1.3 What are the problems associated with centrally based resource allocation in a large organisation?.......................................................................................................................................6

1.2 A Market-Based Solution: TAC market Design Competition........................................................8

2 Simulation System Design....................................................................................................................9

2.1 Workflow...................................................................................................................................10

2.2 Agent Roles................................................................................................................................10

2.2.1 Producer............................................................................................................................10

2.2.2 Buyer..................................................................................................................................10

2.2.3 Seller..................................................................................................................................10

2.3 The Contract..............................................................................................................................11

2.3.1 Contract States..................................................................................................................11

2.3.2 Agent Contract Operations................................................................................................11

2.4 Funds.........................................................................................................................................11

2.5 Resources..................................................................................................................................11

2.6 Decision Processing...................................................................................................................12

2.6.1 The Definition of Slack.......................................................................................................12

2.6.2 Decision Cycle....................................................................................................................13

2.6.3 Execution...........................................................................................................................14

2.7 Implementation.........................................................................................................................15

2.7.1 Agent roles.........................................................................................................................16

2.7.2 Database handling.............................................................................................................16

2.7.3 Agents implementation.....................................................................................................16

2.7.4 Contract Implementation...................................................................................................16

2.7.5 Contract States..................................................................................................................18

2.7.6 Agent Operations...............................................................................................................19

2.7.7 Agent Resources Implementation......................................................................................20

2.7.8 Funds Implementation.......................................................................................................20

2.8 Slack Implementation................................................................................................................20

3 Simulation Results.............................................................................................................................20

3.1.1 Simulations........................................................................................................................20

3.1.2 Constant Consumption......................................................................................................21

3.1.3 Contract Discharge.............................................................................................................24

3.1.4 Random Consumption Function.........................................................................................25

3.1.5 Varying the lower slack limit..............................................................................................28

4 Conclusion.........................................................................................................................................31

5 Bibliography.......................................................................................................................................32

1 IntroductionThe allocation of resources in a large organisation is a complicated task fraught with inefficiency. For example, computing resources such as disk storage are costly1 and require specialist knowledge. Planning for capacity is often imperfect and subject to periods of lag in procurement and deployment. A solution may be found in mitigating the risk of making poor decisions by using financial instruments such as futures contracts.

The value of futures contracts lie in their ability to help their buyers make long term decisions to hedge against fluctuating prices of resources. Futures contracts can be especially valuable in the acquisition of resources with prices that fluctuate in large values. Buyers and sellers of this type of derivative create a market where risk can be offset for financial consideration.

For example, an airline knows how much fuel it will need to buy in six months and also knows how much money it can spend. The airline knows that the price of fuel is extremely variable and is nearly impossible to predict within a reasonable margin at the conclusion of six months. If the present price of fuel is $5/L the airline may hedge against the risk dearer fuel costs by purchasing a contract to buy fuel in six months at a cost of $5.10/L. At the conclusion of six months the airline will have saved itself considerable money if the cost of fuel has risen to some amount greater than $5.10/L.

This project investigates the construction and application of a market, similar to a commodities trading exchange to an organisation that may consist of several organisational units. The implementation of a market for futures contracts within a large organisation is explored in this project by building a software system to simulate their trade between software agents that represent organisational units. Simple strategies are applied to these agents to buy and sell contracts, based upon their own supply of resources and the supply of resources in the artificially created market.

The rest of this section discusses some background behind the principles in creating a market based solution as well as the TAC competition. It is concluded with a description of some goals for the system to achieve these principles. The rest of the report is organised into a description of the system’s design which aspires to give the reader more detail into how the simulation system will operate, followed by a description of the implementation and the experiments that were conducted on the finished product and the results that were obtained.

1.1 Elements of a market and how they map to a large organisationA market based solution provides a framework in which organisational units can coordinate their resource consumption decisions[4]. As such, it is required that analogies of market components be defined with respect to an organisation. These include the Producer and Consumer of a resource as well as the rules of trade and the products to be traded. In this section, we define the basic components of the market-based solution by mapping components of a market to the components of an organisation.1 While the actual cost per megabyte of off-the-shelf hard drives are decreasing, the cost does not take into account enterprise storage resources that include tape backup, diskless backup, archival systems and media, backup software licensed by capacity and SAN infrastructure.

In a large organisation where the allocation of resources is centrally planned, inefficiency may manifest itself in forms such as over-allocation or under-allocation. Both of these inefficiencies are detrimental to an organisation because they result in budget deficit and surplus. The consequences of a deficit are obvious however a budget surplus can be an indication of incorrect allocation resources, burdening one organisational unit with too many resources while starving another. In order to increase efficiency in the consumption of resources, a market-based solution may be used as an alternative.

1.1.1 The ProducerThe Producer in this synthetic market may be specified as the Planner of an IT department. It is the goal of the IT Planner to allocate storage resources to various organisational units. It can be said that the IT Planner “produces” storage resources.

The basic economic attributes of the Producer are as follows

1. Over a given budget period, the Producer is only allowed to ‘produce’ a finite amount of storage resources.

2. The cost of the storage resources consists of the procurement cost and the cost of labour to install it.

1.1.2 The ConsumerThe Consumer may be specified as the individual organisational units that operate under the highest authority within the organisation.

The basic economic attributes of the Consumer are as follows

1. Over a given budget period, the organisational unit consumes storage resources, or the product.

2. This product is exchanged from the Producer previously defined. The product is the storage resource.

3. The product is exchanged from the Producer for a cost.

1.1.3 The Consumer and Producer applied to an example organisation and the problems associated with centralised resource allocation

In a large organisation, it is advantageous to exploit economies of scale in procuring resources through a single point of contact. In turn this single point of contact provisions resources to organisational units that require them. In a large organisation such as a university or a city government, budgeting can be a complicated ordeal. In a municipal Budgets are allocated annually and the planning process can take an entire year. A great deal of time is dedicated to the preparation of a budget by the IT Planner of the organisation. This section discusses the example of SAN disk space allocation at the City of Vancouver and its problems leading to inefficiency.

An IT department can be expected to provide centralised services to composite organisational units within an organisation. Economies of scale figure prominently in selecting a centralised enterprise model. It provides an advantage in allowing the smaller organisational units to participate in an infrastructure that would otherwise be too costly to implement on their own. This could include a

virtualised computing infrastructure, storage area networks and centralised data backup services, amongst others. The SAN and associated backup infrastructure at the City of Vancouver totals approximately 1 million CAD per annum, excluding the cost of labour.

In the provisioning of these resources, organisational units must provide the IT department with information that will assist in planning. Based on the available information, the IT Planner will attempt to determine the funding required for a budget year but it can be very difficult for organisational units to communicate the right information, such as current and future utilisation of resources to the IT department. Poor communication of information will result in insufficient planning, cost overruns and delays in work schedules.

In the case of information gathered on current resource utilisation, it is often difficult to draw any conclusions on future rates of resource utilization, especially in an organisation that is growing rapidly in terms of projects and human resources. An exercise in trend analysis will yield little meaningful information. This is because the growth of data often balloons in the implementation of new projects or new initiatives. For example, a new project may require a database component and in order for a developer to test new code, a copy of a production database may be acquired. The consequent test database may require modification before running the new code. The new development database may be duplicated for other developers to run their own tests and may also be backed up to disk. In this example, it is clear that a single database of several hundred megabytes could multiply the disk storage required for development tasks by orders of magnitude.

With respect to information pertaining to future projects, knowledge gaps often exist that cannot be easily eliminated. This contributes to difficulty in planning accurately. In a large organisation, organisational units are divided by their specialist knowledge and skills, such as the legal or accounting departments2. An organisational unit usually does not possess the specialist knowledge required to understand what information must be given to the IT department to plan accurately. An accounting department may understand what information it wishes an enterprise resource provision application to report. Unfortunately the IT Planner may not know that a single report may require duplication to 100 different managers resulting in increased storage utilisation. In this example the knowledge gap could have been eliminated by the IT Planner asking the right questions. The accountant may not realize that non-accountants would not be privy to their information.

There also exists a risk for the IT Planner that the organisational unit manager may not be forthright about resource requirements and inflate or overestimate estimates for a given budget year. A reason for dissemination of false information at the City of Vancouver arose from poor relationships between managers stemming from past disputes. Such disharmony is very difficult to overcome as motivations are personal in nature and dismissal is rarely ever used, even for the most egregious transgressions.

In a municipal environment such as the City of Vancouver (COV), deficiencies in planning can be overcome at the cost of time. Unforeseen requirements for computing resources can always be

2 I would note that a general shortcoming of an IT department is its ignorance to what the entire organisation actually does.

remedied as long as the deployment is delayed. Procurement procedures and policies can create delays because by definition they are required to be transparent and are thus tendered at the great expense of time. For example, after a budget allotment has been estimated for a year, it must be determined if the resource to be replenished requires public tender. Procedures for public tender can require several months to complete and might require the assistance of the legal department. Respondents’ proposals must then be evaluated through multiple rounds before a contract is awarded.

Market reform strategies have been applied in the energy sector as a means of optimising energy delivery costs. Such strategies have been made possible due to availability of new technologies. See the example of the energy sector[1].

The inefficiencies discussed in this example stem primarily from a lack of actionable information such as the projects that will be implemented or the exact resource usage requirements for such projects. Disk space usage can also be very difficult to predict as demonstrated in a development scenario. A good solution to this problem would require information to be conveyed accurately to managers so that they can react appropriately. As well, it may be effective to devise a system that permits managers to quickly make up for planning shortfalls in resources, such as a market system that allows participants to trade resource surpluses with those experiencing deficits.

In this particular project, the managers of organisational units will be replaced with agents to perform the trade of resource contracts automatically over what may be an organisation’s fiscal cycle. This removes the human factors that contribute to inefficiency and may offer advantages in faster, more accurate decision making through constant monitoring of the resource supply.

1.2 A Market-Based Solution: TAC market Design CompetitionThe application of market-based solutions with respect to software agents is not new. The Trading Agent Competition (TAC) Market Design Competition is a computerized competition consisting of buyers, sellers (aka traders) and specialists. The goals of the entrants (called specialists) to the Tournament are[5]:

To design the market rules for effectively matching buyers and sellers given a dynamic set of traders.

To compete against other matchmakers (specialists) by attracting traders to your own market. To maximise profits by setting appropriate commission fees.

At present a TAC tournament has been proposed for the trading of derivatives. It is hypothesized that the work completed in this report could be adapted for use in any such future TAC tournament since many of the issues encountered in the regular TAC tournament are similar to those in trading derivatives. Such issues include pricing, commission and new problems such as derivative contract duration.

2 Simulation System DesignIn light of the organisational problems that inhibit the allocation of resources in an efficient manner and the potential tools available in a market such as derivatives, improved efficiency may be gained through the creation of a system that facilitates a market to trade surpluses of resources. Such a market requires up-to-date information about resources to be made available to producers and consumers. With this information, producers and consumers may be more able to plan resource production and consumption more efficiently.

The first objective is to relay information to the producers and consumers. With this information, the producer can determine how much of a given resource exists so that more can be produced. The consumer can use the system to determine the price of the remaining resource, as determined by the producer. The information is stored in a database and organised into specified states so that consumers can producers have access to all the contracts and determine whether they can be bought, sold, or consumed.

The second objective is to enable the ability for producers and consumers to trade resources. A producer will be given the ability to list resources available for sale, along with a price. A consumer will have the ability to buy the resource for the listed price. Additionally, a consumer may decide to sell a surplus of resources.

Each agent within the simulation system is given a turn to perform actions on the market through its own decision cycle. The entire simulation is composed of multiple iterations of the decision cycle for all the agents participating in the market. The sum total of all the iterations that agents execute their decision cycle can be taken as a fiscal period or some other measure by which a large organisation defines its budget cycle.

The overall system architecture is composed of agents that query a database for the availability of resource contracts for sale. The agent represents the consumer in the system that is also the organisational unit within a large organisation. If any resource contracts are available for sale, the agent may then buy a quantity of these resource contracts and immediately discharge them to replenish their resource supply. Contracts can be bought from a special producer agent that can be analogous to the IT planner as given in the City of Vancouver example.

After a contract is bought, an agent may decide that it has enough resources but decide to sell its resource contracts at a later point in time. These resource contracts may be bought by other agents. The agents’ decision to buy or sell resource contracts is governed by a monitoring system that is set by numerical bounds of resource values. The agent will be configured with and upper bound and a lower bound. Resource values that correspond with values between the upper and lower bounds, or the slack of the agent are compared with the agent’s actual supply.

This section presents and explains the functions of the simulation system by first reviewing the workflow of the two different types of agents. Subsequently it is shown that each agent can assume different

roles that enable them to perform different operations. Following will be a description of the resource contract and the decision making process that an agent makes to buy and sell contracts.

2.1 WorkflowThe workflow for the producer in the system is as follows:

1) Producer sets the resource contract duration, price, amount of resources to ‘sell’.2) The Producer opens the sale of the resources to Consumers.3) The system records the resources listed.4) The system records the sales of the resources to Consumers. The system must ensure that the

Consumers have enough funds to purchase the resources.

For the consumer, the corresponding workflow is below:

1) Consumer buys the resources. The inventory of resource contracts for sale by the producer is deducted.

2) If the Consumer does not need the resources, they are put back onto the market to be traded.3) The consumer discharges contracts and consumes the resources as required.

2.2 Agent RolesIn this system, an agent buys and sells contracts for resources which allow them to replenish their supply. In order to differentiate what an agent is permitted to do, roles are defined which are associated to certain actions or operations which may be performed. A consumer agent is allowed to perform the operations associated with the buyer and seller roles. In the case of the producer agent, a privileged role is defined exclusively for producing contracts. Consumer agents cannot assume the producer role. A producer agent assumes the producer role and the seller role.

2.2.1 ProducerThe producer role is a privileged and permits the production of contracts within the system. The agent that undertakes this role cannot undertake any other roles. The producer role is meant to be a specialised role within the system and is not intended to participate in the market (other than creating the contracts). The person within the large organisation which wishes to allocate resources to the organisational units controls this agent.

2.2.2 BuyerAn agent that assumes the buyer role can buy contracts. This means that the agent can modify the contract to the bought state (this is defined below). In essence, this means the contract is modified to reflect a change in ownership and funds are transferred between two agents. The buyer role contains no provisions to negotiate the price of a contract. A buyer agent is motivated by a requirement to replenish or stock resources in order to accommodate their consumption. Only the consumer agent can assume this role.

2.2.3 SellerThe seller role enables an agent to put the contract into a sell state. This role also allows the agent to set the price of the contract. By entering a contract into a sell state, the selling agent is creating an invitation buy the contract by prospective buying agents, also known as an invitation to treat. A seller is motivated to liquidate its surplus of resources to generate more funds to save for future use, so that it can mitigate unforeseen resource consumption. Both the consumer and producer agents can assume this role.

2.3 The ContractThe contract is a record containing attributes that specify the conditions under which a resource can be traded or used. The contract has an expiration date at which time the resources are to be delivered to its owner. The owner may discharge the contract before that date if so desired. Once the contract is discharge, the resources are added to the owner’s existing supply of resources.

Contracts can exist in different states depending on the operation an agent performs on it. All attributes within a contract are manipulated by the agents through operations permitted to them through the assumption of roles.

2.3.1 Contract StatesA contract may exist in four states, creation, sale, bought and discharged. Each state signifies the result of an operation an agent has performed on the contract. These operations are performed based upon the trading strategy adopted by the agent. As well, identifying the relative proportions of contracts in these various states produces information about the health of the internal market and the performance of the agents.

A valid contract may be discharged by the owner of the contract at any time and for practical purposes, can be understood as the act of consuming or using a resource, such that it cannot be traded again. A contract in a discharged state cannot be modified.

For example, a contract in a bought state cannot be bought by any agent, can be discharged by its owner and can be sold by its owner. If the owner of the contract in a bought state wants to sell the contract, it must enter the contract into a sell state. A contract entered into a sell state can be bought by any agent in the system as long as it has not been discharged.

2.3.2 Agent Contract Operations Agents which assume the Buyer and Seller roles perform specific operations on contracts in order to enter them into different states. These operations modify various attributes which correspond to defined contract states. Operations include produce, buy, sell and discharge.

To produce means that contract resources are created for sale to agents within the market. To buy a contract, the ownership of the contract is transferred from one agent to another in exchange for financial consideration. To sell resources means to signal to other agents that one wishes to sell them. To discharge a contract means to conclude the contract once the resource associated to the contract has been delivered or used by the owner.

2.4 FundsThe currency to be used in transactions between agents consists of arbitrary units assigned as funds to each agent. The funds are to be transferred between agents in consideration for the exchange of contracts.

2.5 ResourcesEach agent maintains its resources independent of each other. The rate of consumption of the resources, or the consumption function is independent of any other factors. The consumption function is a parameter by which market conditions may be manipulated. Some agents will be assigned functions with high, low and periodic rates.

2.6 Decision ProcessingAn agent’s primary concern is to ensure that it has access to enough resources to function. This can be done by purchasing more resources (or in the case of this project, contracts for resources) or by conserving or moderating its consumption of resources. If it is determined that the agent has enough resources in its possession to ensure its function, the agent may decide to sell its surplus of resources. An agent may also determine that it does not need to perform buy or sell operations in order to function. The agent may come to this conclusion if it determines that the difference between its resource supply and consumption are within the bounds of a range of values defined as slack.

2.6.1 The Definition of SlackThe slack boundaries are constraints to the buying and selling behaviour of the agent. The boundaries

are operating limits and are used to define a desired behaviour.

An agent makes its decision to buy or sell resources based upon the lower and upper limits of slack, respectively. If the agent’s supply of resources achieves a value between these two bounds, it can be considered to have achieved its goal and is not required to perform any additional tasks. In other words, the supply of resources is within a nominal range of operation. Should the value of resources fall below the lower slack value, it can make a decision to buy additional resource contracts. The agent is thus operating within a deficit range. Conversely a surplus exists if its supply of resources exceeds a defined upper slack limit and the agent may decide to sell the excess resource contracts. The agent is then operating in a surplus range.

Slack boundaries are configured to obtain a desired behaviour from an agent. This strategy is

configured to obtain a certain goal which may or may not be a prescription to control consumption or to accommodate growth. If the difference between the upper and lower slack boundaries are small, thus creating a narrow nominal range of operation, the behaviour of the agent will be coupled more tightly with the consumption rate of resources for that agent.

Consider an example where that the upper slack limit is 50 resource units and the lower slack limit is 40 resource units. The nominal range of operation is between 40 and 50 resource units. If the agent’s supply of resources + the agent’s supply of resource contracts is greater than 50, the agent is deemed to be operating with a surplus. If the agent’s supply of resources is less than 40, the agent is deemed to be operating with a deficit. The figure above illustrates these concepts.

2.6.2 Decision CycleThe simulation consists of several iterations where an agent decides whether or not to buy or sell resource contracts. This decision making process is called the decision cycle. Prior to the beginning of the decision cycle, all market participants are assigned a certain amount of resources and a certain amount of funds. When the simulation begins, the resources are consumed and the agent spends its funds to replenish its supply. The main decision to be made by the agent in a cycle is determining if there is a surplus or deficit of resource contracts. This decision point has three possible outcomes, do nothing, buy resource contracts and sell resource contracts.

At the beginning of the decision cycle the agent first checks to see if the fiscal period is over. The fiscal period is a metric to describe the total iterations of the decision cycles the agent executes. If the agent has reached the end of the fiscal period, the simulation is concluded.

The agent then must decide whether or not its supply of resources is within the nominal range of operation. In other words, the agent must check that the supply of resources it owns is greater than the lower slack limit and less than the upper slack limit. If the agent’s supply of resources is within the nominal range of operation, it does nothing and the cycle is concluded.

If the agent’s supply of resources exceeds the upper slack limit, it can sell its supply of resource contracts if it has any in its possession. If the agent’s supply of resources is less than the lower slack limit, it must then determine if it has enough resource contracts in its possession that it can discharge to replenish its supply to meet the nominal range of operation. If it has enough resource contracts, it will simply discharge as many as it needs. If it does not have enough, it must then buy as many resource contracts as it can afford and discharge them accordingly to increase its supply.

As mentioned in the preceding section, slack boundaries are configured in order to obtain a desired behaviour from the agent. A narrow nominal range of operation would cause the agent to respond sharply to fluctuations in its resource consumption. A wider nominal range would cause the agent to respond less actively.

Figure 1

2.6.3 ExecutionThe decision cycles in the system are executed in multiple iterations. The sum of these iterations is defined period of the simulation. The period is analogous to a fiscal year or any other metric that specifies the time limit during which resources are allocated, traded and consumed. In each iteration of the loop, any number of agents may be instantiated and run. The agents themselves are stateless and the results of their decisions are stored within the database (results of purchasing and selling operations based upon consumption and resource contract population).

During the execution, the consumption function deducts resources from the agents’ supply which is recorded within the database. The consumption function in and of itself is unknown by the agent. The

agent is only able to query the amount of resources it owns. The consumption function deducts this amount as required.

2.7 ImplementationThe simulation system is implemented in Java and makes use of mySQL server 5.0 as the database backend. The simulation system is composed of 3 main components; the implementation of the agents, a component that defines the various roles and their operations (or methods) and a component that handles the underlying database operations which are used for keeping track of contracts, funds and resources. Agents can perform operations on contracts which enter them into specific states, such as the bought, sale and discharged states. Based upon the states of the contracts, the agents can determine whether the contract may be bought, sold or discharged. The decision to execute these operations is implemented in the decision processing portion of the agent which relies upon the configuration of the slack limits.

The screenshot below depicts the output of the execution of the simulation.

Figure 2

First, the implementation of agent roles is discussed, followed by an overview of how the interaction with the database was implemented. Then the implementation of the agents is reviewed, followed by the contracts. Finally this section concludes with a discussion of the implementation of agent operations and slack.

2.7.1 Agent rolesThis package contains classes associated with buyer, seller and producer roles. The customer class contains a unique ID that is inherited by the buyer, seller and producer classes. Each role contains methods specific to the operations of the role.

For example, the buyer role enables the agent to perform operations such as transferring resource contract ownership from the seller to itself. In consideration, the buyer then transfers whatever sum was required to the seller to complete the transaction.

2.7.2 Database handlingThe database consists of 3 tables; the contract, fund and owner resources tables. The contract table contains records of contracts, the fund table keeps track of the amount of funds and the owner resources table keeps track of the resources each agent individually owns.

The database handling package contains classes for manipulating the data within each of these tables, including methods for opening and closing connections to the database, inserting, updating and deleting records.

2.7.3 Agents implementationThe Agents package contains agent classes that perform trading tasks based upon supply information and their own demand. The supply information is obtained from the database which contains records of contracts in sale states. Independent of this information, the agent can query the database for information related to its condition of funding such as how much it can spend on the market. Finally, the agent can also discover its own consumption rate and thus form a decision as to whether or not it will need to sell or buy contracts for resources.

2.7.4 Contract ImplementationEach contract must be unique. This will be used to differentiate contracts from each other in order for different operations to be performed.

Contracts for sale will be identified by an attribute that can be set by selling agents. A true value would signify the contract is for sale while a false would signify it is not. After the contract has been purchased, this attribute is set to false.

The ownership attribute contains an integer value that belongs to a specific agent to signify that it is owned by said agent. When a contract is purchased by an agent, the ownership is modified accordingly.

As mentioned above, the contracts are limited in their effect and expire at the end of their duration. The duration attribute is an integer measuring the time that the contract is valid. Every cycle that the simulation is run, this attribute is checked for validity. At which point the contract has expired, the resources are delivered and the contract is discharged.

The resources attribute contains the value of the resources associated with a specific contract. For the purposes of this system, the resources are understood to be controlled by the producer in quantity and initial price.

The price attribute contains the value of the cost of price of the contract. The value associated with this attribute can be arbitrarily assigned as long as that value is understood to have the same meaning by all other agents within the system.

The commencedate records the system time at which the contract was created for the comparison with the system time and the duration. These values are used to determine whether a contract has expired.

Attribute DescriptioncontractID A unique identifier for a contract. This attribute is set at the creation of the contract

and is never modified. This attribute is used to distinguish contracts individually. saleStatus This flag is set to false when the contract is not for sale. In order to signify the

owner's desire to sell it, the contract's saleStatus is set to true. An owner of a contract can choose to hold onto a contract by leaving the flag set to false for its duration, at the end of which it expires and the resources are delivered.

ownership An owner is identified by an ID number. The ownership attribute contains this ID number. This ID is set in the contract when the ownership is transferred to another market participant.

delivery This flag is set to false to signify that the contract has not been delivered (in other words, the resources have not been deployed), thus can be traded. The flag is set to true to signify the contract has been delivered. Once the contract has been delivered, the flag cannot be reverted.

duration The duration attribute contains the time from the commencedate (see below) of the contract that it will expire. Once the contract expires, the resources are delivered (thus automatically deploying the resources).

resources This attribute contains the number of resources associated with the contract.price The price of the contract.commencedate The date from which the contract is created.Table 1

2.7.5 Contract StatesContracts may exist in the following 8 states: Creation, Sale, Bought, Discharged and Produce. These states allow the agents to determine what operations they may perform on a contract at any given point in time during the fiscal period.

Contract attribute per corresponding contract stateContract State

contractID saleStatus ownership delivery duration resources price commencedate

Sale <string> true <seller> false <int> <int> <int> <long>Bought <string> false <buyer> false <int> <int> <int> <long>Discharged <string> true <seller> true <int> <int> <int> <long>Creation <string> true <producer> false <int> <int> <int> <long>Table 2

2.7.5.1 Creation StateBefore any contracts are ever bought, sold or discharged, they must be produced by a producer agent. A contract is in a creation state when it is owned by a producer agent, its saleStatus flag is set to true and delivery is set to false. This state is an invitation to treat to other agents within the system. The delivery attribute must also be set to false. A contract is only entered into this state upon its inception. Knowing how many contracts exist in the creation state at the end of the simulation tells one if too many contracts were produced and can be construed as waste.

The table above displays the value of the attributes of the contract in the Creation state. The contractID, ownership, duration, resources, price and commencedate attributes are set to whatever the parameters of the environment may be at the time or whatever the operator has initially defined. Anyone with access to query the database can determine which contracts are in a creation state simply by searching for all contracts owned by the producer with delivery set to false and have saleStatus set to true.

2.7.5.2 Sale StateA contract in a sale state has its saleStatus flag set to true and is owned by any agent other than the producer. A contract in a sale state must still be valid in that the current system time is less than the commencedate plus the duration. It must also have delivery set to false, denoting that the resources have not been delivered and the contract has not been discharged. This state is an invitation to treat to other agents within the system except the producer agent.

Should the agent wish to reverse its decision to sell the contract, it can be reverted to its bought state. As one can see in the contract attribute table above, the saleStatus is set to true and delivery is set to false. If it is required, the agent is free to discharge a contract in a Sale state should the agent’s supply of resources be in deficit to the lower slack limit.

2.7.5.3 Bought StateContracts which have been purchased by agents with the buyer role take ownership of the contract in a bought state. This dictates that the contract’s saleStatus flag is set to false. As with the aforementioned Sale state, a contract in bought state must be valid.

The agent is free to revert the contract to a sale state if it is so desired. When a contract is in a bought state, it may be discharged and the resources are added to the agent’s standing supply.

2.7.5.4 Discharged StateA discharged contract is not valid and cannot be bought or sold. A contract becomes discharged either because an agent has decided to use the resources associated with it or the contract has passed its duration and expired. In both cases, the resources are delivered and the delivery attribute is set to true. The value of the saleStatus flag need not be modified nor any other attribute so that a record exists of the state of the contract when it was discharged.

As shown in the table above, the delivery attribute is set to true.

2.7.6 Agent OperationsAgents must modify the following contract attributes when performing the specified operations in the table below.

Contract record attributes modified for each corresponding operationOperation contractID saleStatus ownership delivery duration resources price commencedateProduce yes yes yes yes yes yes yes yesBuy no yes yes no no no no noSell no yes no no no no yes noDischarge no no no yes no no no noTable 3

2.7.6.1 ProduceThe market is populated with goods to trade through the production of futures contracts by a privileged agent that is permitted to assume the producer role. This operation creates a record of a contract with attributes set in accordance with the creation state with other attributes chosen as market defaults. All attributes can be configured during the produce operation except for the contractID and commencedate attributes. These are set by the computing environment, such as the system time.

The creation state dictates that the ownership of the contract is set to that of the production agent and the saleStatus is set to true.

The table displays attributes that are modified during the execution of the Produce operation. There is no initial state as the contract does not previously exist.

2.7.6.2 BuyAn agent assuming the buyer role may perform a buy operation on a contract that is in a sale state. The saleStatus and ownership attributes must be changed accordingly if the operation is successfully executed.

2.7.6.3 Sell The sell operation obliges the agent to modify the saleStatus to a true value. It is optional for the agent to set the price attribute of the contract.

2.7.6.4 DischargeThe operation of discharging a contract requires that the delivery attribute is to be set to true.

A discharged contract is stored within the database with its last known state. When a contract has been discharged, the resources have been delivered (or considered used) and cannot be re-traded on the market.

2.7.7 Agent Resources ImplementationThe value of funds per agent is maintained within a table in a database. There are only two columns within this table. The first containing the agent’s ownership ID and the second containing the associated resources belonging to the agent.

2.7.8 Funds ImplementationThe funds belonging to each agent are recorded in a database in a table consisting of two columns. The first column contains the agent’s ownership ID and the second contains the funds associated with the agent.

2.8 Slack ImplementationThe slack limits are generated arbitrarily. For each iteration it simply compares its resource supply with the static slack limits. Upon the comparison the agent can either buy or sell resource contracts. An attempt was made to devise a dynamic method of generating slack values based upon the average resource consumption however this yielded unsatisfactory results.

3 Simulation ResultsIn order to demonstrate that the simulation operates as designed, the system was tested under several scenarios. The results were output, graphed and analysed.

3.1.1 SimulationsThe simulations were performed under different scenarios including the following:

1. Constant Consumption with 1 agent.2. Constant Consumption with 2 agents.3. Contract Discharge4. Random Consumption with 1 agent.5. Random Consumption with 2 agents.6. Varying the lower slack limit.

Experiment 1, 2, 3, 4 and 5 were performed to demonstrate that the agents within the simulation system performed as specified. Experiment 6 was performed to determine what relationship the slack lower limit had with the performance of the agent. It was hypothesized that the larger the nominal range of operation became, the fewer transactions the agent would perform. The results seem to support this hypothesis.

3.1.2 Constant ConsumptionThe first batch of results involved testing agent behaviour where consumption of resources was at a constant rate.

3.1.2.1 Constant Consumption with 1 agentThe first result is reflects the behaviour of 1 agent with a constant consumption function. This simulation is intended to demonstrate the basic ability of the agent to deal with simple resource consumption by purchasing resource contracts as required.

Simulation 1 ParametersNumber of Agents 1Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Resource Contracts 0Initial Agent Funds 10000Consumption Function 250 units/iterationSlack Lower Bound 4000 resource unitsContract Cost 100 fundsResources assigned per contract 100 resource units

The simulation was run for a total of 200 iterations. As shown by the graph depicting the agent supply of resources versus the iteration of the simulation, the market supply of resource contracts was exhausted before the simulation completed its full time period.

Figure 3

The simulation begins with 5000 units of resources in possession of the agent. The consumption rate for this simulation is fixed at 250 units of resources per iteration. The lower bound of the slack threshold is set for 4000 units of resources. At the 5th iteration of the simulation, the agent’s supply of resources falls below the slack lower bound threshold. The agent then knows to start purchasing resources. At

the 45th iteration, all contracts have been purchased and discharged by the agent and thus it cannot buy anymore to replenish its supply. The market has been populated with 100 contracts for 100 resources per contract by the producer.

The following table is used to illustrate the events that take place per iteration.

Iteration Consumption Resource units(Pre-Consumption)

Contracts Contracts Discharged

4 250 4000 0 0

5 250 4050 3 3

6 250 4100 2 2

7 250 4050 3 3Table 4

At the start of iteration 4, agent 1 possesses 4000 resource units. This amount is equal to the slack threshold. The consumption function then deducts 250 units from this supply.

At iteration 5, the agent sees that it possesses a deficit of 250 resource units in its supply has 3750 resource units in its supply. It then purchases 3 contracts for a total of 300 resource units and discharges all of these resource units to recover the deficit in its supply. The agent now has a supply of 4050 resource units. At the end of the iteration, 250 units are deducted from its supply due to consumption. In iteration 6, only two resource contracts are required to replenish the deficit.

3.1.2.2 Constant Consumption with 2 agentsThe second simulation was performed with 2 agents and its effects were observed and recorded. The parameters for the simulation are described in the table below. The purpose of this simulation is to demonstrate that basic interaction between multiple market participants functions. In this particular scenario, the expected behaviour is that the total pool of resource contracts should be depleted at a faster rate than in the first simulation with one agent.

Simulation 2 ParametersNumber of Agents 2Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Contract Resources 0Initial Agent Funds 10000Consumption Function 250 units/iterationSlack Lower Bound 4000 resource unitsContract Cost 100 fundsResources assigned per contract 100 resource units

Apart from having 2 agents, the simulation parameters are identical to the experiment with 1 agent.

Figure 4

The behaviour exhibited by agent 1 is similar to the first simulation.

Figure 5

Both agents consume resources at the same rate, thus the total supply of resources in the market is depleted faster. Both agents exhaust the supply of 100 contracts by iteration 25. In the previous simulation consisting of one agent, the market was exhausted of resource contracts by iteration 46. This simulation scenario demonstrates basic market interaction functions within the simulation where the rate of consumption of resource contracts increases as the number of participants increases.

3.1.3 Contract DischargeThis simulation demonstrates the functionality of the expiration of a resource contract. As previously described, the contract record contains a period of time for its validity. At the expiration of its validity the contract is discharged and the agent takes delivery of the resources associated with the contract. In

this simulation, the expiration time is set for an extremely short period in order to demonstrate its application in the system. The agent parameters are the same as in prior simulations except for the total contracts populated in the market. Instead of 1000 contracts, the system is reduced to 500, in order to exaggerate scarcity.

Contract Discharge Simulation ParametersNumber of Agents 1Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Contract Resources 0Initial Agent funds 10000Consumption Function 250 units/iterationSlack Lower Bound 4000 resource unitsContract Cost 100 fundsResources assigned per contract 100 resource units

The contracts were configured to expire 10 seconds from their point of creation during the simulation.

This screenshot demonstrates the expiration of the contracts during the simulation.

Figure 6

Given the quick expiration of the contracts, the figure below shows the agent experiencing depletion of resources by iteration 9 of the simulation. At this point in the simulation, the agent has purchased 13 contracts for a total of 1300 contract resources. At iteration 9, all the remaining 487 contract resources have expired and the agent cannot purchase any more to replenish its supply.

Figure 7

The consumption rate of the agent is set at 250 resources per iteration.

3.1.4 Random Consumption FunctionAnother scenario that was simulated was the case where consumption of resources was random. The consumption function was programmed to randomly consume or conserve resources, in other words it randomly added or subtracted resources from the agent’s supply. This function was used to simulate resource consumption in an unpredictable environment.

The agent parameters in this simulation are consistent with previous simulations except for the consumption function. See the table below.

Random Consumption Function Simulation Parameters – One AgentNumber of Agents 1Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Contract Resources 0Initial Agent funds 10000Consumption Function RandomSlack Lower Bound 4000 resource unitsContract Cost 100 fundsResources assigned per contract 100 resource units

The agent’s buying behaviour is consistent with its specified logic. That is, it maintains its supply of resources within the lower slack limit of 4000 resource units, as shown in the figure below.

Figure 8

In the figure above the random consumption function consumed an average of 49.93 resource units over the fiscal period of 200 iterations. The standard deviation was ±488.51 resource units. The raw data indicated that the market was exhausted of resource contracts at iteration 160. The average resource consumption from iteration 160-200 was 32.84 with a standard deviation of ±379.49. This information corresponds with the net increase of resources past iteration 160, the point at which the market supply of resource contracts was exhausted. The standard deviation is given in this analysis to indicate the volatility of the agent’s resource consumption.

The next simulation was conducted with two agents with identical input parameters as previous simulations except for a reduction of initial funds by 4000, resulting in 6000 funds per agent. The contract lifetime was set to 3 hours, well below the total duration of the simulation. This parameter was set in this fashion in order to observe the results of agent interaction without having contracts expire before the simulation completed.

Random Consumption Function Simulation Parameters – One AgentNumber of Agents 2Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Contract Resources 0Initial Agent funds 6000Consumption Function RandomSlack Lower Bound 4000 resource unitsContract Cost 100 funds

Resources assigned per contract 100 resource units

The reduction of funds was intended create a more informative graph as well as to increase the possibility that an agent would run out of funds.

Figure 9

In the figure above, agent 1 consumed an average of 31.95 resource units with a standard deviation of ±445.43. It is also observed that agent 1 sells surplus contracts at iteration 7 and 37.

Figure 10

In the figure above agent 2 consumed an average of 123.71 resource units with a standard deviation of ±474.06 resource units.

Agent 2 consumed resources at a greater rate than agent 1 using a randomly generated consumption function. In fact agent 2 managed to exhaust all its funds by the 69th iteration of the simulation while agent 1 finished the simulation with 1700 funds. From the beginning to the 69 th iteration, agent 2’s net consumption was 9651 resource units whereas agent 1 had consumed a net amount of 1215 resource units. The higher rate of resource consumption by agent 2 is not particularly indicative of anything other than the random nature of the consumption function.

Resource Consumption Rates with Random Consumption Functions for two AgentsAgent 1 2Average Resource Consumption per iteration 31.95 123.71Standard deviation of Average Resource Consumption per iteration

445.43 474.06

Net resources consumed by 69th iteration 1215 9651Table 5

3.1.5 Varying the lower slack limitAn experiment was performed where a single random consumption function was configured for a series of simulations where a single agent had varying slack lower limits. The purpose of this particular experiment was to determine what sort of relationship the slack lower limit had with the purchasing activity. Intuitively it seemed obvious that as the nominal range of operation was expanded, that the agent would perform fewer transactions.

The simulation was performed for 49 different lower slack values, from 4900 to 400. The initial parameters of the experiment are similar to previous simulations. The details are contained in the table below.

Varying Slack Simulation ParametersNumber of Agents 1Total Iterations (simulation period) 200Initial Resources 5000 resource unitsInitial Contract Resources 0Initial Agent funds 6000Consumption Function RandomContract Cost 100 fundsResources assigned per contract 100 resource units

The random consumption function was preserved by seeding the random number generation with the same value for every simulation run for varying slack lower limits.

In the figure below, a graph is presented depicting the result of a simulation with a high slack lower limit. That is, the nominal range of operation is narrow and several transactions must be performed by the agent to maintain its supply of resources. In the simulation below, the lower slack limit was set at 4500 resource units. For the fiscal period the agent performed 60 transactions to maintain its resource supply within the nominal range of operation.

Table 6

Figure 11

The simulation was repeated for 49 different slack lower limits. In the figure below, the graph shows the behaviour of the agent over the fiscal period for a slack limit of 2500 resource units, or half of the initial supply of resources assigned to the agent. The result was the agent performed 46 transactions where it bought resource contracts.

Figure 12

In the figure below, the graph depicts results of the final simulation where the slack lower limit was set at 400 resource units. The agent performed 9 transactions where it bought resource contracts.

Figure 13

The figure below shows a graph of the number of resource contracts bought by agents for each simulation, for a specific slack lower limit. The graph is displayed from the left to right starting at a slack lower limit of 4900 resource units and ending with a slack lower limit of 400 resource units.

Figure 14

The graph suggests that as the slack lower limit is decreased, the agent performs fewer transactions. In terms of devising a strategy for an agent, this result confirms that an agent’s sensitivity to performing transactions can be moderated by altering the slack lower limit. However, if the nominal range of operation is too broad, the agent will behave as if it has not been configured to operate within the bounds of any constraints.

4 ConclusionA system has been built to simulate the behaviour of agents trading contracts for resources to be delivered at a specific point in the future. The agents have been designed to perform actions that enable them to buy and sell these contracts based upon a simple strategy called slack. The slack defines a range of values of the agent’s own supply of resources as nominal for operation. When the agent’s supply of resources exceeds the upper limit or falls below the lower limit, the agent will then sell or buy resource contracts and discharge them to deplete or replenish its supply.

The ability of agents to successfully perform tasks such as buying, selling and discharging was demonstrated in simulations. An attempt was made to explore the agent’s behaviour with respect to varying levels of slack. The results suggested that as the nominal range of operation was widened, the agent performed fewer transactions.

4.1 Future WorkThe simulation system lacks a mechanism by which a selling agent may adjust its selling price. As the situation currently exists, the agent sells resource contracts at the price that they are bought. It may be worth exploring the behaviour of the market if agents were able to sell contracts at prices that reflect the agents’ need for resources.

Price by present value of funds.

Speculative pricing?

5 Bibliography[1] C. K. Woo, D. Lloyd, and A. Tishler, “Electricity market reform failures: UK, Norway, Alberta and

California,” Energy Policy, vol. 31, no. 11, pp. 1103-1115, 2003.[2] J. Hull, Introduction to Futures and Options Markets, New Jersey: Prentice-Hall Inc., 1995.[3] S. N. Neftci, An Introduction to the Mathematics of Financial Derivatives, San Diego: Academic

Press, 1996.[4] M. Parkin, M. Powell, and K. Matthews, Economics, 3rd ed., Reading, MA: Addison-Wesley,

1997.[5] P. McBurney. "Market Design or CAT Tournament 2008," 4/19/2008;

http://www.marketbasedcontrol.com/blog/index.php?page_id=5.