Customer model structure - Pyosch/powertac-server GitHub Wiki

up

Much of the interesting behavior of the Power TAC simulation comes from its customer models. Each model represents a population of customers with similar characteristics. Some are low-population bottom-up designs that model individual appliances and people, and some are higher-population top-down statistical models that can represent many thousands of individual customer entities.

A customer model has three basic functions in the simulation:

  • Consume and produce energy, as determined by the current model state, the current tariff, and the weather. This behavior is provided by the step() method, called by the simulation control during each timeslot.
  • Evaluate and subscribe to tariffs in the tariff market. This behavior is provided by the evaluateTariffs() method called by the simulation control when new tariffs are published. Note that a customer can invoke evaluateTariffs() at any time, but the simulation expects it at least when new tariffs are published.
  • Optionally provide some level of demand response. There are two types of demand response: curtailment and regulation. Interruptable devices such as water heaters can be shut off remotely or curtailed for limited periods, in exchange for lower energy prices. Interruptable and storage devices, including batteries and many types of thermal storage devices, may participate in short-term regulation, absorbing excess energy or reducing energy demand temporarily. Regulation rates specify payments for up-regulation (reducing consumption or actually delivering stored energy to the grid) and for down-regulation (absorbing additional energy).

Customer models are central to Power TAC, and the ability to add new customer models is an important facet of research value. However, they can be quite complex. Here are some goals for a new customer-model architecture:

  • Use the standard configuration scheme, to allow configuration in a binary environment. Currently, configuration for most models is using files in src/main/resources, which is packaged in the module jar files and therefore cannot be edited outside a source environment. This may require some updates to the current configuration scheme.
  • As far as possible, separate tariff evaluation from energy consumption and production. This is already mostly done through the use of tariff evaluators.
  • Although all existing customer models (as of August 2014) are internal to the simulation server, it would be desirable to allow for external customer models, to allow Power TAC to make use of existing behavioral models.

As a starting point, we'll look at the customer-models module in release 1.1.0. It contains a set of cold-storage warehouses that can be managed for energy storage. Individual models are subclasses of AbstractCustomer, which supports tariff evaluation and access to services (repositories). The AbstractCustomer in server-interface is similar, but contains quite a bit of dead code.

customer-models architecture

The current design in the customer-models module has three basic elements:

  1. CustomerModelService is the singleton Spring service that reads the configuration (using the server-standard configuration scheme) and instantiates individual customer models.
  2. AbstractCustomer is the common interface for all customer models in this module. It implements the two customer callbacks, as well as an initialize() method called by the service.
  3. Individual customer models are created by the service at startup as specified by the configuration. Classes must be subclasses of AbstractCustomer in order to be configured, because the system works by finding all the subclasses and looking for configuration clauses that specify those classes.

CustomerModelService and AbstractCustomer are not specific to the models in the customer-models module; it should be possible to move these to server-interface and use them for all customer models with minimal changes. The key will be to make the configuration schemes in other customer models conform to the Apache common-configuration system used in the rest of the server.

Differences between implementations

The version of AbstractCustomer in server-interface differs from the one described above in customer-models in a few minor and a couple major ways:

  • Dead code: upper and lower power cap, carbon emission rate, etc.
  • server-interface version allows multiple power-types per model, to support for example both consumption and interruptible consumption in the same model.
  • server-interface version includes subscribeDefault() method to subscribe to the appropriate default tariffs. This appears to be used only during initialization and in test code, and requires an extra service reference. The customer-models version puts this function in the service rather than in the customer.
  • server-interface version includes abstract methods consumePower() and producePower(). It's not clear why these are here.
  • server-interface version includes some test-support code, such as changeSubscription() and unsubscribe().