Tariff representation - Pyosch/powertac-server GitHub Wiki

up
This is a space for documentation and technical discussion about the domain data elements shared between brokers and the server. up

Tariffs are the broker's offerings to their customers. Within an instance of the simulation, tariffs will be represented as a graph of structured objects that conform to the Power TAC Tariff Ontology.

Here is a representation of a constrained version of this ontology, slightly denormalized to simplify relational mapping:

This structure allows a number of features within a simple, compact object graph. Many of the ontology concepts are collapsed into the Tariff itself (payments, power-type), but the rate structure is broken out. This allows for a range of rate structures without requiring space (memory and bandwidth) for unused features. It also allows a simple convention for unused features: null references. Here are some tariff features that can be represented:

• tiered rates, in which customers pay/receive one rate for a portion of usage (up to 20 kWh/day, for example), and a different rate for the remainder;
• time-of-use rates;
• weekday/weekend rates;
• two-part tariffs (fixed daily fee plus usage fee);
• signup payments in either direction (fee or bonus);
• early withdrawal penalties;
• variable rates with minimum and maximum values, estimated mean values, and notice intervals.

This model is implemented in the powertac-common plugin. The classes in yellow, TariffSpecification and its associated Rates and HourlyCharges are serializable value objects that are used to communicate between Broker and Server. Once a TariffSpecification arrives at the server, it is wrapped with a Tariff, which remaps the Rates of a Tariff into a 2-D array, indexed by usage tier and hour. Customer subscriptions to the Tariff, are represented by TariffSubscriptions, which are responsible for keeping track of the number of customers in a population model that are currently subscribed, and for computing credits and debits for power usage and production.

Note that not all of the features in the ontology will be implemented immediately. The major feature of the full ontology that is not represented here is the ability to write tariffs that bundle multiple power-types, such as household consumption and electric-vehicle charging. Such bundling is certainly practiced in the real world, but for the time being, the complexity of evaluating bundled tariffs is avoided.

On the other hand, bundling of tariff instances within the scope of a negotiated agreement seems reasonable and easily represented with minor modifications.

Chris Flath has posted a nice summary of our discussion of 3 December 2010 on the server wiki.

Some clarifications and refinements arising from an ongoing exchange among John, Prashant, and Chris:

• The noticeInterval field in the variable rate is the delay between a broker announcing a price change and the price change taking effect. So a noticeInterval of 2 hours would give customers a minimum 2-hour notice of a price change. A variable Rate, then, would always show the current price as well as the announced prices for at least the next two hours. Note that this scheme allows the broker to issue exactly one price update each hour for each of its outstanding variable Rates that are contained in its offered Tariffs.
• This model does not contain information about the source of power (wind vs. coal). If we want customers to express preferences over power source or perhaps carbon content, then we could add an additional field in the Tariff, a number between 0 and 1. We could label it "minimum renewable content" or "maximum carbon emission per kwh" or something like that. It's not clear how that information would be transmitted through the wholesale market.
• This structure does not allow a feature found in some of the British examples: "Sign-up for a 6-month contract and you get the first month free," or "get 30% off for the first two months" or some other time limited rate specification. Such conditions could be modeled with another kind of rate with an attached time interval, representing a discount applied to the "regular" rate, but the bookkeeping would be nasty if the early-withdrawal penalty involves refunding the discount, possibly pro-rated. It's unclear that this feature has research value, or whether anyone wants to build a customer model that could reason about such terms.

Given the above list we can think of the following tables of requirements for customer models with respect to choosing a tariff and "optimally" responding to a given tariff.