Difference between revisions of "Game Design"

From powerwiki
Jump to: navigation, search
(Model elements)
(Time-skipping to achieve longer timelines)
(26 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
===Model elements===
 
===Model elements===
  
====[[Broker]]====
+
==== [[Broker]] ====
: Responsible for building and operating a portfolio by offering [[Tariff Contract|tariffs]], and for balancing the supply and demand within that portfolio by trading in the [[Wholesale Market|Wholesale Market]].
+
 
 +
:Responsible for building and operating a portfolio by offering [[Tariff Contract|tariffs]], and for balancing the supply and demand within that portfolio by trading in the [[Wholesale Market|Wholesale Market]] and in the [[Balancing Market]].
  
 
====[[Distribution Utility|Distribution Utility and Accounting Service]]====
 
====[[Distribution Utility|Distribution Utility and Accounting Service]]====
Line 13: Line 14:
  
 
====[[Tariff Market]]====
 
====[[Tariff Market]]====
: Brokers offer tariff contracts to customers, which customers may accept or ignore. Tariffs may specify a number of conditions, including minimum contract duration, bonus or fee for subscribing, rates for production and consumption of power, etc. The Accounting services charges a fee to register a tariff and distribute it to customers.
+
: Brokers offer tariff contracts to customers, which customers may accept or ignore. Tariffs may specify a number of conditions, including minimum contract duration, bonus or fee for subscribing, rates for production and consumption of power, etc. A fee is charged to register a tariff and distribute it to customers.
  
 
====[[Market Data Service]]====
 
====[[Market Data Service]]====
Line 19: Line 20:
  
 
====[[Tariff Customer]]====
 
====[[Tariff Customer]]====
: A small-scale customer, such as a household or small-to-medium business, may be net supplier or consumer. Most (or all) tariff customers are represented by population models in order to achieve reasonable scalability.
+
: A small-scale customer, such as a household or small-to-medium business, may be net supplier or consumer. Most (or all) tariff customers are [[Consumers Simulation|represented by population models]] in order to achieve reasonable scalability.
  
 
====[[Contract Customer]]====
 
====[[Contract Customer]]====
 
: A relatively large (compared to an individual Tariff customer) customer who wishes to [[Contract Negotiation|negotiate an individual contract]] with a Broker for electric power service. May be a net supplier or a net consumer. Examples include large commercial and industrial facilities, and government entities.
 
: A relatively large (compared to an individual Tariff customer) customer who wishes to [[Contract Negotiation|negotiate an individual contract]] with a Broker for electric power service. May be a net supplier or a net consumer. Examples include large commercial and industrial facilities, and government entities.
 +
 +
: This feature is not currently well-specified, and has not been implemented.
  
 
====Bank====
 
====Bank====
Line 28: Line 31:
  
 
===Simulation Timeline===
 
===Simulation Timeline===
====Days and Dates====
+
The game simulates interaction over several days. The number of days is limited by the timeslot granularity (one hour), the maximum length of a simulation (about 2 hours for a tournament situation), and the minimum wall-clock time allocated to a timeslot (target value is 5 seconds). 12 timeslots/minute for two hours gives 1440 timeslots or 60 24-hour days.
The game simulates interaction over several days spread across two years. The exact number of days simulated is deliberately undefined to discourage the use of end-game or known-horizon strategies. However, participants can expect that the game will simulate approximately 60 days. Each simulated day represents a specific calendar date. For example, assume that the game is initialized with a start date of Jun 1, 2011. Then the sequence of days progresses as:
+
 
#Jun 1, 2011 (Simulation day 1)
+
The game timeline is therefore a sequence of days, with each day divided into 24 one-hour ''timeslots''. Each timeslot will occupy approximately 5 seconds of real time. The exact number of days simulated must be deliberately undefined to discourage the use of end-game or known-horizon strategies.
#Jun 13, 2011 (Simulation day 2 = Calendar date of simulation day 1 + 12 calendar days)
+
 
#Jun 25, 2011 (Simulation day 3)
 
#Jul 07, 2011
 
#Jul 19, 2011
 
#... and so on.
 
In other words, the date of the first simulation day is not known until the start of the game, but once that first date is known, the rest of the series can be computed deterministically. This is relevant because the underlying model in the game infrastructure attempts to simulate typical load and production levels for that date of a typical year and game partipants may want to use that knowledge in their strategies.
 
 
====Execution and Contracting====
 
====Execution and Contracting====
  
The game timeline is partitioned by two sets of periods, Execution and Contracting. An Execution period represents 1 hour in simulated time and lasts 5 seconds in wall-clock time. Therefore, each simulated day is made up of 24 Execution periods. In parallel, we define a Contracting period as 6 hours in simulated time. Therefore, we have 4 Contracting periods per simulated day and, correspondingly, 6 Execution periods per Contracting period. Contracting periods start at 00:00, 06:00, 12:00 and 18:00 in the simulated day.
+
Within the simulation, the one-hour timeslot is the smallest unit of time for which prices, power production, and power consumption can vary. During a given timeslot, the makeup of a Broker's portfolio of customers remains unchanged.  
 +
Brokers may offer tariffs, adjust prices for their subscribed customers, and place bids in the wholesale market at any time. Once during each timeslot, Brokers are notified of market activities, actual production and consumption for each of their tariff subscriptions, and current weather conditions.
 +
 
 +
Trading in the wholesale market may be conducted in multiple rounds during each timeslot; the number of rounds will be configurable between 1 and 4. A greater number of rounds will presumably communicate more price information, but at the risk of slightly less liquidity in each round.
 +
 
 +
Customer evaluation of new tariff offerings will be conducted just four times/day, or once every six timeslots.
 +
 
 +
====Initialization====
 +
 
 +
Given the relatively short duration of a simulation, brokers face a major problem of adapting to their environment fast enough to make intelligent decisions. One way to alleviate this burden to some extent would be to run the simulation for a period of time directly preceding the competition scenario, before brokers log in, and collect the basic data on customers and markets that brokers will need.
 +
 
 +
During this setup period, the default broker would offering a single tariff for each power type, all customers would be subscribe to that tariff, and the default broker would attempt to purchase enough power to serve its entire customer base, thereby making market prices for this quantity of power observable. The simulation would produce the following information during the setup period:
 +
* Hourly power consumption and production for each customer model.
 +
* Hourly production and price quotes for each of the gencos.
 +
* Market clearing records and orderbooks for each traded timeslot each time it is traded.
 +
* Hourly market position (net mWh of energy purchased/sold in the wholesale market) and prices paid for the default broker in each timeslot.
 +
* Net imbalance for the default broker in each timeslot. This is the difference between the broker's market position and the actual net consumption of its customers.
 +
* Hourly weather reports and forecasts.
  
An Execution period defines the smallest timeslot for which prices can vary. During a given Execution period, the makeup of a Broker's portfolio of customers remains unchanged. In fact, the portfolio remains unchanged over the six Execution periods that correspond to a single Contracting period. In a given Contracting period, Brokers can submit tariffs to the Market Intelligence Service or cancel tariffs that they had previously submitted. During the last Execution period in a given Contracting period, the Market Intelligence Service computes a new allocation of Tariff Customers to Brokers based on the tariffs submitted by each Broker and the preferences of the Customers. Each Broker's share of the allocation is then communicated to that Broker by the game server before the start of the next Contracting and Execution periods. Note that Brokers can negotiate contracts with Contract Customers at any time.
+
This is a lot of data. If we run a 2-week setup period, that's 336 timeslots, and each timeslot trades 23 times in the market, giving 7728 orderbooks and market clearing reports. What information do brokers actually need?
 +
* They need to know about customers and their power usage profiles. This could be satisfied with an array of consumption/production numbers for each customer model, and for each power type, indexed by timeslot.
 +
* To the extent that power consumption and production is affected by weather, they need to know the weather conditions for the setup period. This could be satisfied with the set of actual weather reports for this period. Forecasts should not be necessary.
 +
* They need to know the cost of power in the wholesale market. Assuming the default broker's bidding strategy is simple and well-specified, this should be satisfied by the actual cost of delivered power for each timeslot. By combining this with the net consumption data of the customers, brokers could infer an approximate cost curve for wholesale power.
  
Note: Given 5 seconds per Execution period and approximately 60 simulated days, the game can be expected to last approximately 2 hours in wall-clock time.
+
Because external brokers will not be connected, we assume that the time/timeslot could be substantially reduced during this setup period, but even one second/timeslot for a two-week simulated setup period would yield a 5-minute delay at the beginning of each competition game. One way to avoid this problem would be to run the setup period and collect the data offline, then distribute the relevant customer and market data to brokers at the beginning of the game, thereby giving the competition scenario a "running start".
  
(JDcosta: Q: Is the Execution (shorter time interval) and the Contracting (relatively longer look-ahead time horizon) identifiable with the Real Time Dispatch (RTD) over 5-10 minute interval) and Real Time Commitment (RTC over a 1-3 hr ) in a Real Time (as well as a Day -Ahead scheduling optimized over hourly intervals over a 24 hr period ) Market operation of a market design referenced on (for example) page 1964 of the reading material assigned for today's meetup (Chow et al)? (except perhaps for convolution with a time contraction/dialation operator to adjust for the relative differences in the magnitudes of the time periods involved in the proposed Game Design and the Market Design presented in the paper) [http://class.ece.iastate.edu/ee458/Chow.pdf
+
''Open question'': What is the "base" time of the simulation? Is it the sim time of the start of initialization, or the sim time of the start of the "real" game? Making it be the start of the "visible" simulation would make life somewhat easier for brokers, presumably, but it could complicate things for server elements that carry state over from the initialization period.
]
+
 
 +
====Time-skipping to achieve longer timelines====
 +
 
 +
One option is to spread the simulation timeline somewhat evenly across approximately two years. Each simulated day would represent a specific calendar date, and game time would progress by skipping days by 12, 12, 12, and 13 day intervals, using 4 of every 49 days and giving three weekdays and one weekend day in each "week".
 +
 
 +
For example, assume that the game is initialized with a start date of Jun 1, 2011. Then the sequence of days progresses as:
 +
#Friday Jun 3, 2011 (simulation day 1)
 +
#Wednesday Jun 15, 2011 (simulation day 2: add 12 days)
 +
#Monday Jun 27, 2011 (simulation day 3: add 12 days)
 +
#Saturday Jul 09, 2011 (simulation day 4: add 12 days)
 +
#Friday Jul 22, 2011 (simulation day 5: add 13 days)
 +
#... and so on.
 +
 
 +
In other words, the date of the first simulation day is not known until the start of the game, but once that first date is known, the rest of the series can be computed deterministically. This is relevant because the underlying model in the game infrastructure attempts to simulate typical load and production levels for that date of a typical year and game participants may want to use that knowledge in their strategies.
 +
 
 +
A major problem with this approach is that it would require significant manipulation of weather data to provide correct forecasts and avoid discontinuities across the day boundaries.
  
(JEC) - moved this discussion to the talk page...
 
 
==Major scenarios==
 
==Major scenarios==
 
==='''Server start'''===
 
==='''Server start'''===
Line 59: Line 91:
 
==='''Broker login'''===
 
==='''Broker login'''===
 
*Brokers first login to the Web App.
 
*Brokers first login to the Web App.
**In case a competition is open for participants, the Web App returns the competition server's URL. The broker then connects to the competition server.
+
**In case a competition is open for participants, the Web App returns the competition server's URL. The broker then must download the game parameters and static dataset, and then connect to the competition server.
 
**In case a competition is already running, the Web App either tells a broker to wait and check back at a later time, or the Web App sets up a new competition server. For research and debugging scenarios, brokers may be allowed to ask the Web App to create a competition based on certain parameters defined by the broker.
 
**In case a competition is already running, the Web App either tells a broker to wait and check back at a later time, or the Web App sets up a new competition server. For research and debugging scenarios, brokers may be allowed to ask the Web App to create a competition based on certain parameters defined by the broker.
*Once the broker has the server's URL, it logs into the simulation server.
+
*Once the broker has the server's URL and the necessary static data set, it logs into the simulation server.
 +
 
 
==='''Game start'''===
 
==='''Game start'''===
 
*Once all brokers defined as part of the server configuration are connected, the game starts.
 
*Once all brokers defined as part of the server configuration are connected, the game starts.
*Initial endowment is computed and communicated to all brokers.
+
*Brokers start with no Tariffs or Tariff subscriptions. All Customers are initially subscribed to a default tariff, which is communicated to the Broker as part of the static data set for the specific simulation scenario.
*If brokers start with non-empty endowment, then
+
*Brokers can immediately begin offering Tariffs, and may observe prices and even trade in the Wholesale Market.
**There is a "warm-up" period to allow brokers to predict supply and demand, and secure necessary commitments in the wholesale market.
+
 
==='''Wholesale market trading'''===
+
=== Wholesale market trading ===
 +
 
 +
Energy may be bought and sold in an auction-based [[Wholesale_Market|wholesale market]] at any time. Energy is traded in units of kWh for a given one-hour timeslot. At any given time, there are 23 timeslots open for trading, ranging from one hour ahead to 24 hours ahead of the current timeslot.  
 +
 
 +
==== Submitting bids ====
 +
 
 +
A bid specifies a quantity of energy (in kWh) and a price/kWh. Bids may be submitted at any time for any timeslot that is currently open for trading.
 +
 
 +
==== Transparency ====
 +
 
 +
At the end of each timeslot (once per simulated hour), the market clears bids for all open timeslots. Brokers are notified of the clearing price, their updated market commitments, and the price and quantity (but not the bidder identity) for all bids considered during that clearing interval.
 +
 
 
==='''Tariff offerings'''===
 
==='''Tariff offerings'''===
 
==='''Contract negotiation'''===
 
==='''Contract negotiation'''===
==='''Execution'''===
+
=== '''Execution''' ===
Primary activities during an execution timeslot include:
+
 
*Price changes are communicated to Customers.
+
Activities during each timeslot include:  
*Customers retrieve Environment conditions.
+
 
*Customers determine actual usage and production for the current timeslot.
+
*Price changes are communicated to Customers.  
*Portfolio retrieves supply, demand, and balancing capacity data from Customers. The cost of using customer balancing capacity is determined by tariff terms.
+
*Customers retrieve [[Physical Environment]] conditions.  
*Distribution Utility retrieves supply and demand from Broker Portfolios, Broker positions from Wholesale Market.
+
*Customers determine actual usage and production for the current timeslot.  
*DU determines prices for external balancing capacity.
+
*Accounting retrieves supply, demand, and balancing capacity data from Customers. The cost of using customer balancing capacity is determined by tariff terms. This data is treated as broker "bids" in the balancing market.  
*DU performs intra-Broker, inter-Broker, and external balancing. We assume this is done in a way that maximizes individual broker welfare; in other words, broker balancing capacity will be used as long as it's financially better for the broker than the cost of external balancing. Inter-broker balancing will initially be charged/credited at the price of external balancing capacity, until we allow brokers to make bilateral deals for mutual balancing. Note that the result of this step could change the prices for balancing capacity, so the two problems may have to be solved simultaneously.
+
*Accounting retrieves Broker positions for the current timeslot from [[Wholesale Market]].  
*DU clears the balancing market and runs resulting Bank transactions.
+
*Accounting/DU determines price function for external balancing capacity from the most recent timeslot in the wholesale market (the spot market price function).
*Portfolios compute actual charges and credits based on tariff terms and customer usage and production, run resulting Bank transactions.
+
*Accounting/DU enters the cost of running its own spinning reserves into the balancing market.  
*Brokers may retrieve demand/supply forecasts for future timeslots from MIS.
+
*Accounting/DU clears the balancing market, thereby performing intra-Broker, inter-Broker, and external balancing. We assume that the market clearing results in using customer balancing capacity as long as it's financially better for the respective brokers than the cost of increasing or reducing imports and of DU balancing. Inter-broker balancing will be charged/credited at the price determined by the balancing market, until we allow brokers to make bilateral deals for mutual balancing.  
 +
*Accounting runs resulting Bank transactions.  
 +
*Accounting computes actual charges and credits for customers based on tariff terms and customer usage and production, runs resulting Bank transactions.  
 +
*Brokers are notified of actual consumption and production, and use of customer balancing capacity, broken down by tariff.  
 
*Brokers adjust prices for customers with variable pricing. Updated prices may go into effect immediately, or be delayed, depending on tariff specification.
 
*Brokers adjust prices for customers with variable pricing. Updated prices may go into effect immediately, or be delayed, depending on tariff specification.
 +
 
==='''Winner determination'''===
 
==='''Winner determination'''===
 
==='''Game end'''===
 
==='''Game end'''===
  
 
==Research questions==
 
==Research questions==

Revision as of 14:25, 26 October 2015

Overview

Model elements

Broker

Responsible for building and operating a portfolio by offering tariffs, and for balancing the supply and demand within that portfolio by trading in the Wholesale Market and in the Balancing Market.

Distribution Utility and Accounting Service

The Distribution Utility (DU) models the regulated monopoly that owns and maintains the distribution infrastructure. In the context of Power TAC, it is a neutral third party, primarily responsible for balancing supply and demand in each timeslot. So if a Broker is unable to balance its portfolio, the DU does it, most likely through a balancing market mechanism. Because it controls the physical infrastructure, the DU is the party who is able to observe the actual energy use of the customers, and the actual power imports and exports through its coupling with the transmission infrastructure. Therefore, it also controls the accounting process by which customers and brokers are charged and paid.

Wholesale Market

Consists of a day-ahead market and a real-time (spot) market, which for the time being are treated as a single market. There are a number of market models in use, from a simple Continuous Double Auction (CDA) or Periodic Double Auction (PDA) to the more complex FERC structure used in much of North America, in which bids consist of piecewise-linear supply and demand curves. The CDA model is not workable within the Power TAC simulation, because of the time compression of the simulation and the variable latency of network-connected broker agents. Therefore, the market will operate as a PDA or Call market, clearing once per timeslot, with prices determined by the intersection of inferred supply and demand functions.

Tariff Market

Brokers offer tariff contracts to customers, which customers may accept or ignore. Tariffs may specify a number of conditions, including minimum contract duration, bonus or fee for subscribing, rates for production and consumption of power, etc. A fee is charged to register a tariff and distribute it to customers.

Market Data Service

Provides historical data on production and consumption to Brokers, aggregated in various ways. Also provides actual production and consumption data on an hourly basis, at the end of each timeslot, for a Broker's existing tariff subscriptions. The packaging and delivery of actual data will likely be bundled with the Accounting service.

Tariff Customer

A small-scale customer, such as a household or small-to-medium business, may be net supplier or consumer. Most (or all) tariff customers are represented by population models in order to achieve reasonable scalability.

Contract Customer

A relatively large (compared to an individual Tariff customer) customer who wishes to negotiate an individual contract with a Broker for electric power service. May be a net supplier or a net consumer. Examples include large commercial and industrial facilities, and government entities.
This feature is not currently well-specified, and has not been implemented.

Bank

Keeps accounts on behalf of the Brokers and the DU. Probably bundled with the Accounting service.

Simulation Timeline

The game simulates interaction over several days. The number of days is limited by the timeslot granularity (one hour), the maximum length of a simulation (about 2 hours for a tournament situation), and the minimum wall-clock time allocated to a timeslot (target value is 5 seconds). 12 timeslots/minute for two hours gives 1440 timeslots or 60 24-hour days.

The game timeline is therefore a sequence of days, with each day divided into 24 one-hour timeslots. Each timeslot will occupy approximately 5 seconds of real time. The exact number of days simulated must be deliberately undefined to discourage the use of end-game or known-horizon strategies.

Execution and Contracting

Within the simulation, the one-hour timeslot is the smallest unit of time for which prices, power production, and power consumption can vary. During a given timeslot, the makeup of a Broker's portfolio of customers remains unchanged. Brokers may offer tariffs, adjust prices for their subscribed customers, and place bids in the wholesale market at any time. Once during each timeslot, Brokers are notified of market activities, actual production and consumption for each of their tariff subscriptions, and current weather conditions.

Trading in the wholesale market may be conducted in multiple rounds during each timeslot; the number of rounds will be configurable between 1 and 4. A greater number of rounds will presumably communicate more price information, but at the risk of slightly less liquidity in each round.

Customer evaluation of new tariff offerings will be conducted just four times/day, or once every six timeslots.

Initialization

Given the relatively short duration of a simulation, brokers face a major problem of adapting to their environment fast enough to make intelligent decisions. One way to alleviate this burden to some extent would be to run the simulation for a period of time directly preceding the competition scenario, before brokers log in, and collect the basic data on customers and markets that brokers will need.

During this setup period, the default broker would offering a single tariff for each power type, all customers would be subscribe to that tariff, and the default broker would attempt to purchase enough power to serve its entire customer base, thereby making market prices for this quantity of power observable. The simulation would produce the following information during the setup period:

  • Hourly power consumption and production for each customer model.
  • Hourly production and price quotes for each of the gencos.
  • Market clearing records and orderbooks for each traded timeslot each time it is traded.
  • Hourly market position (net mWh of energy purchased/sold in the wholesale market) and prices paid for the default broker in each timeslot.
  • Net imbalance for the default broker in each timeslot. This is the difference between the broker's market position and the actual net consumption of its customers.
  • Hourly weather reports and forecasts.

This is a lot of data. If we run a 2-week setup period, that's 336 timeslots, and each timeslot trades 23 times in the market, giving 7728 orderbooks and market clearing reports. What information do brokers actually need?

  • They need to know about customers and their power usage profiles. This could be satisfied with an array of consumption/production numbers for each customer model, and for each power type, indexed by timeslot.
  • To the extent that power consumption and production is affected by weather, they need to know the weather conditions for the setup period. This could be satisfied with the set of actual weather reports for this period. Forecasts should not be necessary.
  • They need to know the cost of power in the wholesale market. Assuming the default broker's bidding strategy is simple and well-specified, this should be satisfied by the actual cost of delivered power for each timeslot. By combining this with the net consumption data of the customers, brokers could infer an approximate cost curve for wholesale power.

Because external brokers will not be connected, we assume that the time/timeslot could be substantially reduced during this setup period, but even one second/timeslot for a two-week simulated setup period would yield a 5-minute delay at the beginning of each competition game. One way to avoid this problem would be to run the setup period and collect the data offline, then distribute the relevant customer and market data to brokers at the beginning of the game, thereby giving the competition scenario a "running start".

Open question: What is the "base" time of the simulation? Is it the sim time of the start of initialization, or the sim time of the start of the "real" game? Making it be the start of the "visible" simulation would make life somewhat easier for brokers, presumably, but it could complicate things for server elements that carry state over from the initialization period.

Time-skipping to achieve longer timelines

One option is to spread the simulation timeline somewhat evenly across approximately two years. Each simulated day would represent a specific calendar date, and game time would progress by skipping days by 12, 12, 12, and 13 day intervals, using 4 of every 49 days and giving three weekdays and one weekend day in each "week".

For example, assume that the game is initialized with a start date of Jun 1, 2011. Then the sequence of days progresses as:

  1. Friday Jun 3, 2011 (simulation day 1)
  2. Wednesday Jun 15, 2011 (simulation day 2: add 12 days)
  3. Monday Jun 27, 2011 (simulation day 3: add 12 days)
  4. Saturday Jul 09, 2011 (simulation day 4: add 12 days)
  5. Friday Jul 22, 2011 (simulation day 5: add 13 days)
  6. ... and so on.

In other words, the date of the first simulation day is not known until the start of the game, but once that first date is known, the rest of the series can be computed deterministically. This is relevant because the underlying model in the game infrastructure attempts to simulate typical load and production levels for that date of a typical year and game participants may want to use that knowledge in their strategies.

A major problem with this approach is that it would require significant manipulation of weather data to provide correct forecasts and avoid discontinuities across the day boundaries.

Major scenarios

Server start

The server is started by the Web App (locally or remotely). It is provided with the identies of the participating brokers as part of its configuration.

Local startup is provided for research and debugging purposes, remote startup for multi-server competition situations.

Initialization

  • Start the Repast simulation
  • Set up Repast model instances

Broker login

  • Brokers first login to the Web App.
    • In case a competition is open for participants, the Web App returns the competition server's URL. The broker then must download the game parameters and static dataset, and then connect to the competition server.
    • In case a competition is already running, the Web App either tells a broker to wait and check back at a later time, or the Web App sets up a new competition server. For research and debugging scenarios, brokers may be allowed to ask the Web App to create a competition based on certain parameters defined by the broker.
  • Once the broker has the server's URL and the necessary static data set, it logs into the simulation server.

Game start

  • Once all brokers defined as part of the server configuration are connected, the game starts.
  • Brokers start with no Tariffs or Tariff subscriptions. All Customers are initially subscribed to a default tariff, which is communicated to the Broker as part of the static data set for the specific simulation scenario.
  • Brokers can immediately begin offering Tariffs, and may observe prices and even trade in the Wholesale Market.

Wholesale market trading

Energy may be bought and sold in an auction-based wholesale market at any time. Energy is traded in units of kWh for a given one-hour timeslot. At any given time, there are 23 timeslots open for trading, ranging from one hour ahead to 24 hours ahead of the current timeslot.

Submitting bids

A bid specifies a quantity of energy (in kWh) and a price/kWh. Bids may be submitted at any time for any timeslot that is currently open for trading.

Transparency

At the end of each timeslot (once per simulated hour), the market clears bids for all open timeslots. Brokers are notified of the clearing price, their updated market commitments, and the price and quantity (but not the bidder identity) for all bids considered during that clearing interval.

Tariff offerings

Contract negotiation

Execution

Activities during each timeslot include:

  • Price changes are communicated to Customers.
  • Customers retrieve Physical Environment conditions.
  • Customers determine actual usage and production for the current timeslot.
  • Accounting retrieves supply, demand, and balancing capacity data from Customers. The cost of using customer balancing capacity is determined by tariff terms. This data is treated as broker "bids" in the balancing market.
  • Accounting retrieves Broker positions for the current timeslot from Wholesale Market.
  • Accounting/DU determines price function for external balancing capacity from the most recent timeslot in the wholesale market (the spot market price function).
  • Accounting/DU enters the cost of running its own spinning reserves into the balancing market.
  • Accounting/DU clears the balancing market, thereby performing intra-Broker, inter-Broker, and external balancing. We assume that the market clearing results in using customer balancing capacity as long as it's financially better for the respective brokers than the cost of increasing or reducing imports and of DU balancing. Inter-broker balancing will be charged/credited at the price determined by the balancing market, until we allow brokers to make bilateral deals for mutual balancing.
  • Accounting runs resulting Bank transactions.
  • Accounting computes actual charges and credits for customers based on tariff terms and customer usage and production, runs resulting Bank transactions.
  • Brokers are notified of actual consumption and production, and use of customer balancing capacity, broken down by tariff.
  • Brokers adjust prices for customers with variable pricing. Updated prices may go into effect immediately, or be delayed, depending on tariff specification.

Winner determination

Game end

Research questions