3 December 2010 - Pyosch/powertac-server GitHub Wiki

After a presentation of the new server structure and the technical foundations by David we proceeded to a lively discussions of our tariff model. The key conflict which arose is (as often) richness vs. tractability. The current attributes list in the wiki was compiled from what is out there (mainly English market) not from a customer modelling perspective. Since besides a realistic desciption of the power market consumer modelling as well as a robust game design are a key goals of our project we spent some time to elaborate on what aspects are ultimately required for our initial launch.

Key results and decisions:

• OWL ontology is powerful and enables queries against tariff base: “Customer wants a tariff which is better in two dimensions than my current"

  • However, reasoning can create a lot of overhead in the game context as we need F-logic triples (problem also showed up in SESAM project)
  • Technology-wise simple XML objects are preferred – just parse them as java objects on the server which could be hard
  • Solution: The OWL tariff ontology will be kept as a full specification but in every given year we focus on specific type of tariff detail and elaborate on these effects with a simpler representations; Tariffs should be described as object graphs

• Bundling vs separate treatment of multiple customer attributes (e.g. solar panel + family power plan + electriv vehicle with V2G): although being an important concept in marketing and pricing, bundling may be a bit too complex for our first realization:

  • Structurally different appraoches to customer choice process: all tariffs should be attractive to everybody (Publish complete tariffs and everybody picks what he likes out there the rest of the tariff is ignored) vs. specific tariffs
  • As a Broker offering lower price for consumption depending on capability of the customer e.g. Storage offered may be an interesting reasons for bundling
  • Current metering concept best facilitates separate meters for different consumption types
  • Solution: We will proceed by modelling these in a seperate fashion, i.e. a solar panel customer, a family power customer and an EV with V2G customer which will each sign up for a separate contract (will induce specific tariffs). This allows easier customer models and allows brokers to easily understand what tariff properties attract what type of customer
  • Potentially, we can find a nice workaround which facilitates both aspects from bundling and this more separate approach

• Two tier and multi-tier pricing potentially too complex

• Difference between Population and individual Customer models needs to be better definied - this is a question of game mechanics / server performance: fewer aggregated customer models with multiple tariffs vs. many micro-level models with single tariffs

• There was a discussion on the amount of tariff traffic data communication. John asks to keep this in mind.

  • Unclear if the traffic limitation due to competition controller is enough - will need to check this as soon as we have a running system.
  • Customer can but do not have to process tariffs every five seconds

• Tariff properties required not found yet:

  • Entry/ exit fees are a good way to capture customer inertia and very common in the marketplace (cell phone contracts) - should be included
  • Different kinds of customer behaviors that brokers need to evaluate risk:
    • Interruptable consumption
    • Solar, Wind attributes included in tariff but no value set
    • Storage yes / no (Battery, EV, Thermal storage)
    • Balancing capacity available
    • "No broker is interested a base of customers who do not have balancing capability"
  • Type of customer may create power set problems – customer with solar, customer with battery, customer with solar/battery, customer with neither are 4 roles in discriminator scheme
  • There were worries that we create a model that is poorly explaining reality, and thus may not generate any meaningful insights

We agreed that. arbitrary tariffs are ok, but we need to specify where to cut down the complexity. The ultimate goal is a simple model without complexity issues which facilitates easy modelling of customer preferences, a simple data representation as well as enough scenario richness for meaningful analysis.

To further progress we agreed that John, Prashant and Chris will together work out a baseline tariff definition for the initial game launch.