Talk:Market Intelligence Service functionality

Questions / Comments

 * 1) What is the mechanism to charge a fee? Does the MIS invoke a transaction on the CCS or Depot? If so, is this transaction asynchronous for end-of-negotiation fees and nested for value-added information?
 * 2) What is the mechanism by which the MIS collects the preferences of each customer? Who defines the standard factors represented in customer preferences and profiles? Can customers provide non-standard information in their preferences (which most likely won't be reflected in the profiles).
 * 3) Which subset of the programmatic or messaging interface should also be available from a GUI? None for now? All, except tariff-set submission? All eventually?

Tariff status
Editing discussion to reflect new game model that does not separate contracting and execution. We assume that every tariff customer always has a contract with some broker. What happens to those tariffs? Do they expire? Can new customers always sign up for them? Once a customer signs up, do they have the right to stay with that tariff forever? Here are some suggestions: Open question: Can brokers unilaterally change the terms of existing tariffs? This is common practice in the industry. Presumably this means that customers would then be more likely to "wake up" and choose among all brokers and tariffs. Preferred answer: No, but they can supercede a tariff when its term expires. Some customers will presumably just accept the new tariff without shopping.
 * 1) A tariff can be in one of two states: offered (new customers may sign up); valid (existing customers are not obligated to choose another tariff).
 * 2) A tariff continues to be valid at least as long as some customer is subscribed to it, but a broker can limit the term of validity of a tariff. That term must be part of the tariff description, so customers will know when they will have to shop for a new tariff.
 * 3) A broker can stop offering a tariff at any time. This does not affect its validity for existing customers.
 * 4) A broker can, with some advance notice TBD, revoke the validity of a tariff for customers whose obligated term has expired. Alternatively, they may notify a customer that their tariff will be superceded by another tariff when the first one expires.
 * 5) Customers can abandon a tariff at any time, but may have to pay a cancellation fee to the broker if they bail before the term of the tariff expires.

Grampajohn 02:53, November 6, 2010 (UTC)


 * This is almost exactly how I've been thinking about it. I agree that a tariff's terms cannot be changed but a tariff can be replaced with or superceded by another tariff.


 * One additional question I've run into in the last few days... in the whitepaper there is some mention of fees that are charged by the MIS for the tariffs offered. Are these fees charged only for new tariffs introduced into the market or does a broker get charged a fee for all offered tariffs at each contracting period? My suggestion would be that we charge a small fee for all offered contracts at each contracting phase and charge a bigger one-time fee for new tariffs introduced into the market.
 * PReddy 03:11, November 6, 2010 (UTC)
 * Interesting question. It might make more sense to treat it as a "commission" - the MIS gets paid whenever a customer subscribes to a tariff. That would seem to be a more realistic assumption. Is there a strong need to also levy a "complexity" fee for the number of concurrently-offered tariffs? I'm in favor of keeping it simple and easy to justify.
 * Grampajohn 03:43, November 6, 2010 (UTC)
 * I've been going back and forth on this, but it feels to me that if there is no extra charge for number of tariffs, brokers can flood the market with hundreds of highly customized tariffs and hope to simply overwhelm the other brokers and/or customers.
 * PReddy 22:31, November 6, 2010 (UTC)\
 * I suggest we include two fees: one for posting a tariff, and a commission for each match. We can easily set either fee to zero for experimental purposes.
 * Grampajohn 02:57, November 7, 2010 (UTC)
 * Carsten and I discussed yesterday that the complexy cost should be increasing in the number of active tariffs. As we fundamentally want the brokers to offer multiple and varying tariffs offering the first few tariffs should be relatively cheap. However, it is the flooding we want to prevent and hence an increasing cost allows us to counter this. I am unsure whether or not I like the comission per se as this seems to reduce consumer mobility (assuming that the broker will have to earn back the comission by offering worse rates). I would rather see the limited consumer mobility as some type of characteristic of the consumers (switching costs).


 * Considering the tariff statuses - I like option 3. (i.e. removing the offer of a tariff without affecting currently signed-up customers) combined with option 5. Option 4 (revoking after expriy of obligated life) seems somewhat complex and seems to harsh on the consumers as the broker can more or less renegotiate on already agreed terms.
 * Chrisflath 15:40, November 11, 2010 (UTC)

Tariff Attributes
The language of the tariff attributes is such that the same tariff can be used for consumers and producers.

Game design issue: Do we need to allow separate producer and consumer tariffs or do we force brokers to offer the same terms to consumers and producers? I.e., is a customer allowed to take either side of the tariff? (Not sure if there is currently, or will be, any government regulation that mandates this?) This seems like it would be a customer-friendly policy but it may make the broker's job of balancing supply and demand too hard.

Anyway, if we do separate the tariffs, the language can be made more specific for consumers and producers (e.g., Discount and Bonus instead of Offer).

PReddy 14:35, October 3, 2010 (UTC)

I think having separate tariffs might be easier for the broker, i.e. for the participants, and they are able to offers special tariffs to each group with different attributes. (unsigned?)

I think the answer depends on how prices are structured. Assuming brokers use 2-part tariffs (a fixed part and a variable part), then presumably at least part of the fixed part is paying for distribution. So if customer A is supplying 50 kwh while customer B is using the same 50 kwh, there has to be a net difference between what A is paid and what B pays to cover distribution cost. Probably the broker would need to make at least a minimal spread on the transaction also.

Grampajohn 03:01, November 6, 2010 (UTC)

I've been looking at the tariff attributes, and I have several reactions.


 * First, I don't really understand what's there.


 * Second, it seems unnecessarily complex and inflexible. This seems like an obvious application for an xml document with a defined vocabulary. Or maybe that's what you intend. Any time I see a data structure with multiple fields for the same kind of data (tier 1, tier 2, etc.) it makes me ask where tier 3 is. What's wrong with a collection of some kind.


 * I don't understand the tiers - are those Time Of Use (TOU) prices?


 * I don't see how to specify variable pricing.


 * I don't see how I would specify a standard two-part price (a fixed price/kWh plus a dynamic price).


 * I don't see how to specify any sort of constraints on variable pricing. For example, I can imagine offering a tariff that is tied to the spot market with a defined spread.

That's what I see at the moment. This may be an area where it would be worthwhile building an ontology.
 * It has an early termination fee without any way to specify the term of the contract.

Grampajohn 03:13, November 7, 2010 (UTC)


 * I should have posted the XML view instead since that is more intuitive. I didn't because I don't actually use XML in the implementation right now. I think I have taken into account most of the issues you mention here. The exceptions: I kept it to Tier 1 and Tier 2 for simplicity. We can obviously make it N-Tier capable if we think that would be useful. I did not consider the ability to tie variable pricing to a reference price like the spot market price -- that should be added.

 6.50  0=0.05, 9=0.10, 18=0.12, 21=0.08  15  0=0.10, 9=0.14, 21=0.10  90 20.0</ExitFee> <RateGuarantee units="days">0</RateGuarantee> <LeadTime units="hours">4</LeadTime> <OfferRate type="discount">0.15</OfferRate> <OfferPeriod units="days">30</OfferPeriod> <OfferDelay units="days">60</OfferDelay> <FuelMix>19, 5, 46, 22, 8</FuelMix> <Balance>0.03</Balance> </Tariff>


 * Variable pricing is specified using a map of hour-to-price entries. The value of the Tier1Rate and Tier2Rate attributes are such maps. I'm not sure I understand why a per kWh two part price is needed? What I included is a consumption-/generation-independent fixed price and the TierXRates which are the fixed or dynamic per kWh prices. I have a Duration attribute which may be the term length you're looking for?


 * One of my comments when I posted the code was indeed that constraint checking and validation is lacking on the Tariff class. I deferred impllementing that because I wasn't sure whether that should be done using an XML Schema on the message or locally in the Groovy class. For flexibility, I went with a HashMap container instead of named members for the various attributes (as Carsten suggested), but that makes validation more difficult (and also looking at the class is not very informative).


 * Does the above explanation help? (I will also add the XML to regular page.)


 * PReddy 04:23, November 7, 2010 (UTC)
 * Yes, this helps, and the structure makes it easier to understand. I still don't see how to specify dynamic pricing, or constraints, or a few other things, such as
 * A sign-up bonus or fee, which could be fixed or usage-based (first two weeks free, for example);
 * Balancing capacity that corresponds to specific load/source that may be constrained (water heater cannot be turned on if temp>max or off if temp<min, battery cannot be discharged below min level or charged above max level or must be fully charged at a particular time (vehicle battery));
 * I assume the "exit fee" applies if the customer bails before the Duration expires, correct? What if the exit fee is just a refund of the sign-up bonus, which might be variable? That would be easy to express.
 * Grampajohn 16:38, November 7, 2010 (UTC)


 * A sign-up bonus for first two weeks free would be something like:

<OfferRate type="discount">1.0</OfferRate> <OfferPeriod units="days">14</OfferPeriod>
 * In other words, 100% discount for 14 days.


 * For dynamic pricing, I figured TierXRate fields would be empty and LeadTime would have a non-empty value. But, it may be better add a bit more structure and make it explicit whether it's fixed or dynamic pricing. I'm not sure what you mean by constraints specifically. Variable exit fee sounds like a good idea -- I'll add that in the next iteration.


 * And yes, we need to add all the balancing capacity stuff... I didn't, and to some extent still don't, have a good understanding of how that would work. The above water heater and vehicle battery examples help. Do you have an larger set of such examples or do you have a specific structure in mind that you think would capture all the examples adequately? Thanks.


 * PReddy 17:47, November 7, 2010 (UTC)

MIS tasks / User Stories
I currently have a hard time finding and understanding these MIS tasks in the user stories - I would like to suggest that we should introduce a description / depiction of the MIS that clearly describes the mechanics at work. [e.g., from our call (Carsten, Wolf, John and me) on Monday I recollect that the MIS also takes care of the matching, i.e. represents the tariff choice of the small scale consumers.]

In general I would be happy to have an online discussion on MIS design and underlying mechanics but I without knowing what has been decided before I realized that such discussions lead to a lot of misunderstandings.

Chrisflath 18:05, November 11, 2010 (UTC)

JDcosta: Question related to the Contracting and Execution Phases in view of the Tariff definition and in view of the new game design
I am approaching this from the viewpoint of a retail consumer (ConCo-Ret) operating within the new game model. Lets say ConCo-Ret accept a “tariff” (Tarf1) proferred by Broker (B1) during a contracting phase (Phk1 @ t 1). This acceptance is supposed to work a “contract” (k1) between ConCo-Ret and B1 for dispatch of power (P MWh ) during the execution phase (or phases) (Phex1 @ at a future time (t2 > t1)). Please help me figure out the following:
 * how does ConCo-Ret specify the maximum units of power (P MWh ) that it has contracted for and therefore must arrange to pay for? Using the tariff, how does one compute the contracted for volume and the contract price (k1)? In order for acceptance of an offer to result in the formation of a contract, the offer 'must be sufficiently definite, or must call for such definite terms in the acceptance, that the performance promised is reasonably certain. I am assuming that in a specific duration contract to supply power, at least the total contracted for price and the total contracted for power must be ascertainable with reasonable certainty.
 * How does ConCo-Ret specify the execution period (or periods) (Phex1 @ t2) during which it wants the dispatch (or contracted for delivery of power) to occur? Clearly, t2 must be offset from t1 by at least the time it would take the ISO to make the scheduling decisions, the ramp-up time for the GenCos etc. This lead time (L(t2 - t1)) does not appear to be the same as the LeadTime you define (i.e. minimum lead time for price change signals (in hours)). The lead time L(t2-t1) cannot be the OfferDelay variable (Number of days before signup offer is accounted for and paid) either because, facially, OfferDelay appears to be related to the settlement and billing cyle rather than the time t2 at which the contracted for delivery is to occur.

I am tryng to understand the mechanics of aggregating the bids from contracting phase Phk1 and possibly from other contracting phases prior to Phk1 to compute the power to be dispatched by the ISO during a future execution phase Phex1, at a future time t2 when performance under the contract is promised.

Because the ISO is required to balance the dispatch to ConCo-Ret with the procurement of power from the GenCos at this future time t2, and because one of the side-effects of this process of balancing generates economic signals that inform at least the prices during the execution phase Phex1 (and possibly successive phases) in the real time market, understanding when contract performance is expected (given the definition of the tariff ) is integral to understanding the market platform and the agent design.
 * You specify a capacity related term Balance (Percentage of production/consumption capacity held for balancing ). However, there is no mechanism that constrains the maximum amount of power that can be drawn by ConCo-Ret at any given time t (t >= t2) during Duration (Contract duration from signup in number of days) to conform to the total capacity (and or transmission) constraints (Physical delivery constraints). The term Tier1Max (Threshold in kwh for consumption or production at tier1 rate) does not fit this bill (correct me) because Tier1Max is indicative of a price related constraint in that the tariff proposes to deliver a maximum of Tier1Max units of power at the Tier1Rate (Map of hourly rates per kwh upto Tier1 threshold ).There is no restriction on ConCo-Ret as far as demanding all the contracted for power in a very narrow time window within Duration so long as it is willing to pay the higher marginal prices (beyond Tier1Max). Wont such behavior violate some capacity constraints ( capacity, as the term is used here, is a measure of the quantity of instantaneous energy use. The term is applied to the amount of electric power delivered or required for which a generator, turbine, transformer, transmission circuit, station, or system is rated by the manufacturer.)

Cblock answers to JDcosta: Carstenblock 17:42, November 15, 2010 (UTC)
 * Consumers are "just consuming" energy. They are not announcing their consumption to the broker but merely just do it (as you in your home currently just turn the light switch on without prior announcing that to anybody). The broker thus has to predict the consumer behavior (e.g. based on historic load data). In order to make consumers change their predicted consumption behavior, a broker can change the energy price (currently called tier1rate and tier2rate respectively) over time, which might (or might not) lead to a consumption change at the consumer's premises.
 * The ISO (in the competition) is in charge of balancing the residual imbalance across all broker agents (i.e. the deviation between announced and real consumption or production). This basically means, that the ISO computes the overall imbalance for a timeslot that was closed from trading before (i.e. broker have no more influence on production and consumption in that slot). If an imbalance exists, the broker(s) who caused this imbalance are charged an expensive balancing power fee. Note: the ISO is not in the center of interest for the competition and thus only this reduced balancing power part of is modeled, which abstracts from reality, where ISOs also have to plan future demand in a region etc.